* [EMAIL PROTECTED] wrote on Fri, May 30, 2008 at 06:51 -0500:
> Back in the day, DES was the de facto encryption algorithm.
 [...] 
> In an ideal world, I think the system should throw an exception
> then and let the calling application feed it another key.
> However, I think the general consensus was that we should just
> ignore it.

I don't know what the general consensus was, but applications
I know do not ignore this situation but handle it by actively
rejecting it. Do you meant this by `ignore'?

I think best is to consider a weak or semi-weak [3-]DES[1] key as
a [3-]DES key acceptable and thus refuse to generate, store or
use it[2]. In practice usually it shouldn't be a big deal to iterate
a 16 elements table at key generation, which probably usually is
much more expensive.

So to say that DES is not defined / allowed for those numbers
(keys). I think it is a little like division by zero: it simply
cannot be done.

BTW, testing that can be difficult and probably needs special
considerations (e.g. some test driver with special `PRNG without
random' generating bits that lead to a weak key to check if the
generator correctly detects and refuses it).

oki,

Steffen

[1] A 3DES key with one weak or semi-weak key half should be
    considered weak (not essentially stronger than single DES).
[2] http://en.wikipedia.org/wiki/Weak_key tells as a main
    countermeasure: `Checking generated keys against a list of
    known weak keys, or building rejection of weak keys into the
    key scheduling.'
 
About Ingenico Throughout the world businesses rely on Ingenico for secure and 
expedient electronic transaction acceptance. Ingenico products leverage proven 
technology, established standards and unparalleled ergonomics to provide 
optimal reliability, versatility and usability. This comprehensive range of 
products is complemented by a global array of services and partnerships, 
enabling businesses in a number of vertical sectors to accept transactions 
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged 
information. If you are not the addressee or authorized to receive this for the 
addressee, you must not use, copy, disclose or take any action based on this 
message or any information herein. If you have received this message in error, 
please advise the sender immediately by reply e-mail and delete this message. 
Thank you for your cooperation.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to