Re: GOST key gen?



<tom@xxxxxxx> wrote in message news:3f65ff76-6e2a-4a0f-9e2d-d4cff190225f@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On May 13, 5:13 am, "Joseph Ashwood" <ashw...@xxxxxxx> wrote:
A 64-bit block is inherently weak for sizes that are normal today. Chaining

No, a 64-bit block size makes for bad STANDARDS but that's because
they have to be ubiquitous and a lot of applications nowadays need 128-
bit block ciphers.

Obviously you haven't kept up with the entire conversation. The original question is about encrypt disks. Last time I checked most people have hundreds of GB worth of ceramic disks spinning in their computers. Since hundreds of GB > 32GB, its pretty simple.


mode security is only good to the the birthday point, for a 64-bit block
this is 2^32 blocks of 64 bits each = 32GB. 32GB is no longer large enough
for common use. This applies to even a perfect block cipher. While I didn't
immediately locate published attacks on the full GOST algorithm, the age of
the standard indicates that at least minor flaws are likely.

Are you kidding? Most TLS/SSL transactions measure under 1MB, let
alone 1GB or even 32GB. The bulk of private transactions are tiny
banking and cell transactions. They're certainly nowhere near 32GB in
size.

I should ask you the same thing, are you kidding? There have been an enormous number of TLS/SSL transactions that are over 32GB in size, if a 64-bit cipher is used for those they are insecure. Basically you are advocating playing Russian Roulette, most of the time when you pull the trigger nothing will happen, so obviously it's a good idea. The problem with that line of thinking is that a portion of the time everything goes horribly, horribly wrong. Personally, I'd rather remove the bullet from the gun.


I brought up 3DES because both 3DES and GOST are in the same situation, both
are in the process of being retired, and both for very good reason. It is
just that most people are more familiar with the retirement of 3DES than
GOST.

The real problem with GOST was that the 4x4 tables were secret and a
standard for them was never settled upon. Which made implementations
very home-brew at best. It also had really crappy diffusion and
basically no branch. They would have been better with even the most
trivial of circulant binary matrices as a linear transform...

I should like to point out that your line of thinking really irked me
during the SHA3 discovery phase [before the contest started]. I had
proposed that there be a class of 128-bit hash functions whose single
purpose would be to used in HMAC situations. My argument being you
could compute a 128-bit hash natively faster than a 512-bit hash and
truncate it (since sending a 512-bit MAC is useless and a waste of
space). And I received the same counterarguments about how a hash has
to be really large to be secure in any circumstance and all that.

People really ought to think about how this is to be used not just
what they'd "like" to see.

Exactly. You "like" to see that if it is used in certain very narrow, restrictive constraints it is reasonably secure, but when time is taken to think about how this will be used everything changes. There is also no evidence that an HMAC secure 128-bit hash will be faster than a 512-bit secure hash, SHA-512 is nearly as fast as SHA-1 when properly optimised. Unloading the gun is always safer.

The GOST encryption algorithm standard was retired for a reason, and it is important to move away from using GOST as soon as reasonable.
Joe

.



Relevant Pages

  • Re: Hashing of short fixed length messages
    ... You actually have 55 bytes of useful payload before MD5 requires a 2nd ... to present a traditional hash interface since the ... The input itself is a hash too, so I can ignore related key attack, ... to a speed-up factor of two, but I don't think it's secure. ...
    (sci.crypt)
  • Re: Loop over keys and values of a hashtable
    ... The thing is, hash tables are by nature unordered, so no ... and then you rely on vendor promises. ... In fact, better, since the standard cannot promise a single ... > For this reason I think it would almost be more helpful for the ...
    (comp.lang.lisp)
  • Re: Loop over keys and values of a hashtable
    ... The thing is, hash tables are by nature unordered, so no ... >> even if you iterate over the same hash table you shouldn't expect to ... >> For this reason I think it would almost be more helpful for the ... a new loop term was added to specifically return the key and value like ...
    (comp.lang.lisp)
  • Re: modular programming in Forth
    ... That's the essential reason for using a separate ... wordlist for the API. ... : test bla bla .... ... HASH \ ensure that HASH is in the search order ...
    (comp.lang.forth)
  • Re: Added hashes.
    ... > Isn't it more secure to hash a file by hashing it twice with two seperate ... First I will agree with Hadstate, all you've done is create a new hash ... Strategy designs, while the MD/SHA series are Feistel designs. ...
    (sci.crypt)