Ok, I'll bite. Why would it be more secure?
Would the following block cipher be more secure than AES?
function encrypt(block, key) {
return block XOR key;
}Would the following block cipher be more secure than AES?
function encrypt(block, key) {
return block XOR key;
}AES in its default block cipher mode can usually be byte-at-a-time decrypted. AES in its "conservative" mode can almost always be byte-at-a-time decrypted when not augmented with another crypto building block that developers invariably forget. When developers don't forget that building block, they often manage to implement it in such a way that it too can by byte-at-a-time broken. AES in its most "modern" mode ends up being exactly as secure as naive XOR when developers use it without understanding its parameters.
On the other hand, if you read the Wikipedia page on Feistel networks and wrote your own --- or if you just used reduced-round FEAL-4 --- but used Keyczar to actually deploy it against real data, all those mistakes I alluded to above would be avoided, and your attackers would have to do real cryptanalysis to attempt to break your application; nobody does that.
Knowing this, you can now see why I'd take issue with the idea that your "Secure Progammer's Pledge" urges people to use "vetted algorithms" to protect data. AES is about as "vetted" as algorithms ever get, and its use in production code by generalist developers is almost always comically insecure.
So: no, that one example turns out not to be more secure than AES, even in Keyczar. The problem is, by itself, it usually turns out not to be less secure either.
> AES in its default block cipher mode can usually be byte-at-a-time decrypted.
1. Block ciphers don't have default modes. Implementations might. Does OpenSSL really use ECB as the default mode? (I agree wholeheartedly with you that sensible defaults are extremely important, and so ECB-as-default seems hard to believe.)
2. What does "byte-at-a-time" decrypted mean? You haven't specified the threat or attacker models.
Are you saying that given several million ciphertexts, you can recover the key from AES-ECB? AES-CTR? Does the attacker need side channel acccess? How about given one ciphertext? Or is this a chosen-plaintext or chosen-ciphertext attack?
In short, could you please detail the attack you have in mind?
> AES in its most "modern" mode ends up being exactly as secure as naive XOR when developers use it without understanding its parameters.
As far as I can tell, this is entirely predicated on your later statement that "nobody does [real cryptanalysis]". What is AES's 'most "modern" mode'? Which parameters are you referring to here (key size, mode, any others?)
My guess is that XOR will fall in some small number of hours against someone who cares; AES-128-ECB (as bad as it is) may require many more resources for key retrieval.
For fun, which definition of security are you using to compare cryptosystems?
You're a security researcher who doesn't know crypto. This stuff isn't hard, but for some reason, most security researchers know fuck-all about how to test and exploit crypto bugs. Don't take too much offense; I was in the same bucket until a few years ago (and I'm not far from it even now), and I've been a researcher since 1994.
ECB is the default mode not because people choose overtly to make it the default mode, but because it requires no parameters to make it work. Look at a generalist programmer's cryptosystem. Flip a coin. Did it come up heads? It's ECB mode, because that's the moral default.
Nothing I'm talking about involves "several million ciphertexts".
Nothing I'm talking about involves side channels --- at least, not precision measuring side channels. "Side channel attacks" are the voodoo totem that security researchers wave around when they don't know a specific attack that will break a cryptosystem. Sort of like not knowing how to pick a lock a pin at a time, but talking about "bump keys".
Nothing I'm talking about even involves the attacker knowing for sure what algorithm the defender used. We test for this stuff black box; it takes less than a week to train people to do it.
No, I'm not going to provide more details here. Not because I jealously guard this stuff (I've written most of this stuff on HN before, and I've given talks about it that are recorded online), but because every time I get into a thread like this, someone comes back and says "oh yeah well THAT attack is LAME and I assumed that any smart developer would already have defended against it" and I'd rather reveal ignorance for what it is.
ECB will fall in seconds in most situations. If you knew how to test crypto, you'd know that none of these attacks "retrieve keys". Again: don't take offense. People way smarter than me don't know this stuff. I think it's because the papers use math notation.
You're unwilling to have this conversation again; I understand. Do you have a link to one of your talks? I'd be interested in watching.
Can you at least tell me what definition you're using for "fall", if not key retrieval? Replay attack? Information leakage?
Edit:
> "I don't understand the vulnerabilities you're talking about so I'm going to assume there's something basic about how stuff works that I grasp but you do not"
Sorry if it came off that way! I'm assuming that you understand something basic about how this works that I do not, and wondering what it is :)
"Byte-at-a-time decryption" means creating a scenario where attackers can brute force numbers like 2^8, winning a single byte of "plaintext" (or whatever the equivalent is depending on the primitive you're targeting). If your block size is 16 bytes long, the attacker might have to brute force 2^8 16 times; with a laptop, you might be talking about whole seconds of work.
Block cipher attacks generally never recover crypto keys.
I am being intentionally vague. Not because I want to keep information from you, but because I don't want to create yet another crypto thread that gives developers a false sense of knowing what the risks are when building crypto.
If this is something you're seriously interested in, and you can code in any programming language, email me and I'll give you a syllabus of straightforward things to work on.
Could you explain something here? How can a block cipher that has 128 bits of output be attacked 8 bits at a time (where 1 bit change in the input will change on average 64 bits of the output in a non-predictable manner)? Sure, you can try every 8 bit permutation, but without knowing the form of the original text how can you know if you have a valid character? And how is that different from extracting "raw data" out of pure randomness (where the fallacy is obvious, you're extracting data that was never there)?
I'm genuinely interested, so if an email will do it, could you please follow up: ircmaxell [at] php [dot] net...
Thanks!
I think you get my point now. Maybe rethink the crypto stuff in your pledge.
Using a well known algorithm is such a small part of the overall security of a cryptosystem that it makes the call to use only well known algorithms useless by itself. Hence tptacek recommending using proven high level libraries (e.g. OpenSSL's EVP_* family of functions).
* Does the library expose block cipher mode choices to callers? It's not high-level.
* Does the library expose IVs to callers? It's not high-level.
* Does the library separate "encryption" from "authentication", offering the choice of doing one without the other? It's not high level.
* Does the library by default allow users to pass in raw buffers as keys? It's not high level.
Don't use OpenSSL directly to do crypto in applications.
What's your go to solution?
For the situation you describe, a "low-level" crypto library is handy; for instance, very few libraries implement ciphertext stealing, so if you require compatibility with some wacky protocol or file format that uses CTS, OpenSSL EVP is no help either.
That doesn't make OpenSSL's primitive interface a good choice.
If you are designing crypto for your own application, and you find yourself typing "O-p-e-n-S-S-L" or even "A-E-S", you are probably in for a lot of trouble.
I agree with you that Keyczar is good to use for certain use cases, but that isn't always the case. Instead of always telling us to use Keyzcar how about showing us how to use the primitive libraries more correctly to have secure applications YET at the same time allow us developers to have the flexibility to use them as we need to use them for compatibility with other implementations or with government requirements (for those of us in the gov't contracting world).
You are in the unique position that you have seen all of the mistakes and know how to avoid them and thus could help developers avoid those mistakes as well.
No, I don't think I'll be spending time trying to help people roll safe custom crypto by hand using the primitives in OpenSSL. For one thing: I'm nowhere close to confident that I know enough to make recommendations like that.
You are well respected when it comes to the field of crypto in this community, you have a lot of knowledge that comes with that, and I believe sharing that knowledge would be more beneficial than just saying "Use Keyczar". Sometimes that one tool just doesn't fit the bill and or can't be used due to contractual obligations/constraints. Even if you are not confident to make a recommendation of how to use OpenSSL securely you can at least say "These are the top 5 mistakes I see" and "Typing A-E-S into your code" can be on that list, but it isn't very constructive.
Why shouldn't there be a choice to offer separate encryption from authentication?
How does interoperation with other libraries/platforms work. For example trying to interoperate with Java for Diffie Hellman has for instance meant using an library that does BER/DER and decoding the values ourselves because Java uses an older standard compared to the library we are using on the C++ side (Botan). We have to have the ability to manage keys ourselves. All the higher level abstractions create all kinds of issues because the choices made don't let us interoperate because they are different from what the next library chooses.
Because if you're using a high-level interface to cryptography, the handling of the IV is a detail that can easily be hidden from developers without loss of security or, in reality, meaningful flexibility? Meanwhile, asking developers to provide an IV is an invitation to cryptosystem flaws?
Because maybe you shouldn't be doing custom Diffie Hellman in your application to begin with? Is there a pointer to either your Java or C++ code on Github? Do you know how to do DH safely? I don't, but I know some flaws to look for, and that I've found in the real world on pentests.
Instead of talking about BER/DER, how about you talk about the DH pitfalls you avoided and how you avoided them? That way, readers of this thread would get a whiff of maybe why they wouldn't want to come within a mile of a custom DH implementation.
Sure, encryption without authentication is worthless, but what if I want to do the authentication in a different manner? What if I want to encrypt using AES-128/CTR-BE and then sign using public/private key rather than using an HMAC(SHA-256). That choice can be left up to a developer. Also, there still seems to be some debate as to whether you encrypt then HMAC or if you HMAC then encrypt. (I personally prefer encrypt then HMAC).
I don't think you necessarily have to have the developer provide the IV, you can provide a way for the developer to get the generated IV back from the system after the fact that would work just as well. So long as you can get access to it, so you can build it to spec. All this hiding is good for projects where that is possible, interoperability and following gov't requirements can throw a wrench in simply using something like Keyczar.
The biggest issue with DH that we have had to overcome is the different encodings that may be used. You have various different standards for how to share the DH keys. There is an ANS X9 standard that is recommended by the government[1] (and required in our product) and then there is PKCS3.
The biggest issue we ran into is that Java (on Android) only does PKCS3, and Botan doesn't by default decode that so you end up having to implement that functionality yourself. We ended up using PKCS3 but that will most likely have to be changed for gov't approval which means we need to get Java to grok ANS X9.
When doing DH I also suggest using one of the NIST approved DH groups and not generating your own.
Do note that none of this is using a custom DH implementation, it is using the stuff that is available in Botan/Java itself, the biggest issue is finding common ground for finishing the DH key exchange because of the different formats used in the in-between steps.
Also, generating a random key from the DH data is different on various different API's. Botan can generate keys for you, and will use a KDF for you, while Java will simply give you the bytes back in raw format.
So far this isn't a solved problem for us. Since we are not using it for cryptographic purposes we may end up doing our own custom implementation so that we have less to worry about in terms of encoding/decoding various different storage schemes. And any weakness in the system won't be a fatal flaw that could be used/exploited in a meaningful manner, so fixing things at a later date won't be catastrophic.
The biggest issue is that there are so many standards and so many little variations of it in cryptography that trying to get systems to interoperate and work together is a massive undertaking and each time you run up against a wall because something is abstracted away you wish and eventually want access to the lower level primitives.
[1]: http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A...
Incidentally, there's not much controversy about encrypt-then-MAC vs. mac-then-encrypt. You E-t-M, so attackers can't play games with ciphertext bits. Also: if you have the choice, you'd probably want to avoid using public key signatures when you could just get away with using a MAC. The public key stuff strictly adds vulnerabilities; it doesn't ameliorate any.
Wasn't this an issue in an IPSEC implementation?
Or are you talking about the no authentication on DH so that MITM is trivially possible? Or the choosing of bad prime numbers (hence my suggestion of using the NIST groups) could mean it is easier for an attacker to figure out the private key that is generated.
Speaking of which, this paper which I read a while back is definitely a good idea for reading before implementing DH:
http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf
Do I feel confident how to tell generalist developers how to do crypto? Not entirely, but I do feel confident telling generalist developers what I have seen that is completely wrong or what has to be avoided.
As for the encrypt then mac, I'd definitely agree with you there, and also agree that public key may not be the best, but the option should exist. For what I am currently working on it is encrypted then HMAC the encrypted data, then the HMAC is stored publicly but the key for the HMAC is encrypted with public key, then that encrypted data is signed with private key. Now the receiver verifies signature with senders public, decrypts symmetric key/iv/hmac key with private key, and then verifies HMAC for data, then decrypts the data.
Which as far as I am aware (and please correct me if I am wrong) is the best way to make sure that the data has not been tampered with.
Lots of people have done their own implementations of DH (DH is trivial to implement; it's just a couple lines of Ruby); how many of them do you think caught these flaws?
I have no idea what the utility of the public key is in the system you just described. Public key crypto adds susceptibility to attack; it doesn't ever really spare you from it. Here, you're vulnerable both to attacks on your HMAC verification and to implementation flaws in your more number-theoretic (and way more dangerous) public key code.
I wish I could go into more specifics for our implementation and what it is we do.
Either way the public/private key stuff is done using various "high" level libraries that make reasonable choices and are audited, so it is not code that we are implementing ourselves, nor is the HMAC. So long as there are no issues in the libraries I should be fairly good.
Thanks for the discussion :-).