[gnutls-dev]weak cryptography

[phr-2002@nightsong.com]

    > A GNU TLS-based web server
    > without weak cryptography support wouldn't be able to communicate
    > securely with these browsers.

    You seem to make an assumption that is not correct. You assume that
    the 40 bit restricted browsers, offer some security. 
    Actually they do not offer any security at all.

I don't agree with this.  40 bit browsers offer some security, enough
for some applications but not for others.

    It is better to 
    communicate in plain, instead of having a false feeling of security.

I don't agree with that either.  It's like saying it's better to leave
your house completely open, than lock the door but use a door weak
enough that an attacker can break it with a sledgehammer.  Almost
every house can be broken into with a sledgehammer but most people do
lock their doors and it's better than leaving them open.

    It is trivial to crack 40 bit protected communications by brute
    force.

It's not trivial and that's easy to prove: if I send you 1000 messages
encrypted with 32-bit encryption and offer to pay you 0.10 US dollars
for each message you can read, you might take the trouble to set up a
few workstations and make an easy 100 USD (it takes about one hour to
crack each key on a PC, so you'd let your network run for a few days).
But with 40-bit encryption, it takes weeks to crack each one and you
probably won't bother.  "Too much work to bother", by definition, is
non-trivial.

And If I offered 100 USD per message, then it would be worth it for 40
bits but probably not 56 bits, and so forth.

    Well, I'm not aware of software that cracks 40 bit restricted TLS
    sessions, but we shouldn't assume that there aren't such programs
    available in underground communities. One can use a network of
    general purpose computers to break 40 bit ciphers would in days or
    (in the worst case) weeks, which does really worth the effort.

Yes, programs like that are available.  40-bit ciphers are definitely
too weak for highly valuable messages.  But they are often ok for
not-so-valuable messages.  If the message is a digital coin worth 0.10
USD, then nobody will spend weeks of CPU time cracking it.  So whether
the 40-bit cipher is sufficient is completely application specific.

    As I said, I do not believe that the weak ciphers offer any
    security.

Of course you're entitled to that opinion, but you should not impose
the opinion on GNU TLS application programmers who may not feel the
same way.  They are not necessarily stupid; they know what compromises
are involved, and they know more than the library implementer what the
value (or lack of value) is of the data they're trying to protect.

    > even worse than the GNU TLS server case, since the GNU TLS browser
    > user will usually have no hope of persuading the server operator to
    > upgrade.  So again, s/he'll have to abandon the site or else turn
    > off TLS.

    He cannot persuade him, but he should not trust him bussiness anyway.
    Offering secure services restricted to 40 bit ciphers, is a joke.

In some cases (like typical e-commerce) the cryptography is intended
to protect the server and not the client.  If a user's credit card
number gets cracked, it causes some inconvenience for the user but
doesn't cost the user money--the user's bank is responsible for the
loss.  So I personally don't mind entering my credit card into a 40
bit website.  If someone cracks it, it's not my problem.  I call the
bank and they have to pay for it.  And if that happens occasionally,
the bank doesn't mind either, since covering such occasional losses is
part of their cost structure--basically an insurance policy takes care
of it and they have already allocated money for the expense.  It's
just a business problem to them, not a technical one.

But if 1000's of numbers are cracked, the bank and the merchant have a
big problem.  So the issue is not to make sure that no numbers ever
get cracked.  It's to make sure that 1000's of numbers don't get
cracked at once.  40 bit cryptography takes care of that, by making
each one take several CPU weeks.

It might not sound so nice to risk inconveniencing a user, but
remember that if you use your credit card in a restaurant, you're
giving it to a low-paid waiter who can copy the numbers directly from
the card because there's no encryption at all.  Yet everyone does that
all the time.  This is clearly a type of data that needs some
protection, but doesn't need ultra-strong protection.  In fact there
has never been a single known publicized case of an actual credit card
number being stolen by intercepting and decrypting it from a 40 bit
SSL web transaction.  Part of the reason is TCP/IP traffic is
reasonably private to begin with, but mostly it's because if someone
wants stolen credit card numbers, there are easier and cheaper ways to
get them than by attacking 40 bit SSL traffic.  (The usual way to get
them is by buying them from a dishonest merchant).

Finally, this discussion has mostly been about 40 bits, but for a
brief period some exportable browsers and servers supported 56 bit
ciphers.  I don't know if GNUTLS considers those "weak".  In practice,
they are breakable, but only with great difficulty, requiring special
hardware and/or very large distributed PC networks.

You might like to read "Secrets and Lies" by Bruce Schneier for more
discussion along these lines.  You've probably already read his
earlier book "Applied Cryptography".