4 ms·

ECB mode somehow still gets used, Zoom also did it. I think this is a result of many developers not knowing much about encryption and then selecting the simples

ECB mode somehow still gets used, Zoom also did it. I think this is a result of many developers not knowing much about encryption and then selecting the simplest option from their language's standard library.

owenmarshall 4y ago
Because I always want to identify the solution when we point to the problem: https://doc.libsodium.org/ https://doc.libsodium.org/ http://noiseprotocol.org/ http://noiseprotocol.org/
- eternityforest 4y ago
  Also TLS and SSH for data in transport.
bawolff 4y ago
Zoom at least has the excuse that its more convinent if you are possibly dropping frames and need random access decryption (still really not acceptable). LastPass does not even have that.
- robryk 4y ago
  CTR with no authentication is strictly better than EBC with no authentication in that case. Similarly, CTR-then-MAC (with MACs being e.g. per packet) is strictly better than EBC-then-MAC.
  - upofadown 4y ago
    Missing (or duplicating) a block in the CTR (counter) block cipher mode messes up the alignment of the count. Then everything after that comes out as random garbage. CTR is not a very robust block cipher mode...
    - tptacek 4y ago
      Missing or duplicating a block anywhere in a ciphertext should completely prevent decryption; that's how authenticated encryption works. The idea that some cipher modes are more or less resilient to corruption is, for the most part, a discredited 1990s idea.
      - robryk 4y ago
        In this setup we want to be able to decode a cipherstream with holes into a plainstream with holes. This is very much possible with CTR-MAC, as long as MAC is done on some finitely-sized segments.
        tptacek 4y ago
        That is a problem that is generally handled at a higher level than the block cipher mode.
    - robryk 4y ago
      As long as you simply transmit the count in the packet this is not an issue. You mostly have to do that anyway, because packets can be reordered and you want to stitch them together in order (with holes).

owenmarshall 4y ago

Because I always want to identify the solution when we point to the problem: https://doc.libsodium.org/ https://doc.libsodium.org/ http://noiseprotocol.org/ http://noiseprotocol.org/

eternityforest 4y ago
Also TLS and SSH for data in transport.

bawolff 4y ago

Zoom at least has the excuse that its more convinent if you are possibly dropping frames and need random access decryption (still really not acceptable). LastPass does not even have that.

robryk 4y ago
CTR with no authentication is strictly better than EBC with no authentication in that case. Similarly, CTR-then-MAC (with MACs being e.g. per packet) is strictly better than EBC-then-MAC.
- upofadown 4y ago
  Missing (or duplicating) a block in the CTR (counter) block cipher mode messes up the alignment of the count. Then everything after that comes out as random garbage. CTR is not a very robust block cipher mode...
  - tptacek 4y ago
    Missing or duplicating a block anywhere in a ciphertext should completely prevent decryption; that's how authenticated encryption works. The idea that some cipher modes are more or less resilient to corruption is, for the most part, a discredited 1990s idea.
    - robryk 4y ago
      In this setup we want to be able to decode a cipherstream with holes into a plainstream with holes. This is very much possible with CTR-MAC, as long as MAC is done on some finitely-sized segments.
      - tptacek 4y ago
        That is a problem that is generally handled at a higher level than the block cipher mode.
  - robryk 4y ago
    As long as you simply transmit the count in the packet this is not an issue. You mostly have to do that anyway, because packets can be reordered and you want to stitch them together in order (with holes).