On Tue, 6 May 2014, Hubert Kario wrote:
Firefox does say that the communication is impossible because the server
does not support the same encryption algorithms as the client.
There is no option to override. The problem is that the server won't
tell you which ciphers it wants (it may be RC4, it may be single
DES...).
The server won't tell it explicitly but the client can play some
trial-and-error. IMHO, two steps would be sufficient: First, try to
connect with secure ciphersuites. If it fails, try again with, ahem,
less secure ciphersuites, and warn the user.
(You may object that an encrypted connection is supposed to be simply
secure, not more secure or less secure, but I am afraid that ship has
already sailed with things like EV certs aboard.)
Such a feature would become useful again when it will be necessary to
phase out other ciphersuites (or protocol versions) in the future.
Firefox does tell you that you should contact the web site owner and
tell him about the problem.
...while the said contact is published on the site I am not allowed to
access. :)
You assume the client keeps sending the same secret data for a year.
Who changes passwords for an automated service on frequency higher than
once a year? It's set it and forget it (or are you trying to tell me
that you and all the people you know do change email passwords every 1-3
months?).
You argue that RC4 is not secure when used in a certain manner. I agree.
But I wanted to point out that there are other applications whose modus
operandi is less conductive to attacks on RC4 and that an unconditional
ban on the use of RC4 might perhaps be too drastic. (In fact, I am quite
familiar with one of the web apps on your list and I dare to say it is
very unlikely anyone will be able to exploit (known) weaknesses in RC4 to
do anything serious.)
BTW: If it's "set it and forget it" then passwords might not be the best
authentication method...
That's correct for attack that uses just single byte biases, there are
also double byte biases in RC4 output:
http://www.mindspring.com/~dmcgrew/rc4-03.pdf
Indeed, there are double-byte biases but their nature is similar. The
only important twists are: 1. they are not restricted to the initial part
of the keystream and 2. pairs of bytes can overlap (see below).
Like I said, the attacks assume random plaintext. While in reality, all
plaintexts have internal structure (the protocol used, be it HTTP, SMTP
or POP3). Coupled with double byte biases you are able to recover
unknown, but unchanging (like passwords or pre shared keys), bytes of
plaintext.
Let us assume we need to collect 2^20 ciphertexts to guess a certain
plaintext byte (with probability very close to 1) with no prior
information about the byte (in order words: our prior probability
distribution is uniform for all values from 0 to 255). This means that the
average information content we can extract from one ciphertext is 8 / 2^20
= 2^-17 bits. Yes, a tiny fraction of a bit.
If you start with some nontrivial priors (e.g. an assumption that the byte
is an ASCII code of an alphanumeric character), you reduce the total
amount of information you need to collect but the reduction is
proportional to the fraction of bits of information provided by said
priors: if you assume that there are, say, only 16 = 2^4 possible values
of the plaintext byte, you still need to analyze 4 / 2^-17 = 2^19
ciphertexts. 50 % of bits, 50 % of work. (BTW: compare this result to
figure 8 in AlFardan et al.)
Let us look at double-byte biases now: the straightforward approach would
recover individual pairs of bytes (16 bits) but if those pairs overlap
(they do when you are after several consecutive bytes) you can correlate
your guesses and reduce "degrees of freedom" to half (8 bits per one
pair). The strength of double-byte biases (+/- 2^-8) is comparable to the
strength of an average single-byte bias but they occur less frequently
(cca 2^-12 vs 2^-8) therefore I do not think the use of double-byte
biases would make the attack considerably easier.
The biases are a bad problem but they are not bad enough to make it
possible to crack plaintext with a handful of ciphertexts.
--
Pavel Kankovsky aka Peak "Que sais-je?"
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
