My concern with salting is that in the near future that may turn out not to be effective.
One observation about salting low entropy keys/passwords is that if the salt is known to the attacker, it may provide a deterrent to rainbow tables, but not one to crackers like oclhashcat. http://codahale.com/how-to-safely-store-a-password/ The above applies to simple concatenated salt || key cracking but the trend is relatively clear. Using PBKDF2 or bcrypt are probably more effective than a simple salt. Though I don't think changing to a different alg for symmetric keys is going to be all that useful. Low entropy symmetric keys are the problem. That could be dealt with as a security consideration, or by precluding thumbprints of symmetric keys. John B. > On Jan 23, 2015, at 10:46 AM, Vladimir Dzhuvinov <[email protected]> > wrote: > > What would be a good way to pass the salt? Within the "jkt" parameter > using some kind of a delimiter, or using a separate parameter? > > We've got a use case where we need to identify shared JWKs (oct). These > start at 128 bits. What length is generally considered low-entropy to > require a salt to be added? > > Vladimir > > On 23.01.2015 14:38, Stephen Farrell wrote: >> >> I just had a quick look and it seems fine for >> asymmetric keys assuming there's a need for it >> and a justification for including things like >> '{"e":' in the hash input, which I don't see. >> >> The reason I looked at this is that there's some >> overlap here with RFC6920, (I'm an author of >> that) and DANE and maybe other specs that say >> how to hash a public key. >> >> It does seem a shame to have so many ways to >> hash public keys, but 6920 is compatible with >> DANE and others that hash a SPKI (even if >> that's artificially created just as a hash >> input), so I wonder if the benefit of the >> running code here is really worth being >> different from other specs that hash a SPKI. >> >> So, other than that someone has some code, >> what is the benefit of being incompatible with >> other specs here? >> >> The downside is that I could not determine >> that one of these does/doesn't map to the >> same public key as some DANE RRs for example. >> Seems a bit odd to me to want to accept that >> downside unless there's an upside. >> >> Only other thing is for symmetric keys I think >> you should add an optional salt, in case you >> need the thumbprint of a low-entropy secret, >> which is quite likely to happen, and quite >> likely to get exposed somehow. And I'd argue >> to recommend that a long salt always be used >> for potentially low-entropy secret keys. >> >> Apologies if the WG discussed these before >> but I missed it;-) >> >> S. >> >> PS: These are just random-punter comments with >> no hats. >> >> On 23/01/15 01:56, Jim Schaad wrote: >>> This starts a two week last call on draft-ietf-jose-jwk-thumbprint. Last >>> call will end on February 2, 2015. >>> >>> >>> >>> Due to the general lack of activity on the list. General silence will be >>> considered as a vote to park the document and either have it done via the >>> ISE or with an AD shepherd rather than having group consensus. >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >>> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > -- > Vladimir Dzhuvinov :: [email protected] > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
