4 ms·

> "jury is out" One advantage of a jury being out is that someday said jury can come back in and return a verdict. > as if someone was ever going to publish a

> "jury is out" One advantage of a jury being out is that someday said jury can come back in and return a verdict. > as if someone was ever going to publish a cryptanalytic result showing bcrypt to be worse than SHA1. SHA-1 has a formal specification, an RFC, a reference implementation, implementation guidance, and comprehensive test vectors published. To date, bcrypt is lacking some of those things. And yes, bcrypt has gotten pwned worse than SHA-1 as a result: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483

tptacek 14y ago
Give me a break. That's an application implementation flaw, and one no standard could have prevented. It's like saying that insufficient cryptanalysis is responsible for the OpenSSL RCEs. Again: I'm not really torn. It's a good thing you're all doing this. The jury is not really out on bcrypt, though.
- marshray 14y ago
  one no standard could have prevented Then I'm sure you'll have no trouble* finding similar vulnerabilities introduced by implementation flaws of any NIST (or even IETF) defined algorithms. *Note: sarcasm.
  - jgeralnik 14y ago
    How about this: http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1 http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-...? Granted, these were just candidates and not actually NIST defined algorithms, but the point stands that algorithms can be fine while standard implementations have bugs.
    - marshray 14y ago
      Those were round 1 submissions, not even close to being "standard implementations". Which proves my point that the standardization process works to minimize implementation bugs in implementations of the standard.
      - tptacek 14y ago
        NIST standardization sure didn't help SHA2: http://mail-index.netbsd.org/tech-security/2009/07/28/msg000250.html http://mail-index.netbsd.org/tech-security/2009/07/28/msg000... You're just wrong about this point, Marsh. You are very smart and often right, but not invariably so.
        marshray 14y ago
        OK, so here's the patch to the bug in question: http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.17&r2=1.18&only_with_tag=MAIN http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash... + /* The state and buffer size are driven by SHA256, not by SHA224. */ memcpy(context->state, sha224_initial_hash_value, - (size_t)(SHA224_DIGEST_LENGTH)); - memset(context->buffer, 0, (size_t)(SHA224_BLOCK_LENGTH)); + (size_t)(SHA256_DIGEST_LENGTH)); + memset(context->buffer, 0, (size_t)(SHA256_BLOCK_LENGTH)); The NetBSD code was confused about which algorithm it was implementing. This can hardly be used to generalize about vulnerabilities in specific NIST approved algorithms. You're just wrong about this point, Marsh. You are very smart and often right, but not invariably so. So even if we allow this example as meeting my test of similar vulnerabilities introduced by implementation flaws of any NIST (or even IETF) defined algorithms I can still claim that this bug that existed in NetBSD only for 3 months in the spring of 2009 is the exception which proves the rule. It doesn't compare at all in scope to http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 in terms of the length of time, number of systems affected, or number of credentials created with weak cypto. EDIT: Sorry, I'm looking at the wrong patch. It appears that at the time indicated in the advisory, a bunch of other stuff was added to the source tree. Either I'm missing something obvious or there's a bit of misdirection going on. For example, it says: *"The overflow occurs at the time the hash init function is called (e.g. SHA256_Init). The init functions then pass the wrong size for the context as an argument to the memset function which then overwrites 4 bytes of the memory buffer located after the one holding the context." and "fixed: NetBSD-4 branch: Jul 22, 2009" But the diffs of 2009-07-22 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sha2.h.diff?r1=1.1.4.1&r2=1.1.4.2&only_with_tag=netbsd-4 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sha2.h.diff?... http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.2.4.4&r2=1.2.4.5&only_with_tag=netbsd-4 http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash... don't seem to affect the memset call in SHA256_Init() at all or the size of the structure.
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
  - tptacek 14y ago
    Oh, you mean like potential remote code execution in AES?
    - jgeralnik 14y ago
      For reference, it looks like he's referring to this: http://freecode.com/articles/suse-new-krb5-packages-fix-remote-code-execution-5 http://freecode.com/articles/suse-new-krb5-packages-fix-remo...
      - tptacek 14y ago
        If I wanted to play dirty, I'd have mentioned ASN.1. :)
        thirsteh 14y ago
        Or allowing \0 in X.509 fields.
        marshray 14y ago
        I agree, ASN.1 sucks in terms of implementation in security-critical contexts. But it's not a NIST or IETF standard, so it doesn't count. It's from ISO/IEC/ITU.
      - marshray 14y ago
        Do you have a link to the code with the bug? I'll bet that "Specially crafted AES and RC4 packets" does not actually refer to the implementation of a NIST standard algorithm, just its usage in a context outside of such a standard.

