6 ms·

Actually, depending on the mode of operation it may be about as secure as AES in ECB... That's it, not secure at all. Using a well known algorithm is such a sm

by brohee 14y ago

Actually, depending on the mode of operation it may be about as secure as AES in ECB... That's it, not secure at all. 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).

tptacek 14y ago
Whoah. Hold on. OpenSSL EVPxxx claims to be a "high-level interface", but isn't one. Here's some acid tests for high-level libraries: * 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.
- brohee 14y ago
  I get your point, but pretty often you must respect some general mandate (e.g. must use this approved chaining mode, this certified PRNG...) and OpenSSL EVP comes very handy if you don't find a library doing exactly what you need. It still shields you quite a bit from the lower level mistakes to be made. What's your go to solution?
  - tptacek 14y ago
    Keyczar. 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.
    - X-Istence 14y ago
      Except that to implement TLS for example you NEED to type OpenSSL into your code, and to set the allowed ciphers for the connection you need to type AES. 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.
      - tptacek 14y ago
        If you're implementing TLS using OpenSSL, you aren't using it to do custom crypto for your app. 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.
        X-Istence 14y ago
        So don't tell us how to use the primitives, tell us in high level overview of common mistakes that are made so that we can watch out for those. Some of us simply don't have the luxury of using Keyczar. 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.
        tptacek 14y ago
        Getting people not to make dumb crypto mistakes, by getting them to either (a) not write crypto code in the first place, or (b) if they have to encrypt stuff, to use GPG to do it, or (c) at the very least, to use a library interface that has been bulletproofed like Keyczar or cryptlib --- that seems way more productive than leading people down a garden path of the individual flaws I know how to test for, and letting them think they're secure.
- X-Istence 14y ago
  Why shouldn't the IV be available to the callers? How are you supposed to implement cryptography where this is not available so that you can send data from one source to another (such as encrypted using a private/public key system) so that they have the same IV for decryption. 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.
  - tptacek 14y ago
    Because encryption without authentication in most systems is pointless? 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.
    - X-Istence 14y ago
      My code is not on Github because it is proprietary code, so unfortunately I can't send you a link to have a look at it. 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_Revision1_Mar08-2007.pdf http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A...

by brohee 14y ago

tptacek 14y ago

Whoah. Hold on. OpenSSL EVPxxx claims to be a "high-level interface", but isn't one. Here's some acid tests for high-level libraries: * 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.

brohee 14y ago
I get your point, but pretty often you must respect some general mandate (e.g. must use this approved chaining mode, this certified PRNG...) and OpenSSL EVP comes very handy if you don't find a library doing exactly what you need. It still shields you quite a bit from the lower level mistakes to be made. What's your go to solution?
- tptacek 14y ago
  Keyczar. 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.
  - X-Istence 14y ago
    Except that to implement TLS for example you NEED to type OpenSSL into your code, and to set the allowed ciphers for the connection you need to type AES. 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.
    - tptacek 14y ago
      If you're implementing TLS using OpenSSL, you aren't using it to do custom crypto for your app. 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.
      - X-Istence 14y ago
        So don't tell us how to use the primitives, tell us in high level overview of common mistakes that are made so that we can watch out for those. Some of us simply don't have the luxury of using Keyczar. 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.
        tptacek 14y ago
        Getting people not to make dumb crypto mistakes, by getting them to either (a) not write crypto code in the first place, or (b) if they have to encrypt stuff, to use GPG to do it, or (c) at the very least, to use a library interface that has been bulletproofed like Keyczar or cryptlib --- that seems way more productive than leading people down a garden path of the individual flaws I know how to test for, and letting them think they're secure.
X-Istence 14y ago
Why shouldn't the IV be available to the callers? How are you supposed to implement cryptography where this is not available so that you can send data from one source to another (such as encrypted using a private/public key system) so that they have the same IV for decryption. 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.
- tptacek 14y ago
  Because encryption without authentication in most systems is pointless? 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.
  - X-Istence 14y ago
    My code is not on Github because it is proprietary code, so unfortunately I can't send you a link to have a look at it. 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_Revision1_Mar08-2007.pdf http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A...