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

[Raif S. Naffah]

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

hello Marcel,

On Fri, 30 May 2003 07:04 am, Marcel Winandy wrote:
> Hello everybody!
>
> I think this discussion will be useless until we've not agreed upon
> the design goals and objectives of GNU Crypto as a whole. It's very
> important to know where the position of the GNU Crypto library will
> be placed.
>
> Again, the question is: shall it be set of pure algorithms with no
> "intelligence" or shall it be a robust and secure software package
> that can perform secure cryptographic operations?
>
> In the latter case you can use the library as a kind of
> "cryptographic token" (compare to PKCS#11). At first, you'll set up
> some parameters, then you give input to that "token" and get some
> output (mainly encrypted/decrypted or signed/verified messages). The
> "token" is responsible for creating a secure output. While performing
> an operation the "token" cannot be tampered. It can be seen as a
> shielded black box. And it will warn the user if the input or the
> provided parameters are not valid/secure.
>
> And I think that's the place to be!
>
> If we made the user responsible for checking weak parameters, there
> wouldn't be any need for a high level API, e.g. classes like Assembly
> or Transformation, etc. And normally, it's good object oriented
> design to make an object responsible for proper operations and not
> its user!
>
> When talking about a high level API it's necessary to talk about high
> level design first. I think that's the main issue. Whether DES is
> relevant or not, there must be a design decision about how to handle
> weak parameters in general. This includes weak keys, weak domain
> parameter, weak input, weak operation modes, and so on.
>
> There is one very important principle of software engineering (beside
> some others): anticipation of change! We must not consider DES alone.
> It's important to consider any (known) weaknesses. Especially, when
> P1363 shall be integrated (as stated at the project website).
>
> Being conform to P1363 techniques requires a lot of decisions about
> responsibility for verification and validation against known attacks
> and weaknesses. There are a lot of optional or required checking
> operations. It is crucial to decide where to put these operations.
>
> My suggestions is as follows. Make a global design considering future
> integration of cryptographic schemes and methods. Define a global
> policy how to handle weak (but valid) parameters in the whole
> library. I mean define if and how such handling shall be implemented.
>
> I'll prefer a design like the "token" or black box approach described
> above. However, it could be possible (and maybe necessary) to operate
> optionally(!) with weak parameters. But in that case the user (or
> using system) shall be informed explicitly.
>
> In the next step, one can decide and design how this optional "weak
> mode" is being configured or set up. This could be done either
> globally for the whole library or locally for every single operation.

the consensus we have so far is IMO summed up as follows:

* the library provides high quality algorithms implementation and 
primitives, incl. those to check for weak keys.

* the library does not enforce one and only one way of handling weak 
keys, instead,

* it allows the user --in this case a programmer, not an end user-- to 
set his preferences on how to package the library in their application.


> Casey Marshall wrote:
> > I don't think conditional compilation is a particularly good idea;
> > it's inelegant, and can easily lead to obscure incompatibility
> > bugs.
>
> I agree. Additionally, conditional compilation comes from C and it's
> no good Java or even object orientated code.

i disagree.  see my previous reply to Casey.


> > I would prefer using a properties class because (1) no-one will
> > care about, or even notice, any performance boost; (2) the security
> > aspects of these properties can be handled with the access-control
> > methods
>
> Again, I agree. But there is something to consider: at what time
> shall we ask that property class what properties are set, especially
> when we must decide to allow weak keys (or domain parameters). I
> think that shouldn't be done everytime we start some operation.
> Instead of this it should be done at instantiation time, i.e. when an
> object is constructed.

there are two issues here:

1. should we allow this feature per class, or per instance of the 
library, and

2. the point you raise, which can only occur if we dont use conditional 
compilation; i.e. when to know about it.


from the discussions that preceded, and which made me see a benefit in 
not disallowing weak keys, the argument was an application-wide 
decision, and not an algorithm specific one.  so my answer to the first 
point would be to have this option on a per instance of the library not 
the algorithm.

the second point it moot to me becasue i still see benefits in 
conditional compilation, that properties or attributes do not offer.

the problems with those latter methods is that they are open to being 
subverted from the original programmer/packager intention.

the attached code demonstrates how a property that was set to false can 
be changed during runtime.  just run it with the following additional 
options:

   -Djava.security.manager -Djava.security.policy=no.policy

- ----- Algorithm -----
package test;

import java.lang.reflect.Field;

public class Algorithm {

   private boolean weakAllowed = false;

   public static final void main(String[] args) throws Exception {
      Algorithm obj = new Algorithm();
      obj.makeKey(); // weak NOT allowed...
      // change it to true
      Field f = null;
      Field[] fields = obj.getClass().getDeclaredFields();
      for (int i = 0; i < fields.length; i++) {
         if (fields[i].getName().equals("weakAllowed")) {
            f = fields[i];
            break;
         }
      }
      boolean oldValue = ((Boolean) f.get(obj)).booleanValue();
      System.out.println("old value = "+oldValue);
      f.set(obj, Boolean.TRUE);
      boolean newValue = ((Boolean) f.get(obj)).booleanValue();
      System.out.println("new value = "+newValue);

      obj.makeKey(); // weak allowed...
   }

   private void makeKey() {
      if (weakAllowed) {
         System.out.println("weak allowed...");
      } else {
         System.out.println("weak NOT allowed...");
      }
   }
}
- ----- no.policy -----
grant { permission java.security.AllPermission; };
- -----


>
> So it can be some argument to the constructor of a class. For
> example:
> ---------------------------------------------------------------------
>--- class CryptoOperation {
>     private boolean weakAllowed;
>
>     public CryptoOperation(Param1 p1, Param2 p2, boolean
> allowWeakMode) { // some initialization...
>         weakAllowed = allowWeakMode;
>     }
>
>     public Operation() {
>         if (weakAllowed) {
>             // weak operation possible...
>         } else {
>             // strong cryptography...
>         }
>     }
> }
> ---------------------------------------------------------------------
>---
>
> Using this code pattern makes it easy to be flexible enough. However,
> the the user can be aware of any weaknesses. Once a weak mode is not
> allowed to one object, no weak operation will be possible with that
> object. However, you can create 'weak' objects, e.g. to be backward
> compatible.
>
> It's not up to the user anymore to decide _what_ is a weakness. This
> can be a special group of keys, the key length, the properties of
> domain parameters, or something completely different. The definition
> of weakness and the verfication of it can be encapsulated. This
> allows a very easy to use and high level interface for both users and
> other applications.
>
> Ciao,
>  Marcel

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

iD8DBQE+1+LK+e1AKnsTRiERAxJDAKDJxTdXuPCGoaYtsU7lwEwtzJI+sACgmEHp
DCwswsGlgfbi678hqfj32TQ=
=d4aL
-----END PGP SIGNATURE-----