Its a presentation about Colossus and the role it played to help in the cryptanalysis of the Lorenz cipher. It is regarded as "... the world's first programmable, electronic, digital computer, although it was programmed by switches and plugs and not by a stored program..."
The presentation has detail of analysis of the different cipher in use at the time. Also fascinating historical details of the technical work done, for example:
- Some of the breakthroughs in cryptanalysis were only possible because one day, one of the German Engima machine operators had to resend the same message twice, due to a transmission error. However he/she forgot to rotate the encoding mechanism.
- Colossus was considered so secret that after the war it was destroyed on purpose.
- The creator of Colossus managed to cross the border
and escape the German army just by a 3 hours difference.
> And occurring or believed likely to occur in a different cipher or code message
Does anyone know if TLS/HTTPS does padding or tries to alter the length of ciphertext? I ask because a specific length for a specific request that is known to be a certain Wikipedia page (for example: https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_...) means certain encrypted request's plaintext are known to an adversary. Is each encrypted network request's ciphertext different or padded to a new size?
AFAIK TLS doesn't make such attempts simply because that would make it quite inefficient. However, if you're using Tor (like you probably should if you want privacy for online browsing) the exit-node that fetches the site for you gets the leaky packet size, and the Tor cell -packets that transit from the exit node to you are static size (500 bytes IIRC). The number of packets can of course be quite revealing too, but all simultaneous data transfer over Tor adds noise to end-to-end correlation on your end.
This is a classic problem (traffic analysis) that in principle can only be solved by having the browser access random wikipedia pages in a continuous manner, to create cover traffic.
I'm no expert in cryptography, but don't most versions of TLS/HTTPS use RSA for encryption? Which in turn uses the private/public key methodology to prevent such attacks?
No AFAIK. The actual traffic is encrypted using a block cipher. Asymmetric crypto is only there to verify each peer's identity and establish a common secret for the symmetric cipher.
This is right - asymmetric crypto is awesome but just not anywhere near as fast as something like AES for chewing through chunks of data. So some anonymous asymmetric crypto (Diffie-Hellman or similar) is used to set up an encrypted channel, i.e set up a shared AES key, and then RSA is used to verify that the entity on the other end actually holds the private key for that subdomain. After that it’s AES pretty much all the way.
Yup that’s basically how it works. Usually when PFS is involved the keys are session based as opposed to using the same keypair for every session. This mitigates passive monitoring and future private key compromise/legal pressure permitting historic decryption of sniffed TLS sessions.
They use a form of key exchange (using RSA, Diffie-Hellman etc) to transfer the (symmetric) key used by the symmetric block cipher. So typically ECDHE and AES-256-GCM for e.g. so the symmetric key is wrapped.
Even in the 90s, SSL (and PGP) used hybrid encryption. The data is encrypted (and authenticated) using symmetric primitives and the symmetric keys are exchanged or established using asymmetric cryptography. Asymmetric cryptography is also used to authenticate the counter party.
RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated. These days RSA is only used in digital signatures (which are not encryption) while key exchange is done using Diffie Hellman (specifically ECDHE).
CBC mode cipher suites used to add up to 8 bytes of padding (for deprecated 3DES) and up to 16 bytes of padding for AES, but the mac-then-encrypt TLS construction turned out to be very hard to implement correctly, so TLS 1.3 only allows modes based on CTR (AES GCM, CCM and ChaCha20-Poly1305) so not even minimal padding is done.
"These days RSA is only used in digital signatures (which are not encryption)"
AFAIK digital signatures are created by encrypting the hash of the plaintext (be it content ofthe certificate or a message or whatnot). But yeah, RSA isn't really used for key exchanges due to it lacking forward secrecy. There are exceptions to this unfortunately, such as Apple's iMessage which is decades behind in cryptographic innovation.
Please don't repeat terrible 90s pedagogy about RSA. Even in RSA, the padding for signatures and for encryption is different (for very important reasons). The fact that RSA encryption and RSA signatures share code (but are not identical) is just a quirk of RSA that instead of making the thing simpler to explain made it harder to explain well - people think this generalizes and try to understand where is the encryption in Ed25519 or whatever and are very confused.
If you want to point out the difference between "public key operation" (encrypt, verify) and "private key operation"
(decrypt, sign), use those terms. That makes sense and the distinction is important.
People end up with basically misinformation in their heads and other people on stackoverflow (and IRL) spend lots of time trying to sort them out. You just made the problem a little worse. Please don't do that.
While you are right in principle (generally: all encryption schemes explicitly exclude message length from their confidentiality claims), in practice, some parts are user-specific (such as the username if you are logged in, and which compression algorithm is selected).
That said, the ideal encryption tunnel is one which is always running, transmitting a random stream that is likely encrypting a sequence of zeroes most of the time. The energy consumption may be problematic however.
Older CBC cipher suites padded to the next multiple of 16 bytes (for AES). TLS 1.3 doesn’t support these anymore but added a more general padding mechanism [1]. I don’t know whether any browser actually uses it though.
There is no such mechanism in TLS, but HTTP Range header and wikipedia supports it.
So if you want to be protected agains this side-channel problem you can use Connection: Keep-Alive header along with Range header to split each request into a few Range requests.
As TLS pads data to the block size you can introduce uncertainty of 0-8 bytes per chunk. Put some random delays between chunks and while it will be slower and with a bit higher overhead passive attacker won't tell if you're requesting one article in chunks or a few other.
20 comments
[ 2.5 ms ] story [ 52.8 ms ] threadThe presentation has detail of analysis of the different cipher in use at the time. Also fascinating historical details of the technical work done, for example:
- Some of the breakthroughs in cryptanalysis were only possible because one day, one of the German Engima machine operators had to resend the same message twice, due to a transmission error. However he/she forgot to rotate the encoding mechanism.
- Colossus was considered so secret that after the war it was destroyed on purpose.
- The creator of Colossus managed to cross the border and escape the German army just by a 3 hours difference.
Does anyone know if TLS/HTTPS does padding or tries to alter the length of ciphertext? I ask because a specific length for a specific request that is known to be a certain Wikipedia page (for example: https://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_...) means certain encrypted request's plaintext are known to an adversary. Is each encrypted network request's ciphertext different or padded to a new size?
RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated. These days RSA is only used in digital signatures (which are not encryption) while key exchange is done using Diffie Hellman (specifically ECDHE).
CBC mode cipher suites used to add up to 8 bytes of padding (for deprecated 3DES) and up to 16 bytes of padding for AES, but the mac-then-encrypt TLS construction turned out to be very hard to implement correctly, so TLS 1.3 only allows modes based on CTR (AES GCM, CCM and ChaCha20-Poly1305) so not even minimal padding is done.
s/does/doesn't/ there.
AFAIK digital signatures are created by encrypting the hash of the plaintext (be it content ofthe certificate or a message or whatnot). But yeah, RSA isn't really used for key exchanges due to it lacking forward secrecy. There are exceptions to this unfortunately, such as Apple's iMessage which is decades behind in cryptographic innovation.
If you want to point out the difference between "public key operation" (encrypt, verify) and "private key operation" (decrypt, sign), use those terms. That makes sense and the distinction is important.
People end up with basically misinformation in their heads and other people on stackoverflow (and IRL) spend lots of time trying to sort them out. You just made the problem a little worse. Please don't do that.
Here is an actual cryptographer explaining: https://security.stackexchange.com/a/87373/70830
While you are right in principle (generally: all encryption schemes explicitly exclude message length from their confidentiality claims), in practice, some parts are user-specific (such as the username if you are logged in, and which compression algorithm is selected).
That said, the ideal encryption tunnel is one which is always running, transmitting a random stream that is likely encrypting a sequence of zeroes most of the time. The energy consumption may be problematic however.
[1]: https://datatracker.ietf.org/doc/html/rfc8446#section-5.4
So if you want to be protected agains this side-channel problem you can use Connection: Keep-Alive header along with Range header to split each request into a few Range requests.
As TLS pads data to the block size you can introduce uncertainty of 0-8 bytes per chunk. Put some random delays between chunks and while it will be slower and with a bit higher overhead passive attacker won't tell if you're requesting one article in chunks or a few other.
And all this can be implemented client-side.
nah worries...