Re: [GNU Crypto] RFC: New keystore format

[Raif S. Naffah]

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

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:
> > > ...
> > > I've been scribbling some notes...
> >
> > ...
> > on data types:
> >
> > * re-use types implemented in SASL mechanisms (see OutputBuffer and
> > InputBuffer in gnu.crypto.sasl).
>
> I don't see why not.

i started coding a parser for the proposed types and would recommend 
using the basic types supported by java.io.DataInput.  for those that 
are not already there, we can use the sasl ones (e.g. MPI, OS,  EOS, 
etc.).


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


> > * why encoded as a string, not as octets?
> Because they are variable-length. Octets are meant to be
> fixed/implied length. The terminology here is careless; I was using
> the term "string" as it appears in the SSH internet-drafts.
>
> That is, 'string' just means:
>
>    uint16     length, l
>    octets[l]  data

i see.  i believe we're talking the same thing but using different 
terminology (i.e. strings v/s octet sequences).


> > ...
> > 2.5. Certificate Chain.
> > * should be renamed to reflect x.509 certificate parentage.  we may
> > want to support GPG packets in the future.
>
> Not sure what you mean.

the JKS implies X.509 certificates.  we may support other than X.509 ID 
certificates, or standard in the future.  other schemes may also be 
using terms like "Certificate".  my suggestion is to slap x509 in front 
of any X.509-related object/name.


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


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

      String alias = in.readUTF();
      int prfAlgorithm = in.readUnsignedByte();
      int hLen = in.readUnsignedByte();
      int dkLen = in.readUnsignedByte();
      int iterations = in.readInt();
      byte[] salt = new byte[8];
      in.readFully(salt);
      int hmacAlgorithm = in.readUnsignedByte();
      int truncatedSize = in.readUnsignedShort();

      // value bytes

      byte[] mac = new byte[truncatedSize];
      in.readFully(mac);
      // verify mac against computed value

the terms relate to PKCS5 as described in RFC-2898 sections 5, 7, and 
appendix B-1.  also the salt is fixed to 8 bytes.


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


> I am not happy with the multiple/single distinction, and it would
> probably be better to just have one type that contains the alias
> field.
>
> > ...
> > 4. Recommended constructions.
> >
> > * why not consider 2 files: a public keyring and a secret one
> > --similar to GPG?
>
> A single file fits the KeyStore API better -- they are loaded
> off-disk from an InputStream.

i too thought this may be a problem (which can still be ;-) but the JKS 
API allows for null streams --to cater for hardware based keystores.

the Spi implementation can be using a KeyringPair object that contains 
an instance of PublickKeyring and another of SecretKeyring; etc. --i 
already have classes that do this.


> There is nothing stopping a user from keeping the two separate,
> however. This might be the "recommended usage", but forcing this is
> probably not the way to do it.

why not.  they're two different sort of information.  bundling them 
together does not sound right.


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


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


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

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


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


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

iD8DBQE/EMzw+e1AKnsTRiERAyprAJ9dgg4uzvPaK3R1GiOYemrfWhWSxACeNSrW
7fPSU+TLB04rjgSMkvBwwIo=
=Vm1B
-----END PGP SIGNATURE-----