tptacek 14y ago

Give me a break. That's an application implementation flaw, and one no standard could have prevented. It's like saying that insufficient cryptanalysis is responsible for the OpenSSL RCEs. Again: I'm not really torn. It's a good thing you're all doing this. The jury is not really out on bcrypt, though.

marshray 14y ago
one no standard could have prevented Then I'm sure you'll have no trouble* finding similar vulnerabilities introduced by implementation flaws of any NIST (or even IETF) defined algorithms. *Note: sarcasm.
- jgeralnik 14y ago
  How about this: http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1 http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-...? Granted, these were just candidates and not actually NIST defined algorithms, but the point stands that algorithms can be fine while standard implementations have bugs.
  - marshray 14y ago
    Those were round 1 submissions, not even close to being "standard implementations". Which proves my point that the standardization process works to minimize implementation bugs in implementations of the standard.
    - tptacek 14y ago
      NIST standardization sure didn't help SHA2: http://mail-index.netbsd.org/tech-security/2009/07/28/msg000250.html http://mail-index.netbsd.org/tech-security/2009/07/28/msg000... You're just wrong about this point, Marsh. You are very smart and often right, but not invariably so.
      - marshray 14y ago
        OK, so here's the patch to the bug in question: http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.17&r2=1.18&only_with_tag=MAIN http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash... + /* The state and buffer size are driven by SHA256, not by SHA224. */ memcpy(context->state, sha224_initial_hash_value, - (size_t)(SHA224_DIGEST_LENGTH)); - memset(context->buffer, 0, (size_t)(SHA224_BLOCK_LENGTH)); + (size_t)(SHA256_DIGEST_LENGTH)); + memset(context->buffer, 0, (size_t)(SHA256_BLOCK_LENGTH)); The NetBSD code was confused about which algorithm it was implementing. This can hardly be used to generalize about vulnerabilities in specific NIST approved algorithms. You're just wrong about this point, Marsh. You are very smart and often right, but not invariably so. So even if we allow this example as meeting my test of similar vulnerabilities introduced by implementation flaws of any NIST (or even IETF) defined algorithms I can still claim that this bug that existed in NetBSD only for 3 months in the spring of 2009 is the exception which proves the rule. It doesn't compare at all in scope to http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 in terms of the length of time, number of systems affected, or number of credentials created with weak cypto. EDIT: Sorry, I'm looking at the wrong patch. It appears that at the time indicated in the advisory, a bunch of other stuff was added to the source tree. Either I'm missing something obvious or there's a bit of misdirection going on. For example, it says: *"The overflow occurs at the time the hash init function is called (e.g. SHA256_Init). The init functions then pass the wrong size for the context as an argument to the memset function which then overwrites 4 bytes of the memory buffer located after the one holding the context." and "fixed: NetBSD-4 branch: Jul 22, 2009" But the diffs of 2009-07-22 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sha2.h.diff?r1=1.1.4.1&r2=1.1.4.2&only_with_tag=netbsd-4 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sha2.h.diff?... http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.2.4.4&r2=1.2.4.5&only_with_tag=netbsd-4 http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash... don't seem to affect the memset call in SHA256_Init() at all or the size of the structure.
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
- tptacek 14y ago
  Oh, you mean like potential remote code execution in AES?
  - jgeralnik 14y ago
    For reference, it looks like he's referring to this: http://freecode.com/articles/suse-new-krb5-packages-fix-remote-code-execution-5 http://freecode.com/articles/suse-new-krb5-packages-fix-remo...
    - tptacek 14y ago
      If I wanted to play dirty, I'd have mentioned ASN.1. :)
      - thirsteh 14y ago
        Or allowing \0 in X.509 fields.
      - marshray 14y ago
        I agree, ASN.1 sucks in terms of implementation in security-critical contexts. But it's not a NIST or IETF standard, so it doesn't count. It's from ISO/IEC/ITU.
    - marshray 14y ago
      Do you have a link to the code with the bug? I'll bet that "Specially crafted AES and RC4 packets" does not actually refer to the implementation of a NIST standard algorithm, just its usage in a context outside of such a standard.