Re: [GNU Crypto] RFC: New keystore format

[Casey Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jul 18, 2003 at 05:34:34AM +1000, Raif S. Naffah wrote:

Are there any other opinions hiding on this list? I'd like to hear them.
Raif and I clearly have different approaches to this (which I consider a
good thing) but two people a concensus does not make.

> On Thu, 17 Jul 2003 07:57 am, Casey Marshall wrote:
> > On Wed, Jul 16, 2003 at 11:26:47PM +1000, Raif S. Naffah wrote:
> >
> > > ...
> >
> > Should the encrypted envelopes contain a hash of the plaintext, to
> > more easily detect a failed decryption?
> >
> > E.g.
> >
> > encrypted_data = PBE_ENCRYPT(plaintext_and_hash) ;
> >
> > plaintext_and_hash = plaintext HASH(plaintext) ;
> >
> > And make HASH MD5, for example.
> 
> i dont think they need to.  if a decryption fails, the plaintext 
> obtained is unlikely to still be well formed according to the syntax 
> rules we're discussing.
> 

Decrypting then waiting until something goes wrong just feels sort of...
dirty. Since the first byte has a rather good chance of appearing
meaningful on a bad decrypt, merely giving the parser a bad password
could throw the poor thing into fits.

And besides: how does one separate a wrong password from a malformed
file?

> > > * when decrypted, an encrypted_data field should yield a
> > >
> > > keyring_file_params =
> > >    GKR_TYPE_KEYRING_FILE
> > >    uri
> > >    password
> > >    protection_type
> > >    protection_params ;
> >
> > I was hesitant to specify actual URIs since Classpath does not yet
> > have a functional URI class.
> 
> ok.  a workaround that would still keep this version 1 format valid when 
> such an implementation becomes available would be to precede the uri 
> field with a 1-byte type.  allow 2 values (a) one to mean "file" 
> protocol, and the other to mean "implicit" specification of the 
> protocol in the next field string, and (b) when "file" protocol, the 
> uri field would contain the path to the keyring, and when "implicit" 
> the full string of the uri would be considered.
> 

We could perhaps fudge it, since the the most common value of this field
would probably be a file: URI or a simple path with '/' as the file
separator. This could be handled with the URL and File classes. Or our
implementation could just support well-formed file: URLs but still leave
the specification open.

I'm having misgivings about storing the password in the file, though. 

> > > * MAGIC0, MAGIC1, and MAGIC2 are 4-octets...
> >
> > I'm not sure of the need of different magic values for different
> > keyrings.
> 
> the keyring files contain different types of data; the distinct MAGIC 
> helps (a) instantiate the appropriate scanner, and (b) decide which 
> types are illegal if/when they are included.
> 

I've just been approaching this from a very generic standpoint, and that
a valid file could have any valid combination of elements which any
parser will be able to handle. When it comes to writing data, however,
the normal behavior 

Again it just feels sort of dirty and overengineered.

> > > [...]
> >
> > I'd agree that the KDF and its parameters should be fixed, but
> > probably not the encryption/mac algorithms.
> 
> why?
> 

I for one would appreciate being able to customize the cipher that gets
used -- one might not think a particular algorithm appropriate for their
application, and forcing the use of a particular algorithm is outside of
the domain of a file format.

Cheers,

- -- 
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/F2ShgAuWMgRGsWsRApBHAJ9jmQ/7isqPYqWFnPBwBUVDireeIQCeOTy0
VEE48h1EqqsoMIoRDulAxIM=
=K9vm
-----END PGP SIGNATURE-----