Confirmed users
134
edits
BrowserID Key Wrapping: Difference between revisions
→What this Means for BrowseID
Stomlinson (talk | contribs) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 57: | Line 57: | ||
=== Crypto Preliminaries === | === Crypto Preliminaries === | ||
We don't ever do raw encryption. We perform encryption- | We don't ever do raw encryption. We perform encryption-then-MAC. We do this by encrypting the plaintext, then HMACing the ciphertext. The decryption process first checks the HMAC, and decrypts only if it is valid. In the following description, every time we talk about a single key, we really mean two keys: one for encryption, and one for HMACing. We use AES in CBC mode for encryption, and HMAC-SHA256 for MACs. | ||
Wrapping a key means encrypting (and HMACing) a data structure that contains the key and some optional tags. We denote this | Wrapping a key means encrypting (and HMACing) a data structure that contains the key and some optional tags. We denote this | ||
| Line 73: | Line 73: | ||
[[Image:Browserid-userkeys.png]] | [[Image:Browserid-userkeys.png]] | ||
==== What this Means for | ==== What this Means for BrowserID ==== | ||
BrowserID is now storing a (wrapped) user-key per email address. This functionality should move to the identity provider for that email address. BrowserID, as the secondary identity provider, will be the fallback, of course. This means we'll need to define an interface for this key-wrapping interface into an identity provider. We leave that specification to a later date. | BrowserID is now storing a (wrapped) user-key per email address. This functionality should move to the identity provider for that email address. BrowserID, as the secondary identity provider, will be the fallback, of course. This means we'll need to define an interface for this key-wrapping interface into an identity provider. We leave that specification to a later date. | ||