241–250 of 369 posts
Earlier quoted context omitted.
So should we do that, as well as keep finding new algorithms?
Concatenating two hashes is an algorithm. Mathematically concatenating two 128 bit hashes is not any stronger than a single 256 bit hash (and is likely weaker), but if it’s all you have (or all you can afford to compute) two weak hashes is definitely much better than one.
Earlier quoted context omitted.
Why do SHA-512/160 and SHA-512/128 not exist? They could be useful as drop-in replacements for SHA1 and MD5.
Because 224 bits is considered the minimum safe output length for a general purpose hash function. So they'd be drop-in replacements but still wouldn't be safe. Safer than MD5/SHA1, but not actually safe. So rather than push off getting people to make things actually safe by providing a footgun NIST just didn't do that.
Considered by whom?
General questions: (edit: these are indeed general questions, not just about SHA1) Has anyone else been worried about data deduplication done by storage and/or backup systems, considering that they usually use hashes to detect data blocks that are "the same" (without additional metadata) and avoid storing those "duplicate data blocks" again? Doesn't this seem far worse when you also consider that systems like Dropbox…
are there any systems that do sha-1 for dedup? I am only aware of sha-256.
Earlier quoted context omitted.
There's an MC Frontalot song called "Secrets from the Future" and the refrain is "You can't hide secrets from the future." It's something of a useful mantra to remind oneself that if "the future" is a part of your threat model, yes your encryption likely isn't enough because on a long enough timescale it is likely "the future" will crack it. As with any other security issue, the question is "what is your threat model…
The point about archeologists is a good one because it speaks to motive. In general, we should be very supportive of the efforts of distant historians who want to understand what humanity used to be like. We should not WANT to hide secrets from a sufficiently far future. I can't think of any secret that deserves to be hidden from them for any reason besides perhaps modesty.
Earlier quoted context omitted.
There's an MC Frontalot song called "Secrets from the Future" and the refrain is "You can't hide secrets from the future." It's something of a useful mantra to remind oneself that if "the future" is a part of your threat model, yes your encryption likely isn't enough because on a long enough timescale it is likely "the future" will crack it. As with any other security issue, the question is "what is your threat model…
This biblical prophecy from Luke 12,3 is solo true: " What you have said in the dark will be heard in the daylight, and what you have whispered in the ear in the inner rooms will be proclaimed from the roofs."
Earlier quoted context omitted.
> something P != NP might imply can be done... hashing algorithms just have this problem where if you glance at the information theory you would have guessed they couldn't be possible until someone shows you one that seems to work I'm confused what you mean by this? Why does the info theory suggest hashing wouldn't be possible? Also, you can easily derive a secure hash function from a secure symmetric cipher and vice…
1) The premise of a hash function is that you are going to take a large set of inputs and map it to a small set of outputs such that you don't find collisions, with the use case that the result is somehow so unique that the input file can be henceforth named by its hash and looked up in some giant dictionary of everything we have so far ever bothered to hash. The hash is this tiny bit of information, and somehow is e…
It doesn't really describe the information it just indexes each piece. For that it is a very large key space. A 128 bit key could index 10^38 objects. That's a lot of slots. Provided your hash has sufficient mixing you will need a lot of shots to hit anything.
>If one can truly "easily" derive a "secure" hash function
Semantic security has a precise definition. We just have to make empirical assumptions about whether an input cipher is semantically secure. The hash is only secure if the cipher was but the derivation is easy.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
It probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.
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
Earlier quoted context omitted.
Neat, but don't know if I can switch because of how it rolls off the tongue.
It got easier for me once I learned that "shambles" is a noun that is a synonym of "slaughterhouse". Once I learned that, I emphasized shambles slightly differently as I rolled the phrase off my tongue. "SHA-1 is a slaughterhouse " "SHA-1 is a shambles "