Re: FUD about CGD and GBDE

From: Peter Hendrickson (pdh_at_wiredyne.com)
Date: 03/05/05

  • Next message: Charles M. Hannum: "Re: FUD about CGD and GBDE" 
    Date: 5 Mar 2005 20:04:46 -0000
To: Thor Lancelot Simon <tls@rek.tjls.com>

    Thor Lancelot Simon wrote:
    > I note that GBDE uses a number of algorithms in ways that are not
    > consistent with their design purposes. For instance, it truncates a
    > non-keyed hash (SHA512); the fact that this is not necessarily a
    > good idea is one of the major motivators for the design of HMAC.

    This is a widely accepted practice. RFC 2631 generates keys this way,
    using SHA-1. And aren't most /dev/random implementations outputting
    SHA-1 hashes? Users are expected to treat the output as a stream of
    random bits, so in most cases truncated hashes are used. It may not
    be a good idea, but Poul-Henning Kamp has not made a radical design
    decision here.

    Also, a problem with a keyed hash may not be a problem when generating
    key material from a secret. Let's say we use this as a keyed hash
    function: SHA-1(k || p). (k the key, p the plaintext to be
    authenticated.) This has the bad property that the attacker can easily
    forge signatures of the form SHA-1(k || p || x) where x is attacker
    supplied material. (The attacker does not need to know the value of
    k.) But this is a reasonable way to generate key material to drive a
    cipher.

    I will note that Kamp's design differs from RFC 2631's approach.
    Section 7.1 ("From passphrase to master key") of his paper describes
    the generation of three keys from one hash. RFC 2631 would generate
    these keys by doing three hash computations with a counter used to
    vary the input slightly and using the leftmost bits of the result.
    Intuitively, I like RFC 2631's approach better, but it would be
    interesting to know if there's a better reason to do it that way.

    Peter
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Charles M. Hannum: "Re: FUD about CGD and GBDE"

    Relevant Pages

    • Re: SPES (my new encryption) one of its kind
      ... We generally don't state these as blatantly as that in the cipher design, ... there is a good reason which is: you can not be sure 100% that current ... it is a consistent theme in the entire history of cryptography. ... with relying on A AND B AND C AND D being true, so the attacker only has ...
      (sci.crypt)
    • Re: SPES (my new encryption) one of its kind
      ... I'm talking to someone who proposes a new cipher around here: Your design ... but that the attacker will payit over and over. ... every encryption system has advantages and dis-advantages,and every ...
      (sci.crypt)
    • Re: Symetric encryption : DES or not DES ?
      ... >> willing to invest rather heavily in consulting and design (which you ... >> symmetric encryption. ... > But isn't there still a possibility for the attacker to crack this ... and hashing place the data beyond brute fore attack. ...
      (sci.crypt)
    • Idea for enc+Auth?
      ... An attacker cannot move blocks around since the F2won't match. ... random PRP and ideally somewhat ... Open questions ... If this design isn't trivially weak I'm willing to work with someone on the ...
      (sci.crypt)
    • Re: String Constants
      ... political movements that began in Europe in the 1920s. ... protocols, not designing them. ... in RFC 791. ... Since RFC 1122 is a protocol *design* document, ...
      (comp.lang.forth)