Fedora crypto policy vs the real world Was: available crypto policies

[Pavel Kankovsky]

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?"