5 ms·

without formal methods it's impossible to fully test crypto implementations, such as ECDH, because the number of possible inputs are enormous. bugs in small pro

without formal methods it's impossible to fully test crypto implementations, such as ECDH, because the number of possible inputs are enormous. bugs in small proportion of inputs can lead to fault attacks. and furthermore side channel attacks are very common.

imaginenore 11y ago
That's true of every crypto implementation.
- vitriol83 11y ago
  Sure, that's why I think there's an argument to use ones which are more 'battle tested'.
  - amaranth 11y ago
    That's not an option here though because of the poor performance of Go's C FFI infrastructure. It's like Java in this regard, unless you're handing off large batches of work to the C level all at once it's more efficient to just do the work in Go. Except in this case pure Go isn't fast enough either thus assembly.
    - Twirrim 11y ago
      Go's existing crypto library is far from battle tested either (as well as being comparatively slow)
      - tptacek 11y ago
        Go's crypto library is probably the best of all the "standard library" crypto implementations. The modal standard crypto library among other languages is a set of bindings to OpenSSL.
        lmm 11y ago
        The most popular language around is still Java, I think? Which comes with a reputable, non-OpenSSL crypto implementation in its standard library.
        TheLoneWolfling 11y ago
        Except that it's quite literally impossible to ensure data-independent timing in Java - or, for that matter, in any language that does optimizations without a way to disable them. Yes, this includes standard-compliant C / C++, ironically enough. JITters are especially bad for this - what is data-independent today may not be data-independent tomorrow. Or even in a couple minutes when it decides to re-optimize. You ultimately have to dip down to assembly, or something that can be relied on to not do data-dependent optimizations, to ensure resilience against timing attacks. JNI can work, as can inline assembly in things like C / C++, or specifying compilers. But that's just punting things to another language. And you lose portability, among other things. Or worse, you end up with something that looks like language X, and is valid code in language X, but breaks evilly if it's ever run as though it was in language X.
        tptacek 11y ago
        No, I do not think Java's crypto library is as well regarded as Golang's. For example, didn't Java SSL recently manage to reincarnate the Bleichenbacher padding oracle?
        tedunangst 11y ago
        And the message skipping vuln, which put basically all TLS clients in the "no security" category.
        wolf550e 11y ago
        For those wondering: https://www.smacktls.com/#skip https://www.smacktls.com/#skip
        wolf550e 11y ago

imaginenore 11y ago

That's true of every crypto implementation.

vitriol83 11y ago
Sure, that's why I think there's an argument to use ones which are more 'battle tested'.
- amaranth 11y ago
  That's not an option here though because of the poor performance of Go's C FFI infrastructure. It's like Java in this regard, unless you're handing off large batches of work to the C level all at once it's more efficient to just do the work in Go. Except in this case pure Go isn't fast enough either thus assembly.
  - Twirrim 11y ago
    Go's existing crypto library is far from battle tested either (as well as being comparatively slow)
    - tptacek 11y ago
      Go's crypto library is probably the best of all the "standard library" crypto implementations. The modal standard crypto library among other languages is a set of bindings to OpenSSL.
      - lmm 11y ago
        The most popular language around is still Java, I think? Which comes with a reputable, non-OpenSSL crypto implementation in its standard library.
        TheLoneWolfling 11y ago
        Except that it's quite literally impossible to ensure data-independent timing in Java - or, for that matter, in any language that does optimizations without a way to disable them. Yes, this includes standard-compliant C / C++, ironically enough. JITters are especially bad for this - what is data-independent today may not be data-independent tomorrow. Or even in a couple minutes when it decides to re-optimize. You ultimately have to dip down to assembly, or something that can be relied on to not do data-dependent optimizations, to ensure resilience against timing attacks. JNI can work, as can inline assembly in things like C / C++, or specifying compilers. But that's just punting things to another language. And you lose portability, among other things. Or worse, you end up with something that looks like language X, and is valid code in language X, but breaks evilly if it's ever run as though it was in language X.
        tptacek 11y ago
        No, I do not think Java's crypto library is as well regarded as Golang's. For example, didn't Java SSL recently manage to reincarnate the Bleichenbacher padding oracle?
        tedunangst 11y ago
        And the message skipping vuln, which put basically all TLS clients in the "no security" category.
        wolf550e 11y ago
        For those wondering: https://www.smacktls.com/#skip https://www.smacktls.com/#skip
        wolf550e 11y ago