4 ms·

How related are these encryption vulnerabilities to encryption we may do in our own software (stuff that necessarily doesn't depend on SSL connections)? As in,

• agwa 13y ago
  The RC4 vulnerability is in the algorithm, not in TLS. Do not use RC4 in your own software. (If you absolutely must, you can avoid this vulnerability by using a variant of RC4 that discards the first several thousand bytes of keystream, but please just use something else.) The AES-CBC vulnerabilities are specific to TLS, so as long as you don't repeat the same mistakes TLS made, you won't have the same vulnerabilities. Specifically, encrypt-then-MAC (instead of MAC-then-encrypt) to avoid padding oracle attacks like Lucky 13, and actually choose new IVs for each message instead of using the previous message's last ciphertext block (to avoid BEAST). Or better yet, use a high-level crypto library that doesn't make you worry about this stuff.
  • bennyg 13y ago
    Yeah the one I'm using is encrypt-then-MAC for AES-CBC, so I guess I'm good in that aspect.
• tptacek 13y ago
  They are highly related. For instance, if you are using AES-CBC in your own program, but are not composing it with a MAC properly, you too are likely vulnerable to a padding oracle attack, and that attack is likely to be much easier to execute than Lucky 13. In reality, you can safely look at TLS as a "best case" scenario; the number of vulnerabilities that commonly arise from homegrown crypto ("using AES in a self-contained program") are a large superset of the ones that have arisen in TLS.