Re: [GNU Crypto] RFC: New keystore format

[Casey Marshall]

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

On Sun, Jul 13, 2003 at 01:07:27PM +1000, Raif S. Naffah wrote:

> On Sun, 13 Jul 2003 11:37 am, Casey Marshall wrote:
> > On Sun, Jul 13, 2003 at 09:13:34AM +1000, Raif S. Naffah wrote:
> > > On Sun, 13 Jul 2003 04:47 am, Casey Marshall wrote:
> 
> [...]
> 
> > > ...
> > > 2.3. Trusted Certificates.
> > > * what are the possible/allowed values for encoding names/schemes?
> >
> > The idea was to make use of classes such as CertificateFactory, so
> > the encoding name would be e.g. "X.509" and the data the DER-encoded
> > certificate.
> 
> i'd avoid these in favour of an unsigned byte that IDs the desired 
> codec.
> 

The name/encoded pair just makes storage/retrieval of generic Certificate
objects simpler, i.e.

   Certificate cert = ...;
   out.writeUTF(cert.getType());
   byte[] enc = cert.getEncoded();
   out.writeShort(enc.length);
   out.write(enc);

   // ...

   String type = in.readUTF();
   CertificateFactory fact = CertificateFactory.getInstance(type);
   int len = in.readUnsignedShort();
   byte[] enc = new byte[len];
   in.read(enc);
   Certificate cert = fact.generateCertificate(enc);

...but this is not a crucial point. Defining byte-ids for common
certificate types (X.509, PGP) will do just fine.

> [...]
> 
> > >...
> > > 3.1. Password-encrypted.
> > > * hmac-md5 is accepted to be not suffering from md5 potential
> > > weakness. suggest use it as the default for version 1.
> > > * aes should be the default.
> >
> > I just used the OIDs that GNU has as a placeholder; AES and SHA-1
> > would probably be better defaults.
> 
> md5 is much faster than sha, and as i mentioned earlier md5-hmac is 
> still considered secure.
> 

Ok.

> > I am also not sure if OIDs are the way to go.
> 
> let's avoid OIDs altogether.  unsigned bytes for algorithm 
> identification would do the same job with less space.  for example for 
> this type of envelope, a structure that describes it can be:
> 

Better.

> [...]
> 
> > >...
> > > 3.2. Password-Encrypted Entries.
> > >
> > > * the difference between this and the previous type is the alias.
> > > how about always having the alias field, and use an empty string
> > > for multi-contents envelopes?
> >
> > Also the _ENTRY variants have an implied single contained entry,
> > while the others must end with the END byte.
> 
> i'm not sure about the usefulness of the end-byte.  if entries/packets 
> are aware of their length, we dont need the end-byte marker.
> 

The end byte just seemed to make more sense than keeping track of the
number of bytes read per packet, but since that doesn't seem to really
be that big an issue I'd agree that the end byte isn't needed.

Plus the end byte and the extension byte were the first two things I
thought of.

> [...]
> 
> > Also: on a provider level we can provide different semantics based
> > around the desired protection level. I.e. "SecretGKS" could be a
> > keystore that looks like this at the top level:
> >
> >    GKS_TYPE_PBE {
> >       GKS_TYPE_PBMAC {
> >          (keys and certificates)
> >          GKS_TYPE_END
> >       }
> >       GKS_TYPE_END
> >    }
> >
> > And also maybe a non-encrypting keystore that does not accept private
> > keys.
> 
> that's exactly what i'm talking about.  putting everything together in 
> one file doesnt leave too much room for maneuver.
> 
> also separating public data from secret one opens the door for sharing 
> the former between users.
> 

We could allow mixing, but have our normal practice be to keep them
separate.

> > > * shouldnt the secret keyring be constructed as encrypt first and
> > > authenticate later?
> >
> > As it stands, each envelope type only has knowledge of its contained
> > type, and if you encrypt then MACify the MAC would be be of the
> > encrypted data, which would be bad...
> 
> i thought that is, on the contrary, a good thing!  for EtA rationale 
> see:
> 
> Krawczyk, H., "The order of encryption and authentication for protecting 
> communications (Or: how secure is SSL?)", June 2001, 
> <http://eprint.iacr.org/2001/045/>.
> 

Interesting!

I was thinking of the MAC as being the "integrity check" -- to see if
the decryption succeeded or not -- which I probably should not have
been doing.

> 
> > ...
> > The alternative would be to make a type that encrypts and MACs the
> > contained types, e.g.:
> >
> >    byte             GKS_TYPE_PBE_PBMAC
> >    u8string alias
> >    u8string KDF OID
> >    uint32   iteration count
> >    string   salt
> >    u8string Cipher OID
> >    u8string MAC OID
> >    string   encrypted payload
> >    octets   MAC of decrypted payload
> >
> > which I think is unnecessary.
> 
> or just use the construction:
> 
>    GKS_TYPE_PBMAC_ENVELOPE {
>       GKS_TYPE_PBE_ENVELOPE {
>          // 0..n entries
>       }
>    }
> 
> 
> > Also:
> >
> >    * Maybe just choose a KDF/iteration count instead of making them
> >      explicit?
> 
> + having these values explicitly part of the entry/envelope makes it 
> simple for parsing/processing them in different environments/platforms 
> - --provided of course that implementations for the used algorithms exist 
> in that environment.
> 
> - - it also means that when re-used they shew up space.
> 
> - - hard-wiring them in the code is bad practice.
> 
> + containing them in a separate "configuration" (or user preferences) 
> file may be an alternative --e.g. default hmac algorithm, default prf 
> algorithm, default block cipher algorithm, etc.
> 

I prefer explicit algorithms, at least. The iteration count is probably
something where a standard value will suffice.

> >    * GKS (GNU Key Store) -- any better name ideas?
> 
> keystore is ok, but because sun invented it i'd avoid it.  Keyring, 
> Keyrings, KeySet, and KeyCollection are other options.
> 

I'd vote for GNU Keyring, it sounds the least silly.

> >    * Metadata mechanism? I.e. a way to encode how the store may be
> > used, whether or not the store may be modified, etc.
> 
> may be not needed in version 1.
> 

I just thought some attributes -- "read only", "for trusted certificates
only", "for secret keys only" -- would be useful.

Cheers.

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

iD8DBQE/EOTmgAuWMgRGsWsRAsjTAJoD4df9DSuj3Tw8qYVgJDR93P6CYgCfejEd
1INk7BzHWj2CFdzXsiTITfA=
=aDEr
-----END PGP SIGNATURE-----