gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Raif S. Naffah
Subject: Re: [GNU Crypto] how to deal with weak keys. was: Documentation
Date: Sat, 31 May 2003 08:00:01 +1000
User-agent: KMail/1.5.1

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

hello Casey,

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?


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


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

conditional compilation is manipulated by whoever packages the library 
within their own application.  once they change a value and compile a 
jar; no end-user can change the code --unless of course they can 
mainpulate the bytecode in the class files, but in this case they are 
not end-users.


>... and (3) it just seems like the "Java way"
> to do it.


cheers;
rsn


- ----- test.Configuration.java -----
package test;

import java.util.Properties;

public abstract class Configuration {
   public static final boolean WEAK_KEYS_ALLOWED = false;
   public static final String K_WEAK_KEYS_ALLOWED = 
"gnu.crypto.conf.weak.keys.allowed";
   public static final Properties configuration = new Properties();
   static {
      configuration.put(K_WEAK_KEYS_ALLOWED, Boolean.TRUE);
   }

   private Configuration() {
      super();
   }

   public static final boolean isWeakKeysAllowed() {
      Boolean val = (Boolean) configuration.get(K_WEAK_KEYS_ALLOWED);
      return (val == null ? false : val.booleanValue());
   }
}
- ----- test.Main -----
package test;

public class Main {
   private int rounds;

   private Main(int rounds) {
      super();
      this.rounds = rounds;
   }

   public static final void main(String[] args) {
      int r = Integer.valueOf(args[0]).intValue();
      Main task = new Main(r);
      task.execute();
   }

   private void execute() {
      int i;
      long t;
      t = -System.currentTimeMillis();
      for (i = 0; i < rounds; i++) {
         callWithCheck(i, i+1);
      }
      t += System.currentTimeMillis();
      System.out.println("using conditional compilation; "+t+"ms");
      t = -System.currentTimeMillis();
      for (i = 0; i < rounds; i++) {
         callWithoutCheck(i, i+1);
      }
      t += System.currentTimeMillis();
      System.out.println("using properties; "+t+"ms");
   }

   private void callWithCheck(int L, int R) {
      int w;
      L = (L & 0xFF) << 24 | (R & 0xFF) << 16 | (L & 0xFF) << 8 | R & 
0xFF;
      R = (R & 0xFF) << 24 | (L & 0xFF) << 16 | (R & 0xFF) << 8 | L & 
0xFF;
      w  = ((L >>>  4) ^ R) & 0x0F0F0F0F; L  ^= w << 4; R ^= w;
      w  = ((L >>> 16) ^ R) & 0x0000FFFF; L  ^= w << 16; R ^= w;
      w  = ((R >>>  2) ^ L) & 0x33333333; R ^= w << 2; L  ^= w;
      w  = ((R >>>  8) ^ L) & 0x00FF00FF; R ^= w << 8; L  ^= w;
      R = ((R << 1) | ((R >>> 31) & 1)) & 0xFFFFFFFF;
      w = (L ^ R) & 0xAAAAAAAA; L  ^= w; R ^= w;
      L = ((L << 1) | ((L >>> 31) & 1)) & 0xFFFFFFFF;
      if (Configuration.WEAK_KEYS_ALLOWED)
         check(L, R);
   }

   private void callWithoutCheck(int L, int R) {
      int w;
      L = (L & 0xFF) << 24 | (R & 0xFF) << 16 | (L & 0xFF) << 8 | R & 
0xFF;
      R = (R & 0xFF) << 24 | (L & 0xFF) << 16 | (R & 0xFF) << 8 | L & 
0xFF;
      w  = ((L >>>  4) ^ R) & 0x0F0F0F0F; L  ^= w << 4; R ^= w;
      w  = ((L >>> 16) ^ R) & 0x0000FFFF; L  ^= w << 16; R ^= w;
      w  = ((R >>>  2) ^ L) & 0x33333333; R ^= w << 2; L  ^= w;
      w  = ((R >>>  8) ^ L) & 0x00FF00FF; R ^= w << 8; L  ^= w;
      R = ((R << 1) | ((R >>> 31) & 1)) & 0xFFFFFFFF;
      w = (L ^ R) & 0xAAAAAAAA; L  ^= w; R ^= w;
      L = ((L << 1) | ((L >>> 31) & 1)) & 0xFFFFFFFF;
      if (Configuration.isWeakKeysAllowed())
         check(L, R);
   }

   private void check(int L, int R) {
      int w;
      L = (L & 0xFF) << 24 | (R & 0xFF) << 16 | (L & 0xFF) << 8 | R & 
0xFF;
      R = (R & 0xFF) << 24 | (L & 0xFF) << 16 | (R & 0xFF) << 8 | L & 
0xFF;
      w  = ((L >>>  4) ^ R) & 0x0F0F0F0F; L  ^= w << 4; R ^= w;
      w  = ((L >>> 16) ^ R) & 0x0000FFFF; L  ^= w << 16; R ^= w;
      w  = ((R >>>  2) ^ L) & 0x33333333; R ^= w << 2; L  ^= w;
      w  = ((R >>>  8) ^ L) & 0x00FF00FF; R ^= w << 8; L  ^= w;
      R = ((R << 1) | ((R >>> 31) & 1)) & 0xFFFFFFFF;
      w = (L ^ R) & 0xAAAAAAAA; L  ^= w; R ^= w;
      L = ((L << 1) | ((L >>> 31) & 1)) & 0xFFFFFFFF;
   }
}

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

iD8DBQE+19Rh+e1AKnsTRiERA+8ZAJ0Z9cllp79USvcbGXH8IiyZkcUiqgCgi0ox
/1GNtlEXIw9FQYoEzi/k6mg=
=PuhA
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]