On Sat, Feb 25, 2012 at 10:47 PM, Kevin W. Wall <[email protected]> wrote: > > [SNIP] > > Well, I wish it were, but I've seen several evidences of this. For example: > 1) In ESAPI 2.0RC2 (release candidate 2), they security gurus insisted on > making the default crypto 256-bit AES, but in ECB mode. > 2) At work, the Information Security team's "Encryption Technical Standards" > only mentions which algorithms are acceptable and what the minimim key > size is (128-bits) for symmetric block ciphers. It makes NO mention of > cipher modes, padding, choosing IVs, or anything else. > 3) Later when my company was acquired, the new company had a standard of a > minimum key size of 256 bits for symmetric encryption, but said little > else. After much argumentation on my part, I finally convinced them that > 128-bits was more than sufficient. > 4) Why do snake oil crypto salesmen almost always refer to some obsessively > long key size, as if that is the only thing that matters? Could it be that > their development teams really think that that's true and their sales teams > also know that's what most other development teams believe and so that is > what gets emphasized? Gotta love the marketing department and sales team for the AES-256 promises (bigger is better).
I know of one place in Annapolis, MD where paint ball outings happen a few times a year. The engineers always look forward to hunting sales guys.... >> >> http://lists.opendnssec.org/pipermail/opendnssec-user/2012-January/001619.html >> >> See last paragraph about ECDSA keys. Someone might be interested in reading >> the >> whole "Default ZSK sizes" thread - for example, we found that registrars >> shared >> ZSKs for tens of thousands of domains (also tons of 512 bit RSA keys). The >> registrars are slowly rolling them over ATM. > > Great link; thanks. Some have been urging that we should be moving from > 1024-bit RSA keys to 2048 bit ones just because of the NIST push and all > the commercial CAs saluting the NISt flag. This might help push against > that trend. They apparently think that the extra key size comes for free. I believe the use cases are different. CA signing keys are long term. ZSK keys apparently have a much more frequent churn. It seems prudent to me if a key lives until 2035 or 2040, then it should be appropriately sized. Confer, Mozilla's list of CAs: https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html. I *believe* the list used to include a few keys with a 30 year lifetime (valid from the early 1990s until about 2020) with a 512 or 768 modulus. It looks like Mozilla finally flushed the smaller moduli from the list. (But again, I'm working from memory). >> A good article explaining the Vaudenay padding oracle (mostly leaves imprint >> on >> developers if they dedicate the 30-60 min to read it thoroughly), explains >> why >> modes are important along the way and gives insight into "engineer's mind": >> >> http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html > > Thanks for the link. It took me a LONG time to convince the ESAPI team > of this because I was the newb to them and I came in and said we > need to at least need to add a MAC over the IV+ciphertext. But it > took me a really long time to convince them because I could not remember > Vaudenay's name (so sorry if you are out there reading this!) and neither > could I recall the details of how it was done. I finally stumbled upon > it while Googling for cryptographic attacks against IPSec, which I remembered > was one of the things originally affected. Also of interest is Wagner and Schneier's "Analysis of the SSL 3.0 protocol" from 1996 or so (www.schneier.com/paper-ssl.pdf). The Horton Principal (Semantic Authentication) tells us to validate the IV and Ciphertext. From the contrapositive: if there's no need to validate the IV or ciphertext, then there is no need to send it because it has no value. I often use the contrapositive to flush out useless junk in a protocol. > Unfortunately, they didn't want to use something like GCM or CCM, which > were NIST-approved, because they were not in the standard SunJCE > implementation and given that we already had somehting like 30 jar > as dependencies, they didn't want to add another like Bouncy Castle's. This happens a lot in practice on mobile devices with FIPS requirements. You get stuck with AES/CBC and an HMAC. CMACs are not available, and neither is ECC. If you are being punished with a Windows Mobile or an early Apple device, the best you can do is 2048 Diffie-Hellman. 2048 DH has a security level of 112-bits. Its *impossible* to agree/transport an AES-256 key (with a 256-bit security level). +1 to the marketing team and sales guys. > Thanks to feedback from a few of you on this mailing list (well, actually, > it was Perry Metzger's list at metzdowd.com, but basically the same > cast), I think we got it right...at least if we can believe the NSA. > (Me, I'm still a bit skeptical for reasons that have to do with what > in retrospect seems like something obvious that just turned up that > the NSA did not mention. Can't say more until we get it patched.) > >> There was even better article from Matasano that showed the Vaudenay's attack >> nicely step-by-step, included commentary about IV selection (can't find it >> right now). > > If you do find it, please let me know. Usually I just point developers at > the YouTube video by Duong and Rizzo using POET to crack ASP.NET's > encryption and that convinces most of them. > >> NaCl library - should have sane enough defaults to make it hard for a >> non-crypto-devoted developer to screw things up: >> >> http://nacl.cr.yp.to/ > > I've looked at it. Unfortunately, there is only a C, C++, and Python > implementation. We desparately need something like this for Java, C#, > Ruby, etc. You already have what you need :) >> Question regarding the IVs: is there a cryptographically-secure pseudo-random >> permutation generation function for that? I've seen notices in this thread >> but >> can't remember if one was named explicitly. (Sure one could code one up from >> a >> PRNG, but I wouldn't want to be the person that would guarantee its safety.) >> Such function is generally useful in non-crypto ways, too. > > At work, I've seen *WAY TOO MANY* uses of crypto where the developers have > used a fixed IV simply so they would not have to store the IV with the > ciphertext in a DB. They claim that they need to do this because "we are > storing millions of records". Right. Until such time the database programmers have a CV on par with folks like Krawczyk, Wagner, Schneier, Gutmann, Bellare, Bernstein, (and many others on this list - no offense intended), their opinions will be duly noted and should be thoroughly ignored (with prejudice). >>> 6) They have a very naive concept of entropy...where/when to use it and >>> from where and how to obtain it. >> >> I admit that I don't fully understand entropy in crypto sense (though I'm >> fine >> with its physical meaning). No offense to any of you, but my impression from >> the >> entropy discussion is that no one can understand it fully, it's simply damn >> complex subject to understand correctly (taking in account that we don't >> really >> have a precise definition). > > Entropy in information theory surely is a much more difficult concept than > it is in physics. It doesn't help that to know whether you are doing > it correctly or not you have to have a fairly deep understanding of > statistics which most developers don't have and don't even want to > know about. Random numbers are a cryptographic primitive. When in doubt, use an EntropyKey (http://www.entropykey.co.uk/) or other hardware based source of entropy to ensure the health of your random numbers. Then you don't have to worry about software algorithms developing the bits at boot time. >> Obviously no one can tell this to a developer and expect the developer to >> automagically do things right. > > Obviously, it depends a lot on experience. Sure, most developers will > Google for something that don't know, but it's not always the reputable > links that are highest on the hit list. So instead, you end up with > developers sharing ignorance with each other on some developer forum. > Part of it is that they just don't know any authorative sources and > part of it no one thinks to try something like Google Scholar for > their searches. "When a project has cryptographic requirements, who is responsible for cryptographic design and analysis of overall system security?", http://www.codeproject.com/Surveys/1068/When-a-project-has-cryptographic-requirements-who-.aspx. Jeff _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
