Return-Path: william@bourbon.usc.edu
Delivery-Date: Sun Apr 22 09:29:46 2007
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on merlot.usc.edu
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,
	NO_REAL_NAME autolearn=ham version=3.1.3
Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75])
	by merlot.usc.edu (8.13.5/8.13.5) with ESMTP id l3MGTkno005183
	for <cs551@merlot.usc.edu>; Sun, 22 Apr 2007 09:29:46 -0700
Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1])
	by bourbon.usc.edu (8.13.5/8.13.5) with ESMTP id l3MGTVg2002831
	for <cs551@merlot>; Sun, 22 Apr 2007 09:29:31 -0700
Message-Id: <200704221629.l3MGTVg2002831@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: About delete 
Date: Sun, 22 Apr 2007 09:29:31 -0700
From: william@bourbon.usc.edu

Someone wrote:

  > On the node receiving DELETE msg, is computing the digital
  > signature of the FileSpec and comparing it against the received
  > filespec the same as using openssl to verify delete?

If this node uses its own private key to "compute a digital
signature", then with 100% certainty it will not "match"
against the received FileSpec.

What's in a DELETE message is a *digitally signed FileSpec*.
Then only thing you can do with such a thing is to *verify
the digital signature* (which requires the public key of the
signer, and this public key is inside the certificate of the
signer).

Therefore, when a node receives a DELETE message, it should
just verify the digital signature.  Please see:

    http://merlot.usc.edu/cs551-s07/projects/final.html#cert

regarding how to verify a digital signature.
--
Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>



  ----- Original Message -----
  From: william@bourbon.usc.edu
  Date: Saturday, April 21, 2007 10:46 pm
  Subject: Re: About delete
  To: cs551@merlot.usc.edu
  
  > Someone wrote:
  > 
  >  > You said :
  >  > START QUOTE=================================
  >  > You should see that the following 3 lines are visible to your
  >  > program:
  >  > 
  >  >     FileName=...
  >  >     SHA1=...
  >  >     Nonce=...
  >  > 
  >  > So, you can extract the FileName, SHA1, and Nonce values from
  >  > a signed File Spec *before* to try to verify any digital
  >  > signatures.  Then you can use, say, the SHA1 index structure
  >  > to find all files with the same SHA1 files, open their
  >  > metadata files and find a subset that has the same Noce
  >  > (hopefullly, there is only one such file since you should not
  >  > have duplicates), then apply the corresponding certificate
  >  > file to verify digital signature.
  >  > 
  >  > ===================END QUOTE
  >  > 
  >  > We still have to match the filename if all the above is
  >  > found to be matching?
  > 
  > You need to find the file number in your mini-filesystem
  > that has exactly the same FileName, SHA1, and Nonce.
  > --
  > Bill Cheng // bill.cheng@usc.edu 
  > <URL:http://merlot.usc.edu/william/usc/>
  > 
  > 
  > 
  >  ----- Original Message -----
  >  From: william@bourbon.usc.edu
  >  Date: Tuesday, April 17, 2007 7:36 pm
  >  Subject: Re: About delete
  >  To: cs551@merlot.usc.edu
  >  
  >  > Someone wrote:
  >  > 
  >  >  > I am not clear how the delete works?
  >  >  > When a node gets a delete packet it verifies it with all 
  > the 
  >  > .pem files 
  >  >  > he has in his home directory and then matches the 
  >  > contents(file name, 
  >  >  > sha1, nonce) provided in the delete packet
  >  >  > nad then deletes the file..
  >  >  > is it the right flow isn't  it very inefficient or am I 
  >  > missing something?
  >  > 
  >  > This is inefficient.  If you look at the sample signed File Spec:
  >  > 
  >  >    http://merlot.usc.edu/cs551-s07/projects/cert/signed.txt
  >  > 
  >  > You should see that the following 3 lines are visible to your
  >  > program:
  >  > 
  >  >    FileName=...
  >  >    SHA1=...
  >  >    Nonce=...
  >  > 
  >  > So, you can extract the FileName, SHA1, and Nonce values from
  >  > a signed File Spec *before* to try to verify any digital
  >  > signatures.  Then you can use, say, the SHA1 index structure
  >  > to find all files with the same SHA1 files, open their
  >  > metadata files and find a subset that has the same Noce
  >  > (hopefullly, there is only one such file since you should not
  >  > have duplicates), then apply the corresponding certificate
  >  > file to verify digital signature.
  >  > --
  >  > Bill Cheng // bill.cheng@usc.edu 
  >  > <URL:http://merlot.usc.edu/william/usc/>
