Hacker News Reader

Comment by Rygian | Hacker News Reader

Thought experiment: if I use 512-bit encryption from cleartext to intermediate blob, and then encrypt that with 256-bit encryption, is there a way to determine, by looking only at the final ciphertext, that 512-bit encryption keys were used in the intermediate step?

View on HN

I suspect it would come down to rubber hose cryptanalytics. If caught, and forced to decrypt, what is it that you would decrypt with?

Things are banned, implicitly, only if you get caught, so I don't think this is a philosophical argument.

My interpretation as someone who is not an expert on cryptography:

The final cyphertext of an encryption system should be indistinguishable from noise - the less random the output looks, the more information an attacker gains.

The output of your 512-bit encryption should therefore look like noise already. Converting noise to noise should therefore result, predictably, in more noise. So I'm going to say "no, you can't tell".

Cryptography is specialized (and counterintuitive) enough that perhaps we should just let people who know what they're talking about respond rather than repeating or just making up what "feels right" to our lay interpretations of incredibly complex topics.

What we have been taught or what we understand about cryptography is just as important to discuss. What you said sounds a bit like "let the adults talk" and is condescending.

I know what I am talking about: above poster is correct.

Proper encryption, maximum compression, and random bytes are all indistinguishable, as they have maximum entropy.

I only failed 9th grade three times, so feel free to correct me.

It’s a tough grade.

> are all indistinguishable,

without additional information!

I can prove to you that you're seeing an encrypted message by giving you the decryption key, and I can prove to you that you're seeing compression by giving you the decompression algorithm.

However, there is no way to prove that random bytes are _really_ random.

>However, there is no way to prove that random bytes are _really_ random.

well of course, because the opposite is true, any string of bytes can by XOR'd to something meaningful.

https://en.wikipedia.org/wiki/One-time_pad

“20 years of abstinence-only cryptography education hasn’t gotten us anything but an endless supply of bad crypto in production systems”

Unless your "ciphertext" includes a header saying "this data in encrypted with 512-bit AES-cbc"

Instead of auditing the code/file format, it may be less error prone to just re-encrypt the entire file thereby hiding any metadata that the encryption program attaches.

In theory yes in practice crypto systems add additional data to assist in decryption and interoperability. Key size, algo, even key identifier are often added as meta data.

And that is before you get into less than perfect encryption.

They can reverse engineer the binary and see you do double encryption. If you care about this law, presumably at least one endpoint has physical presence in China.

Not necessarily. You can encrypt something twice with different keys. e.g. off the shelf zip archivers dont support 1024 bit keys, but who can stop you from writing a bash script that generates 10 keys using sha1 and a 'seed passphrase' and runs the zip archiver 10 times?

I don't think you even need the 256-bit encryption step? Unless you add metadata the cyphertext shouldn't reveal anything about the encryption method and should (ideally) look indistinguishable from random noise.

Except a 512-bit block cipher typically outputs a ciphertext that's 512-bits in length, revealing how large the key size was.

Either you assume that the attacker can break 256 bit encryption, then probably yes. Or you assume that they can't, then, why bother?

To avoid attracting their attention in the first place. They are not going to bother breaking every 256-bit-encrypted thing they see but as soon as they notice something obviously 512-bit-encrypted they go beat the key out of you.

Quick question, if encrypted data looks like noise, how can you tell apart 256-bit encrypted noise and 512-bit encrypted noise?

I don't think you can with a decent crypt. In practice most encrypted containers come with metadata and a header describing the type of encryption since the assumption is that it can only be decrypted with a key anyway. If you forget encryption parameters, this can become difficult even if you have the key.

In cryptanalysis it is normally assumed that the attacker knows the algorithm and encryption parameters aside the key.

It's dead simple: «You used encrypted connection today. It's encrypted with 10000024 bit key, which is forbidden by China. You can send your key to us to prove that you are innocent, or go to jail.»

I would expect they are interested in me or don’t care. If they are interested, they routinely break all comms and notice 512. If they aren’t interested they won’t bother to break 8 bit.

I’m not interesting so not an issue for me, but I would also assume that they can break much more than this and wouldn’t actually reveal their limit in such a policy. Kind of like how your boss quadruples your time estimate. If their policy says nothing over 256, then they likely have capability for more.

But I’d expect that usually these pass phrases can be any length as they are all getting beaten out of us when needed.

> I would expect they are interested in me or don’t care.

There are several degrees of interest. Essentially they are interested in everyone trying to hide anything from them and they probably understand people of real danger to them will do their best to look ordinary and mediocre.

> If their policy says nothing over 256, then they likely have capability for more.

Sounds reasonable but breaking 512 obviously is much harder than 256 and will take significant time and resources they don't really want to waste. They will rather force you to reveal the key and only break 512+ if they can't easily reach you physically or identify you in the first place.

Whenever you encounter data that you suspect is encrypted and you want to attempt to break that encryption you need to investigate and gather intelligence on the algorithms and data format used. You can't just hit in the dark at random.

This can be done covertly or overtly, the former being plain old spying, the latter may be as simple as detaining the people involved and seizing computers (especially in China...).

The data won't give it away, at least as long as the noise is sufficiently hidden with steganography and not just a mystery blob. But the tooling setup you use to access the cleartext with your passphrase, without starting from first principles each time, that setup might very much give it away if the system comes under serious scrutiny.

Note that there's a huge difference between "until proven guilty" and "until considered suspect": suddenly obscurity cannot be shrugged off at all, quite the opposite.

Presumely, the 256-bit limit was chosen because a 256-bit key can easily be bruteforced. So if authorities find out that any possible 256-bit key only yields garbage, they should know something is fishy.

Reply on news.ycombinator.com