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

[Marcel Winandy]

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

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.

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

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
- -- 
Marcel Winandy
EMail: address@hidden
http://www-student.informatik.uni-bonn.de/~winandy/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+1nXWjqlzsXwzXNwRAhowAJ9CYdwmd/LXyw4BQH6SbxPQWCiEyQCg6Cia
gL4fdlNrfXE4rqvWa+XZZTA=
=+mlX
-----END PGP SIGNATURE-----