Hacker News Reader

Comment by wyday | Hacker News Reader

>> "Hard to justify going to the trouble of encrypting your backup."

Huh? If you're "encrypting" using SHA, I've got some bad news about those backups of yours.

I think GP was taking about the general nature of “previously assumed to be unbreakable” methods being broken. Not sure if he has implying using a checksum also for encryption

What do you mean by "previously assumed to be unbreakable" ? SHA-1 has been known to be unsafe for a dozen years, we just went from "assumed to be breakable" to "yep, definitely breakable, here's how one exact attack will work".

But backups have existed for more than a dozen years. And its replacements today, SHA-256 and SHA-3 will also be broken if you wait long enough.

I can see why backups might be needed for a dozen years, and I can see why encrypted backups might be needed, but outside plainly fake requirements like those of "national security" why would encrypted backups be needed for a dozen years? Aren't we throwing everything sensitive away after seven years? After that isn't it mostly about preserving history? Even things like balance sheets that might be sensitive today will be too out-of-date to be sensitive a dozen years from now.

The obvious counter-example is my library, however old my photos or music or videos are I'd like to keep them for as long as possible, and because they're private I'd like to keep them in an encrypted form

If you use SHA-256 to encrypt your backup, then I just need to steal your backup and wait 20 years, until that is cracked, and then I can decrypt your backup, even though today you’re using the “correct” encryption.

The GP was likely hinting at SHA1 being an hashing function, non an encryption function, so just applying sha* wouldn't produce a working backup

It probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.

You might be able to find bytes that result in your hash, but they probably won't be the same bytes you 'backed up'.

If the data is shorter than the hash shouldn't it be the same data I backed up with reasonably high probability?

No. http://matt.might.net/articles/counting-hash-collisions/

Can you explain the relevance? If I put N items randomly into >> N buckets the chance of there being a second item in a particular bucket is small (as opposed to there merely being a bucket with two items, as in the birthday "paradox").

That doesn't apply here, since the birthday paradox is about the existence of a collision, not that any particular sequence collides.

Most people in the room will still have unique birthdays even if one pair share theirs.

I guess you get (infinite?) many results which all have the same hash and one (or more) of them will be shorter than the hash.

If you're planning to brute-force count through 2^(128x8) possible bit inputs, it will be quite a few decades indeed. And you'll need a few spare solar systems to annihilate to get enough energy to drive your counting engine through that many states.

https://security.stackexchange.com/a/6149/1427

The idea is to wait for a preimage attack on sha, not brute force it.

As an aside, sha-1 is smaller than 128 bytes.

From my numerical experiments (I hope I didn't mess up...) using the random oracle model, the probability that a given key is collision-free is 99.6% if the input is one byte shorter than hash, 1/e if input is same size as hash and 6.6e-112 if the input is one byte longer than hash.

And this holds basically irrespective of key size.

To be excessively pedantic you can encrypt securely (but slowly for the SHA series) with a hash function of sufficient capacity by running the hash function in CTR mode. You turn it into a stream cipher. Ideally you also MAC the ciphertext, nonce, and other associated data. That's is pretty easy with such a hash function (either use HMAC or a MAC mode of the hash function if supported).

Salsa20 & ChaCha20 cores are hash functions (though not collision-resistant compression functions since it's not needed for their design goal and would be slower) run in CTR mode.[1]

[1] https://cr.yp.to/salsa20.html

> To be excessively pedantic

This is the best, most delicious, type of pedantry friend!

You're the best kind of pedantry friend!

(Just some more pedantry, friend.)

Ok man, now that's just over the top.

I'm refering to not being able to rely on encryption in the long term.

Hashing is a separate problem from encryption. There is no proof that one way functions (the idea behind hashing) even exist (by proving this, you would actually prove P!=NP, IIRC). Encryption has a slightly better track record of being broken. AES still holds its promise and is also secure against quantum computing (you might want longer keys, but that's it).

And if you want really, provably unbreakable encryption, there is still OTP. But then you'd need a key, that is as long as the data you want to encrypt.

The best known attack against AES reduces attack complexity by about two bits over brute force. Given the history of block ciphers, the idea that AES might not be broken in this life time is not uncommon.

Reply on news.ycombinator.com