1996-02-26 - Re: InterNIC Guardian Object Draft

Header Data

From: Jasdip Singh <jasdips@genie.internic.net>
To: cypherpunks@toad.com
Message Hash: 1c851e411edae6f1d80f0403c62f20a93fce0b3a821b8dc2cb4b08e6c019101a
Message ID: <199602260439.XAA24020@genie.internic.net>
Reply To: <199602251334.IAA29519@opine.cs.umass.edu>
UTC Datetime: 1996-02-26 04:50:49 UTC
Raw Date: Mon, 26 Feb 1996 12:50:49 +0800

Raw message

From: Jasdip Singh <jasdips@genie.internic.net>
Date: Mon, 26 Feb 1996 12:50:49 +0800
To: cypherpunks@toad.com
Subject: Re: InterNIC Guardian Object Draft
In-Reply-To: <199602251334.IAA29519@opine.cs.umass.edu>
Message-ID: <199602260439.XAA24020@genie.internic.net>
MIME-Version: 1.0
Content-Type: text/plain


> > PGP stands for Pretty Good Privacy [2]. The sender will
> > sign the update message with a Guardian's secret PGP
> > key. The InterNIC will verify the received update
> > message with the Guardian's public PGP key. 
> As far as I can see from the draft, the contact update templates do not
> include date or time information. This makes the protocol vulnerable to 
> a simple replay attack. An attacker can record update messages and replay
> them to InterNIC later. 
> Depending upon a Guardian's notification status, this could allow the 
> attacker to confuse things by restoring an old contact information record. 
> Even if a Guardian is using BEFORE-UPDATE, she might not notice that a
> subtle change has been undone. An update notification message arriving on 
> the heels of a similar one might get approved by a Guardian, who chalks it
> up to a mail transport glitch.
> Requiring some sort of timestamp field in the signed portion of the contact
> templates would be good.

I think replay attack is not possible in PGP (unless someone has sender's
private key).

On the receiving end, PGP will decrypt the digital signature using the
sender's public key to get the original hash code (MD5) of the sent
message and compare it with the hash code of the received message
to authenticate the sender.  Once the sender is authenticated, it
 *further* needs to be verified as a guardian for the object to be
updated.  Otherwise, a malicious registrant in InterNIC's public key
ring can update an object it is not supposed to.

Only possiblity is someone capturing a signed PGP message, decrypting
the original hash code using the sender's public key, and then trying
to alter the update message such that it generates the same hash code.
This is highly unlikely since PGP uses MD5 that produces 128-bit hash