Question: Can the counter be any value? about discohash HOT 7 CLOSED

Good question! Thanks for the idea! Let’s investigate this.

looking at the line it seems definitely I designed it to be a nothing up my sleeve value. Theoretically it could take any value.

my concerns / thoughts are (and I’m not immediately sure how relevant these all are):

• I developed the randomness of this function through testing with SMHASHER, so is possible that it’s finely tuned and changing a value could unravel it, but it may not be likely
• SMASHER already identifies some weak seed values, not sure how relevant this is for encryption but it’s something I had wanted to come back to and work on a fix for sometime

anyway this is a nice find. Let’s try to make this happen. What’s your specific idea for how to do, and how do you think we can evaluate it?

from discohash.

Thanks @alpominth

from discohash.

@crisdosyago

I got.

What’s your specific idea for how to do, and how do you think we can evaluate it?

I'm thinking on a way to make a pseudo-OTP, it basically uses a very long key, let's say 1MiB and repeats the key for each 1MiB block. The base idea is that if you hash a 512-bits seed and output a 128-bit key, you'll never have idea of what seed was used to make the key, because this process is LOSSY, even trying to brute-force the entire 512-bits seed, 2^256 different seeds will share the same output key because of collisions, it will be more expensive than brute-forcing the entire key-space of the key (2^128). An adversary would never have an idea of what was exactly the key used to generate the key.

In the scheme that I have been thinking, a block of 1MiB is splitted in many parts and each part is encrypted with different outputs of an hash function using different seeds, each seed is four times larger than the output of the hash function. For example, the output of the hash function has 128-bits of size, and the seed four times larger (512-bits); as for each 512-bits seed it would have 2^256 collisions the adversary would need to guess what input was used to generate the output, it would be the same as guessing what plaintext is behind the ciphertext. Remembering that in OTP a key should never be repeated for subsequent blocks or reused; but in my "scheme" it could, maybe.

/\ The intuition above could be expanded to subsequent blocks.

Let's take two blocks of 1MiB, they are splitted in many sub-blocks of 128-bits, each sub-block is encrypted with an output of a hash function being the "key" (seed) 4 times larger than the output. For making each block different, there would be a "block key" that has the same size of the "keys" and is XORed with the "keys" before being hashed and used to generate the output.

I believe the maximum effort for an adversary would be if he knows the plaintext of many blocks, all that he could do is to XOR the known-plaintext with the ciphertext to obtain the outputs of hash function; he could parallelize each core of its CPU for brute-forcing the 512-bits keys to find what common key was used to produce each output of hash function. But as the process of turning a "key" of 512-bits into an 128-bits blocks is lossy, he would never have idea what key was used, and also what "block key" was used because they has the same size of the "key".

This is my idea, but I have to say that I'm not a cryptographer but I have the enough knowledge about the common attacks in OTP and hash functions, I can say that this "scheme" is right.

It's very messy and I don't know if you would understand because it's a little bit complicated to transform a bunch of ideas into text.

PS: Sorry for my English.

==========================

I'm really interested in DiscoHash because it's lightning fast both on 32 and 64-bits systems.

Of course I will use it in my future projects.

from discohash.

Sounds like an interesting bit of work you’re about to do! Thank you for sharing! Well best of luck with it @alpominth!

I’ll close this issue now because it’s about discussing an idea and we’ve done that. Thank you. Have a good one! 😀😜

from discohash.

@crisdosyago

I will take a time and think about the scheme itself, but for me it's safe.

But well, I believe it's not a good idea in setting a different counter value for Discohash as you said.

PS: You could activate the "Discussions" session in this repository, it would help cryptanalists to share their knowledge and helping developing Discohash.

Thank you Man!

from discohash.

Thank you Man!

You're welcome!

PS: You could activate the "Discussions" session in this repository, it would help cryptanalists to share their knowledge and helping developing Discohash.

Done! :)

from discohash.

@crisdosyago

A 5GB/s Hash function that hashes fast on 32-bits systems? Yes!

I believe the community will have a lot of things to discuss.

Thanks.

from discohash.