Re: [GNU Crypto] Documentation

[baz]

Hi Raif,

Yes, of course you're right about the possibility of a weak key being chosen
at random, but I make the chances of this occuring approximately one in
every 970,881,267,037,344,821. That's about a quidzillion to one. I would be
happy with that for random generation.

I suppose the real issue is with users of the library inventing their own
keys, i.e. not random and possibly input by a user. Users have a habit of
entering very simple things, but again, isn't that up to the application
writer? I would be surprised if I used a library that contains a well known
algorithm that allows any combination of bits for its key material and
discovered it through exceptions because certain keys were considered weak.

I think I'm coming from the point of view of a library user/application
writer, as this is what I've done a lot of. I would expect the library
documentation to tell me about the concept of weak keys, tell me about the
methods I can call if I'm worried about this, but in the end let me use the
library the way I want to.

With regard to submitting code, I'm afraid I'm not well up on the theory
behind cryptology, I've just used it a lot. The kind of thing I've done is
write very easy to use wrapper classes around other APIs, e.g. to cover the
kind of situation where a third party says:

"Here is a sequence of ciphers defined by algorithm X, mode Y, padding
scheme Z. Here is a key and an iv for each of these. When you're ready I
will start sending you large chunks of data for you to decrypt."

The other case is when I am requested to provide keys for algorithm X, etc.
I may not really want to know too much about the details of algorithm X, so
a key factory that makes random keys (strong and possibly parity adjusted)
would suit me down to the ground.

Maybe this would be a useful addition to the library and would give me
something to do?

Best regards,
barry


----- Original Message -----
From: "Raif S. Naffah" <address@hidden>
To: "baz" <address@hidden>
Cc: "GNU Crypto" <address@hidden>
Sent: Monday, May 26, 2003 12:00 PM
Subject: Re: [GNU Crypto] Documentation


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

hello Barry,

On Mon, 26 May 2003 07:59 pm, baz wrote:
> Hi,
>
> I'm not convinced of the usefulness of a WeakKeyException for two
> reasons:
>
> 1) It is not an invalid key. The cipher still works.

true.  but should we allow it?  wouldnt you feel safer if/when the
implementation throws an exception if the key is weak?

my rationale is not to allow this to happen.


> 2) I counted only 19 weak and semi-weak (DES) keys. If a user of the
> library is randomly generating 8 byte keys then the chances of
> generating a weak key are pretty small!

yes small but not inexistant.  the question is what do we do if it
happens?


> I don't know about all the other ciphers, but I suspect that if they
> have weak keys then they'd be just as unlikely to be found at random.

to my knowledge, DES is the only one, among those implemented in the
library that has such keys.


> What might be more of an issue is the subject of parity. This is why
> I mentioned key generation before. For example, if a random sequence
> of bytes is used as a key then it can be adjusted to the correct
> parity in a number of ways. If a key generated by random is passed
> between individuals then their respective software might adjust it
> differently, so it's all the more important to generate a completely
> correct key to start with.
>
> I can envisage something along the lines of a
> SymmetricBlockCipherKeyFactoryThingy with a method like:
>
> byte[] generate( String algorithm );
>
> This could delegate to the concrete cipher implementation classes.
> Maybe?

although not necessary, that would be a nice addition.

as Casey pointed out earlier, in the case of DES: (a) there are static
methods to test and set/adjust the parity, and (b) the appropriate
method(s) can be invoked in makeKey().  this way, GNU Crypto
implementation is (or would become) resiliant wrt. the quality of the
input key material, wherever it comes from.


> I must say, I am most impressed with the library so far!

nice to hear :-)  thanks for taking the time to try it and make
suggestions for improvement.  the next step of course is contributing
code?!


> barry
>
> ----- Original Message -----
> From: "Raif S. Naffah" <address@hidden>
> To: "Casey Marshall" <address@hidden>
> Cc: "GNU Crypto" <address@hidden>
> Sent: Monday, May 26, 2003 10:39 AM
> Subject: Re: [GNU Crypto] Documentation
>
> On Mon, 26 May 2003 09:37 am, Casey Marshall wrote:
> > On Mon, May 26, 2003 at 06:59:57AM +1000, Raif S. Naffah wrote:
> > > On Mon, 26 May 2003 05:23 am, baz wrote:
> > >
> > > [...]
> > >
> > > > How about renaming 'Stage.getInstace'?  :-)
> > >
> > >                                    ^^
> > > to what?  once the Cacscade and Assembly are documented, it
> > > should become easy(ier) to have a clear mental image of what the
> > > building blocks are --and the names then would make more sense.
> > > (this is the theory at least :-)
> >
> > To 'getInstance'.
>
> yes of course (blush).  i'll fix this asap.
>
> > > > Lastly, there is nothing in the library for generating keys.
> > > > Correct me if I'm wrong but I thought that not all encryption
> > > > schemes use an entirely random sequence of bits for their keys.
> > > > Don't some require a certain parity?
> > >
> > > true.  certain algorithms exhibit certain "weakness" with some
> > > specific key values (i.e. weak and semi-weak keys); e.g. DES.
> > > currently, the library does not ensure/enforce such constraints.
> > > this will be addressed in future versions.
> >
> > DES does contain static methods for testing if a given key is weak,
> > as well as methods for testing/altering the parity bits. It's
> > trivial to add a test for them in the initialization.
>
> i forgot about those static methods.  adding the test that would be
> nice --see later.
>
> > The parity bits are now just an anachronism; if you give a
> > non-parity adjusted key to the makeKey method, it will produce the
> > same result as a parity adjusted key (erm, probably).
>
> i'll take your word for it :-)
>
> > So, isn't it the case that you can feed any arbitrary key bytes (of
> > the proper length) into any of the ciphers, and be guaranteed that
> > they will work?
>
> yes  --by "will work" i take it that checks for [semi-]weak keys are
> done in makeKey() mehod (also called by the init() method).  we can
> envisage a new exception (a subclass of InvalidKeyException, say
> WeakKeyException) that gets thrown if the cipher is initialised with
> weak key material.  this way existing code will continue to work, and
> the implementation will become more robust.
>
> does this make sense?
>
>
> cheers;
> rsn

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

iD8DBQE+0fO6+e1AKnsTRiERA6RIAJ45/HLXGX6Uw365TttuYHn1IOjocgCfcYNX
z40isPslUnYjXvTlRQJhxwY=
=0MYH
-----END PGP SIGNATURE-----