On 18/12/2014 08:06, Tarek Ziade wrote:
On Wed, Dec 17, 2014 at 9:44 PM, Ryan Kelly <[email protected]
<mailto:[email protected]>> wrote:
But this user public key should not be derived from the core kA/kB
key material.
If it's a public key corresponding to kBr being a private key, why is it
a problem ?
I don't think there is an actual *problem* with doing it this way, it
just sets of my crypto-hygiene radar.
How will you derive a suitable public key, given only kBr? I can think
of a few ways to do it which seem safe to me, but I would not be
comfortable shipping "seems safe to me" to production.
[..]
In my proposal, kBr is a symmetric encryption key, so there is no
"corresponding public key".
I am not sure you've mentioned how exactly kBr should be used.
Sorry, indeed, I should have explicitly said "kBr is a symmetric
encryption key known only to the relier and the user".
More generally, it is 32 random bytes known only to you and the user.
From that perspective, do with it what you will! Nothing that you
choose do with with kBr will affect the security of the core key
material or of other reliers (in theory...)
Stating that it's a private key, and generating the corresponding
public key seems to make sense.
What's the problem of doing this ? I am asking because I'd like to find
a flow where we limit the number of public keys
attached to a user stored in the user directory.
Ideally, one key per user and service. I am not sure to understand the
value of an extra level of indirection between kBr and a corresponding
published public key.
If I understand your proposal correctly, you want to do something like
this to build up a database of user public keys:
DO-THE-OAUTH-DANCE-TO-GET-kBr
userPubKey = DERIVE-PUBKEY(kBr)
db.write(userid, userPubKey)
This is fine if you can safely fill in the DERIVE-PUBKEY operation. I
don't know a sufficiently-well-established pattern for doing that, so I
was proposing something like this:
DO-THE-OAUTH-DANCE-TO-GET-kBr
(userPubKey, userPrivKey) = RANDOMLY-GENERATE-A-KEYPAIR()
db.write(userid, userPubKey, ENCRYPT(userPrivKey, kBr))
From my perspective, the key point is that a relier should be able to
do whatever it wants with its kBr and not affect other reliers.
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
