undefined | Better HN

0 pointsvalenterry11mo ago0 comments

Except that there are collisions...

0 comments

This might be completely naive but can a reversible time component be incorporated into distinguishing two hash calculations? Meaning when unpacked/extrapolated it is a unique signifier but when decomposed it folds back into the standard calculation - is this feasible?

shakna11mo ago

Some hashes do have verification bits, that are used not just to verify intact hash, but one "identical" hash from another. However, they do tend to be slower hashes.

grumbelbart211mo ago

Do you have an example? That just sounds like a hash that is a few bits longer.

shakna11mo ago

Mostly use of GCM (Galois/Counter Mode). Usually you tag the key, but you can also tag the value to check verification of collisions instead.

But as I said, slow.

ruined11mo ago

hashes by definition are not reversible. you could store a timestamp together with a hash, and/or you could include a timestamp in the digested content, but the timestamp can’t be part of the hash.

RetroTechie11mo ago

> hashes by definition are not reversible.

Sure they are. You could generate every possible input, compute hash & compare with a given one.

Ok it might take infinite amount of compute (time/energy). But that's just a technicality, right?

dagw11mo ago

Sure they are. You could generate every possible input

Depends entirely on what you mean by reversible. For every hash value, there are an infinite number of inputs that give that value. So while it is certainly possible to find some input that hashes to a given value, you cannot know which input I originally hashed to get that that value.

datameta11mo ago

Oh, of course, the timestamp could instead be metadata!

ww52011mo ago

Can use cryptographic hashing.

anonymars11mo ago

How does that get around the pigeonhole principle?

I think you'd have to compare the data value before purging, and you can only do the deduplication (purge) if the block is actually the same, otherwise you have to keep the block (you can't replace it with the hash because the hash link in the pool points to different data)

ww52011mo ago

The hash collision chance is extremely low.

valenterryOP11mo ago

For small amounts of data yeah. With growing data, the chance of a collision grows more than proportional. So in the context of working on storage systems (like s3 or so) that won't work unless customers actually accept the risk of a collission as okay. So for example, when storing media data (movies, photos), I could imagine that, but not for data in general.

1 more reply

j / k navigate · click thread line to collapse

0 comments

datameta11mo ago

shakna11mo ago

Some hashes do have verification bits, that are used not just to verify intact hash, but one "identical" hash from another. However, they do tend to be slower hashes.

grumbelbart211mo ago

Do you have an example? That just sounds like a hash that is a few bits longer.

shakna11mo ago

Mostly use of GCM (Galois/Counter Mode). Usually you tag the key, but you can also tag the value to check verification of collisions instead.

But as I said, slow.

ruined11mo ago

hashes by definition are not reversible. you could store a timestamp together with a hash, and/or you could include a timestamp in the digested content, but the timestamp can’t be part of the hash.

RetroTechie11mo ago

> hashes by definition are not reversible.

Sure they are. You could generate every possible input, compute hash & compare with a given one.

Ok it might take infinite amount of compute (time/energy). But that's just a technicality, right?

dagw11mo ago

Sure they are. You could generate every possible input

datameta11mo ago

Oh, of course, the timestamp could instead be metadata!

ww52011mo ago

Can use cryptographic hashing.

anonymars11mo ago

How does that get around the pigeonhole principle?

ww52011mo ago

The hash collision chance is extremely low.

valenterryOP11mo ago

1 more reply

j / k navigate · click thread line to collapse