On 23/01/15 15:00, John Bradley wrote: > 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.
True, but I think thumbprint=salt||sha256(f(salt,key)) is still better than sha256(key) which immediately gives the game away. But yes, bcrypt or pbkdf2 would of course be better. > 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. Yeah fair points. I'm not clear if thumbprints of symmetric keys are needed but if they are then h(secret) just isn't good enough a lot of the time, so I'd say the good choices are 1) don't support symmetric or 2) figure out an acceptable way to do it that's not a slam-dunk for the attacker when a low-entropy secret is used. Either implies a change to the draft. S > > 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 > > > > _______________________________________________ jose mailing list > [email protected] https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
