Re: [GNU Crypto] RFC: New keystore format

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

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:
>
> 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?

* 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.


> > > > * 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.

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, 
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>:/...


> > > > * 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?


> > > > [...]
> > >
> > > 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.

if this is the argument and you feel a majority of users share the same 
feeling, then it's fair to allow everybody making the decision about 
other parameters too.  some 'user-preference' entry(ies) in the 
keying_params_file could store preferred default values for algorithms 
and parameters that can be overriden on a per operation basis.


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/GFxO+e1AKnsTRiERA2n5AKDHrrFNLKOT4IECikJrIDTKo+jwjACg+ZWw
aqvCUoeNqjI8flGIl1+F7kc=
=jtOj
-----END PGP SIGNATURE-----