Re: [GNU Crypto] RFC: New keystore format

[Casey Marshall]

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

On Sat, Jul 19, 2003 at 06:45:00AM +1000, Raif S. Naffah wrote:

> On Fri, 18 Jul 2003 01:08 pm, Casey Marshall wrote:
> > On Fri, Jul 18, 2003 at 05:34:34AM +1000, Raif S. Naffah wrote:
> > > 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:
> > > >
> > >
> > > 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?
> 
> * the first byte may be right even if the password was wrong, everything 
> else does not have the same chance; i.e. all the other header fields in 
> the 1 or more entries that are decrypted.
> 
> * the end result wether the file is malformed or the password is wrong 
> is that the entries in the keyring are not visible.
> 
> * if you insist on asserting if you decrypted what the originator 
> intended, pretending not to have any knowledge of what type of data is 
> meant to be encrypted in the first place, then hashing the plaintext is 
> probably the most expensive way for doing so.  other cheaper 
> alternatives may be:
> 
> + compute a CRC of the ciphertext and include it in the to-be-compressed 
> data; or
> + append a known guard (MAGIC byte(s)) to the plaintext before 
> encryption --e.g. GKS_TYPE_END entry.
> + (variation of the above) append to the plaintext a duplicate of the 
> first n bytes.
> 

A CRC/magic value will do (md5 was just a placeholder). It would be
difficult programmaticly to separate a bad password from a badly formed
(but properly decrypted) file, and I think outputting "bad password" is
a friendlier thing for a program to do.

> > [URIs ...]
> >
> > 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.
> 
> are you saying use "file:" as the default protocol if none is specified 
> in the uri string?  if yes then agreed.  in the implementation though, 

Or, only support URLs in our initial implementation (URLs are a subset
of URIs, right?).

> care must be taken to distinguish (for later when we will use real 
> uris) between implicit file uri, and windoors paths; i.e.:
> 
>    <drive-letter>:/...
> and
>    <real-protocol>:/...
> 

':' is a reserved character in the URI syntax, so it would have to be
escaped if it appears in a URI.

> > > > > * 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.
> 
> if certain files shall contain certain type(s), and only those types, of 
> data, then using a different MAGIC value for those files is an explicit 
> rendition of the specification.  on the other hand, if a file can 
> contain different types, then we dont need one per file type.
> 
> what is it?
> 

My intention was to allow any valid file to contain any valid objects,
but at out application layer we enforce the separation.

(Admittedly, this may be the wrong way to do it, but I didn't want to
bring content restrictions into the actual file format, making it of
better generic use)

Cheers,

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

iD8DBQE/GIm7gAuWMgRGsWsRAu3NAJ0QT61Ud8Z7V91tABJO48AAOny0zACfXry2
hmvRRONjU4LqGAJkp3wcGCU=
=BM+J
-----END PGP SIGNATURE-----