general defensive crypto coding principles

Simon Josefsson jas at extundo.com
Wed Feb 8 12:47:52 EST 2006


"Travis H." <solinym at gmail.com> writes:

> Hey,
>
> In "Practical Cryptography", Schneier mentions a couple of general
> principles that he thinks wise when writing code which uses or
> implements cryptographic routines.
...
> 3) Authenticate the plaintext, not the ciphertext.  This is a general
> application of the rule "use semantically appropriate constructs". 
> That is, our point in signing is to authenticate the plaintext, not an
> encrypted version of it.  This has the drawback that decryption must
> occur before authentication, which is a possible DoS vector.

I wonder whether this is really a good suggestion, considering
Krawczyk's paper that show that this construct is not generically
secure.  See <http://eprint.iacr.org/2001/045>.

> 4) Try to eliminate security dependencies between modules.  That is,
> when you read from the RNG subsystem, check the values to see if they
> indicate a broken RNG (let's avoid pointing out the obvious problem
> with this by saying that all outputs are equally likely, and thus no
> sequence is more "random" than any other, in his code he just aborts a
> probabilistic algorithm if it fails too many times).

I'd say this leads to complex code that is difficult to audit.
Consequently a questionable recommendation.

> Then there are a few I'm not sure I understand:
>
> A) Allow a factor of two in strength increase.  That is, if you
> generate and use 1024 bit keys in the application, allow
> interoperability with 512-2048 bits.

A 1024 bit RSA key is not twice as strong as a 512 bit RSA key, nor is
a 2048 bit RSA key twice as strong as a 1024 bit RSA key.  Factoring
algorithm don't scale that way.

> I think this violates the interoperability rule "be liberal in what
> you accept and conservative in what you generate".

I believe it is now well accepted that this idiom is a poor idea for
security products in particular, and perhaps also in general.  You
should _not_ be liberal in what you accept.

> In particular, some of my sshd's don't accept 4096-bit keys, which
> annoys me greatly every time I try to ssh to them and it barfs into
> syslog.

Are you sure the above is the reason for this?  Perhaps the sshd
simply didn't support 4096 bit keys.

Cheers,
Simon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list