EnRUPT – The Simpler The Better

I like it!

I'm an engineer and even I could understand how it works. Like you said, we're the dumb fu**s who will be implementing this if it becomes a standard. Masturbating with equations is for math nerds.
We like simple and efficient structures in C/assembly/vhdl :)

[censored a bit by the moderator]

ROFL!

Yes, that’s a very good way to put it. ;)

Although there are plenty of unqualified brainless developers, I certainly did not imply that electrical engineers or software developers have no brains. On contrary. I just know how much crap you guys have to deal with making useful products for everyone besides having to muck around with our stupid equations... Any cipher or a hash that is more than a child can remember is certainly not suitable for general purpose use. That is my opinion.

See, I did not submit anything to SHA-3 just to give EnRUPT more chances :)
Jokes aside, good luck.

Enrupt already has been broken by Khovratovich and Nikolic.

"broken" could not be further from the truth.

All they did is prove the high security margin of EnRUPT. 2^384 memory to find a preimage in 2^480 time to break a 256-bit secure hash?

A straightforward time memory trade-off finds a preimage in 2^128 time with 2^384 memory. A straightforward parallel brute-force with 2^384 tiny EnRUPT circuits that fit in that memory find a preimage in 2^128 time. But 2^480??? Give us a break!

>> 2^384 memory to find a preimage in 2^480 time to break a 256-bit secure hash?

Their attack works on EnRUPT-512. As far as I, know secure hash function should require 2^^n computations to find preimages. That is the standard and accepted requirement. Bernsteins metric of brutforce attacks is not well accepted among cryptologic community. And even if it were, thats besides point, since EnRUPT-512 lacks conservative security margin for a standard cryptographic hash function, that will need to be secure for a least a few decades.

Even if their attack does indeed work with the claimed complexity as they hopeestimate, and even if you are too happy to reject the obvious mathematics of the parallel brute-force by labeling it "Bernstein's metric", the total complexity of this attack is far beyond the generic time-memory trade-off that applies to every single hash function, far beyond even the good old T*M²=N² that applies to every single hash function on that list.

So please let us be civil and reasonable if we want to be productive in this competition. EnRUPT does have the conservative high security margin to last for decades. If you need resistance to attacks with 1024-bit time*memory complexity, simply use EnRUPT with H=4*h/w, that is H=32 for EnRUPT-512 as is recommended in the original specification when such "conservative" 512-bit security is required of a stream mode.

EnRUPT is a highly parameterised hash. You cannot say that you broke EnRUPT unless you completely broke its structural integrity for every size and speed, you can only say that you broke it for a specific set of parameters. Their "attack" does not apply to EnRUPT64x2-512/4 with H≥18 even if you disregard complexity of TMDTO or brute-force attacks.

I don't reject any math. I'm saying that Bernstein's metric(I call it that way, because it was suggested by Bernstein) should not be used to determine the treshold, that separates secure cryptographic primitives from insecure ones. We need to be much more conservative than that, when were selecting a standard. If during AES selection process, an attack on Rijndael/128 would have been found that would require, say 2^^112 chosen plaintexts and 2^^120 work, NIST would have never chosen it as a standard, even though the attack would have been slower than parallel brute-force attack.

>>EnRUPT is a highly parameterised hash. You cannot say that you broke EnRUPT unless you completely broke its structural integrity for every size and speed, you can only say that you broke it for a specific set of parameters

No. SHA-3 Submission Requirements document (http://csrc.nist.gov/groups/ST/hash/documents/FR_Notice_Nov07.pdf ,section 3) clearly states:
"The candidate algorithm shall be
capable of supporting message digest
sizes of 224, 256, 384, and 512 bits..."
NIST submissions may support other digitest sizes, but those 5 are minimum requirements
and those parameters will be defined as SHA-3 standard, just like AES is defined as Rijndael with block size of 128 bits and key sizes of 128,192 and 256 bits, even though Rijndael can support larger block sizes.

>>Their "attack" does not apply to EnRUPT64x2-512/4 with H≥18 even if you disregard complexity of TMDTO or brute-force attacks.

You haven't specified those parameters in EnRUPT submission document. These things matter and you can't blame the cryptanalysts of incorrect analysis for that.

> If during AES selection process, an attack on Rijndael/128 would have been found that would require, say 2^^112 chosen plaintexts and 2^^120 work, NIST would have never chosen it as a standard, even though the attack would have been slower than parallel brute-force attack.

Sir, you are totally confusing the amount of data (plaintext/ciphertext pairs) and the amount of memory required for the attack. You are wrong. Such an attack would have been faster [cheaper] than parallel brute-force and NIST would have been right to reject such a cipher.

> No.

Wrong again. Any stream EnRUPT-512 mode can use any state size, as long as it is no less than 4*security and the number of words is recommended to be divisible by P for performance reasons.

> You haven't specified those parameters in EnRUPT submission document.

Yes we have. See Section 1.1.3: s*P ≤ H ≤ 6*s*P, 2*h ≤ H. Recommended H = (2*h+P*w–1)/w/P*P. It may not be too clear that it is a variable parameter since we forgot to include it in the section 3.4, but it is clearly explained in the original EnRUPT specification paper.

accidentally found a topic with ruptor involved in a discussion in it
i was impressed
so i wish you good luck
let the force be with you!

ps
just in case english is not my mother tongue