3 ms·

Nobody is particularly worried about libcrypto. There would be little point in reimplementing it's functionality.

• tptacek 11y ago
  They aren't?
  • cperciva 11y ago
    Depends who "they" are. Bugs in the crypto code will compromise the cryptographic strength of the connection, revealing data or keys. Bugs in the protocol code will compromise the host which is running it. Both are bad, but I'd say that "remote root" trumps "side channel attack".
• alricb 11y ago
  libcrypto includes the OpenSSL ASN.1 code, which is worrying as all hell, e.g.: https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/asn1/tasn_dec.c;h=7a6414ad04761b5b355869c4fd8d095ce5ddbe6c;hb=HEAD https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/asn1/... Or any file in that directory.
  • imaginenore 11y ago
    Oh man, that code is just horrible. No comments on some of the functions, no comments on the input parameters and return values pretty much throughout. I really thought OpenSSL was in a much better shape.
    • deleted 11y ago
      [deleted]
    • jerf 11y ago
      Code that implements standards should be read with the standard open next to it. This code: https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/md5/md5_dgst.c;h=335126c76d8fdc7f59dd68b2bbe134216c68ae26;hb=HEAD https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/md5/m... looks like awful garbage, until you compare it to https://www.ietf.org/rfc/rfc1321.txt https://www.ietf.org/rfc/rfc1321.txt , and then you realize you don't really want comments or anything else cluttering up the implementation.
    • justizin 11y ago
      > I really thought OpenSSL was in a much better shape. Why?
  • tyho 11y ago
    I overlooked that, I was thinking of the crypto primitives there.