Re: comments on draft-ietf-idpr-specv1-02.txt

Noel Chiappa <> Sun, 14 March 1993 21:42 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa05590; 14 Mar 93 16:42 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05586; 14 Mar 93 16:42 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa27953; 14 Mar 93 16:42 EST
Received: by PIZZA.BBN.COM id aa03613; 14 Mar 93 16:39 EST
Received: from pizza by PIZZA.BBN.COM id aa03481; 14 Mar 93 16:05 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa03477; 14 Mar 93 16:02 EST
Received: from GINGER.LCS.MIT.EDU by BBN.COM id aa26509; 14 Mar 93 16:01 EST
Received: by id AA01810; Sun, 14 Mar 93 16:00:26 -0500
Date: Sun, 14 Mar 93 16:00:26 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Noel Chiappa <>
Message-Id: <>
Subject: Re: comments on draft-ietf-idpr-specv1-02.txt

    They provide NO guarantee of source authenticity, and the only
    integrity that they show is that the data has not been changed since
    the time that the MD4/5 hash has was created. Unfortunately, since
    MD4/5 ARE NOT digital signature algorithms ... If you are looking for
    a full digital signature algorithm, then you need something like RSA
    or DSA. ... MD4/5 were never intended for the purpose you describe,
    and provide essentially no authentication.

If the input to the hash function (MD4/5) includes not only the data, but a
secret, known only to the source and destination, isn't the resulting hash
output a digital signature? (Agreed, the key management is not as nice as a
hash function combined with a private-key, since you need N^2 rather than 2N
keys for the same degree of unspoofability.)

We're both being picky, but your point about the document being unclear is
true, though.