5 ms·

>> "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

• tambourine_man 7y ago
  I'm refering to not being able to rely on encryption in the long term.
  • vbrandl 7y ago
    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.
    • blattimwind 7y ago
      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.
• LadyCailin 7y ago
  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.
  • riquito 7y ago
    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
    • gpm 7y ago
      It probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.
      • ksangeelee 7y ago
        You might be able to find bytes that result in your hash, but they probably won't be the same bytes you 'backed up'.
        • gpm 7y ago
          If the data is shorter than the hash shouldn't it be the same data I backed up with reasonably high probability?
          • pathseeker 7y ago
            No. http://matt.might.net/articles/counting-hash-collisions/ http://matt.might.net/articles/counting-hash-collisions/
            • monktastic1 7y ago
              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").
            • DuskStar 7y ago
              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.
              • deleted 7y ago
                [deleted]
• harikb 7y ago
  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
  • PeterisP 7y ago
    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".
    • rakoo 7y ago
      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.
      • jessaustin 7y ago
        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.
        • rakoo 7y ago
          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