Paul Hoffman wrote: > At 4:59 PM -0700 9/23/08, Nelson B Bolyard wrote: >> In finality, you have to pick a table from someone you believe has done a >> really good job of analyzing it. > > Right. > >> Given that NIST's tables are the basis >> for the US Government's protection of its own secrets, which it guards >> jealously, I'm inclined to accept them as adequately conservative. :) > > This may seem nitpicky, but... > > NIST's tables are for "Federal Government unclassified applications" > (see the table intro on page 65). NIST does not set the rules for US > Govt secrets; the NSA does. See > <http://www.nsa.gov/ia/industry/crypto_suite_b.cfm>.
Thank you Nelson! My point exactly :) > The NSA's > requirements for secret and top secret are quite different than what > you see in SP 800-56 part 1. Apropos to this thread, RSA signing is > not allowed for certificates on secret or top secret material, only > ECDSA is. Aha. I wondered about that. Is that ... like a serious declaration of war against RSA from the NSA? Or are they just declining to follow the fat keys syndrome ... To answer Paul's other question, the guys at keylength.net present not only the NIST models, but several others. You can select and play around, it's all coded up nicely. If multiple models give you similar answers, then it is OK. The guys who did the original site were actually working with the cryptographer(s) who wrote the original paper that did the year table back in early 2000s. I can't recall who it was, but it made quite a ripple at the time, as everyone was thinking "gee, I wish I had thought to write that paper...." I'm not sure if they are still involved though. NIST's paper is of course a follow-up for ... those people who NIST tells to keep secrets. iang
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
