Re: [GNU Crypto] how to deal with weak keys. was: Documentation

[Casey Marshall]

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

On Sat, May 31, 2003 at 08:00:01AM +1000, Raif S. Naffah wrote:

> On Thu, 29 May 2003 08:52 am, Casey Marshall wrote:
> > On Thu, May 29, 2003 at 05:07:31AM +1000, Raif S. Naffah wrote:
> > > On Thu, 29 May 2003 05:00 am, Casey Marshall wrote:
> > > > It would probably be more appropriate to have a class in
> > > > gnu.crypto that contains static methods such as set/getProperty,
> > > > so we can use a PropertyPermission check before querying/setting
> > > > these (sometimes sensitive) properties.
> > >
> > > if we do that we lose the conditional compilation benefit.  for
> > > performance reasons mostly, and security secondly i'd rather have
> > > them as static finals.
> >
> > I don't think conditional compilation is a particularly good idea;
> > it's inelegant, and can easily lead to obscure incompatibility bugs.
> 
> what sort of incomptibility bugs?  any examples?
> 

Ok. Compile test.Main and test.Configuration. Change
test.Configuration.WEAK_KEYS_ALLOWED to its opposite, and recompile
test.Configuration only. Depending on your compiler, test.Main now does
the wrong thing.

The biggest problem with conditional compilation is that you can pretty
much forget about binary compatibility. For every boolean constant used
in this fashion you split your code base into two similar, but slightly
different, code bases. Keep adding tests of this sort and you get
exponentially many different libraries.

> > I would prefer using a properties class because (1) no-one will care
> > about, or even notice, any performance boost;
> 
> i've written a sample code (attached at end) to show that there's a 
> difference in performance.
> 

First of all the test is unfair (the constant is false, while the
property is true). Secondly all it proves is that a handful of
instructions takes longer than no instructions.

The point is still that no one using the library will notice or care; we
are talking milliseconds here.

> >... (2) the security
> > aspects of these properties can be handled with the access-control
> > methods already implemented in Java (unless we regard Java's security
> > model as merely cosmetic);
> 
> the java access control are "run-time" based permissions that can be 
> altered by whoever installs, and/or have access to the launcher of the 
> application.  using the -Djava.security option and an appropriate 
> policy file, that person (or somebody on their behalf, or because of 
> their action) can change the way the code behaves contrary to what the 
> packager intended.
> 

So?

It is possible to use properties that ignore -D on the command line by
using a private properties class. Applications that consider these
properties sensitive can install their own security manager that forbids
access to them.

I am still not convinced that something so minor (and nearly irrelevant
w/r/t the library's security) is worth distributing different binaries
for.

I've attached what I had in mind.

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

iD8DBQE+1/s9gAuWMgRGsWsRAnmAAJ9H9UcMJhUNQ1OlP3U+XybQ91Cd4gCfYzIC
QfD9oRepmi5yJcoQxhqsBCI=
=DIps
-----END PGP SIGNATURE-----

weak.diff
Description: Text document

Properties.java
Description: Text document

WeakKeyException.java
Description: Text document