5 ms·

Author here, ask me anything.

bumblebritches5 6y ago
Can you elaborate on the details that makes crypto insecure? I'm writing a library called CryptographyIO and I want it to be secure.
baby 6y ago
why "cryptbe"? It sounds like you're from belgium
- xuki 6y ago
  He's from Vietnam, the blog title gave it away without reading the about section.
  - baby 6y ago
    I know Thai, just thought this was an interesting nickname :D
    - cryptbe 6y ago
      I'll tell you next time we meet ;-)
      - tptacek 6y ago
        Dave, you have to tell me once he tells you.
        baby 6y ago
        next time we run into each other :)
  - deleted 6y ago
    [deleted]
daenz 6y ago
For the very example-driven people, can you give a couple of examples of some of those non-obvious, subtle implementation details that completely destroy crypto schemes?
- cryptbe 6y ago
  For example, let's look at the IV. Symmetric encryption algorithms usually need an input called the initialization vector (IV), but different algorithms have different requirements. AES-CBC requires unpredictability, but AES-CTR (and AES-GCM) require uniqueness. Misunderstanding of these requirements have led to real world attacks, see for example BEAST or https://eprint.iacr.org/2016/475.pdf https://eprint.iacr.org/2016/475.pdf.
- ridaj 6y ago
  Here's a random example. HMAC is frequently used in security protocols to generate more keys from a master key (for example, to generate temporary keys from a session key). The input to HMAC is (internally) padded with null bytes (<NUL>) before processing, so that for example "abc" and "abc<NUL><NUL><NUL>" will generate the same result. You may need to be aware of that padding when designing protocols that rely on HMAC, in order to avoid certain weaknesses. https://crypto.stackexchange.com/q/52161 https://crypto.stackexchange.com/q/52161
- ridaj 6y ago
  As a very basic but very common example, I've seen many non-experts jump to encryption or symmetric crypto signatures whenever they want to prevent tampering with data, when what they needed was a simple integrity check. Or, they want to do an integrity check, but don't realize that they need a canonical serialization algorithm for their implementation. So they use a standard, non-canonical serialization algorithm, and most of the time it works (because these algorithms typically don't vary that much, especially across tests on a single machine), but that's dangerous because it fails randomly in real life. See more discussion here https://latacora.micro.blog/2019/07/24/how-not-to.html https://latacora.micro.blog/2019/07/24/how-not-to.html
- fractionalhare 6y ago
  Here is a (far from complete) list of fairly common mistakes: https://github.com/SalusaSecondus/CryptoGotchas https://github.com/SalusaSecondus/CryptoGotchas
ShorsHammer 6y ago
Given how long side channels and timing attacks have been causing problems why haven't compilers tried to meet the requirements of crypto authors and implementors? Feels like people are fighting against compiler optimisations more than ever.
- ganafagol 6y ago
  Crypto code and non-crypto code have different requirements. For compiling non-crypto code you often want the fastest code that still matches the language spec. "Fast" is usually even relative to target platform. For crypto code, you need a very narrowly defined abstract machine that you program against and since that's a much stronger requirement than what the language is defined for, you take the next best thing by turning off all optimizations and hoping you understand well enough how your compiler generates code. In other words, they already do their best by giving authors control over how much optimization is applied. Anything beyond that is a language design problem, not compiler construction problem.
andrewnicolalde 6y ago
I notice at the end you imply that a senior software engineer claiming they weren’t rolling their own crypto because they used OpenSSL was doing so in error. What sorts of issues could arise if they were using OpenSSL to handle cryptography? Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand?
- cryptbe 6y ago
  >Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand? Yes. They wanted to encrypt some URL parameters with AES-ECB.
  - deleted 6y ago
    [deleted]
camhart 6y ago
Could you share an opinion on using products like https://virgilsecurity.com https://virgilsecurity.com?

Can you elaborate on the details that makes crypto insecure? I'm writing a library called CryptographyIO and I want it to be secure.

baby 6y ago

why "cryptbe"? It sounds like you're from belgium

xuki 6y ago
He's from Vietnam, the blog title gave it away without reading the about section.
- baby 6y ago
  I know Thai, just thought this was an interesting nickname :D
  - cryptbe 6y ago
    I'll tell you next time we meet ;-)
    - tptacek 6y ago
      Dave, you have to tell me once he tells you.
      - baby 6y ago
        next time we run into each other :)
- deleted 6y ago
  [deleted]

daenz 6y ago

For the very example-driven people, can you give a couple of examples of some of those non-obvious, subtle implementation details that completely destroy crypto schemes?

cryptbe 6y ago
For example, let's look at the IV. Symmetric encryption algorithms usually need an input called the initialization vector (IV), but different algorithms have different requirements. AES-CBC requires unpredictability, but AES-CTR (and AES-GCM) require uniqueness. Misunderstanding of these requirements have led to real world attacks, see for example BEAST or https://eprint.iacr.org/2016/475.pdf https://eprint.iacr.org/2016/475.pdf.
ridaj 6y ago
Here's a random example. HMAC is frequently used in security protocols to generate more keys from a master key (for example, to generate temporary keys from a session key). The input to HMAC is (internally) padded with null bytes (<NUL>) before processing, so that for example "abc" and "abc<NUL><NUL><NUL>" will generate the same result. You may need to be aware of that padding when designing protocols that rely on HMAC, in order to avoid certain weaknesses. https://crypto.stackexchange.com/q/52161 https://crypto.stackexchange.com/q/52161
ridaj 6y ago
As a very basic but very common example, I've seen many non-experts jump to encryption or symmetric crypto signatures whenever they want to prevent tampering with data, when what they needed was a simple integrity check. Or, they want to do an integrity check, but don't realize that they need a canonical serialization algorithm for their implementation. So they use a standard, non-canonical serialization algorithm, and most of the time it works (because these algorithms typically don't vary that much, especially across tests on a single machine), but that's dangerous because it fails randomly in real life. See more discussion here https://latacora.micro.blog/2019/07/24/how-not-to.html https://latacora.micro.blog/2019/07/24/how-not-to.html
fractionalhare 6y ago
Here is a (far from complete) list of fairly common mistakes: https://github.com/SalusaSecondus/CryptoGotchas https://github.com/SalusaSecondus/CryptoGotchas

ShorsHammer 6y ago

Given how long side channels and timing attacks have been causing problems why haven't compilers tried to meet the requirements of crypto authors and implementors? Feels like people are fighting against compiler optimisations more than ever.

ganafagol 6y ago
Crypto code and non-crypto code have different requirements. For compiling non-crypto code you often want the fastest code that still matches the language spec. "Fast" is usually even relative to target platform. For crypto code, you need a very narrowly defined abstract machine that you program against and since that's a much stronger requirement than what the language is defined for, you take the next best thing by turning off all optimizations and hoping you understand well enough how your compiler generates code. In other words, they already do their best by giving authors control over how much optimization is applied. Anything beyond that is a language design problem, not compiler construction problem.

andrewnicolalde 6y ago

I notice at the end you imply that a senior software engineer claiming they weren’t rolling their own crypto because they used OpenSSL was doing so in error. What sorts of issues could arise if they were using OpenSSL to handle cryptography? Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand?

cryptbe 6y ago
>Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand? Yes. They wanted to encrypt some URL parameters with AES-ECB.
- deleted 6y ago
  [deleted]

camhart 6y ago

Could you share an opinion on using products like https://virgilsecurity.com https://virgilsecurity.com?