[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



*Encrypting the signature*: the draft proposes as an option the encryption
of the signature-message (although it is not specified, I guess it means
encryption using SK).
In this case some of the problems mentioned above are seemingly solved.
For example, information leaked on SK by the signature is now protected
(although encrypting a key under the same key cannot be claimed,
in general, to be secure). Also, E cannot as easily as before derive the
value of the internal MD5 computation. Moreover, if one uses encryption of
the signature (under SK), then the whole issue of signing SK can be avoided.

Still, I do not recommend the encrypted signature solution (which basically
becomes the basic STS protocol). The reasons are:

(1) I do not want to mandate symmetric encryption in the key management
protocol; and, most importantly,

(2) encryption is not the right function to use in order to "prove possession"
of a key.

Let me be more explicit about (2).
STS uses encryption under SK (where SK=g^xy) to "prove possession" of SK.
However, encryption is not the appropriate function to do that.
The reason is that encryption is usually "tamperable" (e.g., if I know
"text" and your encryption is a stream cipher then I can change E_SK(text)
to E_SK(text') for any text' of my choice without knowing SK at all).

Is that applicable to STS/Photuris? One can argue that it is not because
E does not know the value of SIG_I(g^x,g^y); however, assume an attacker
E that has stolen I's private key. Clearly, such an attacker will be
able to carry the above attack.
Is that a problem? On one hand, one can say that if E knows I's key she can
do whatever I (the initiator) can do and then this particular attack
is not interesting.  However, notice that E is achieving something that
the sole knowledge of I's private key cannot achieve: namely, convincing
E that she knows SK.
In some scenarios, and the bank example from [STS] can be such a scenario,
E will be able to mislead I and R in ways that the sole possession of I's
private key would not have permitted.

In other words, a good protocol needs to minimize the negative effects of an
exposed key (the whole idea of using Diffie-Hellman or perfect forward
secrecy is exactly that). I argue that the protocol should not show the
above vulnerability. A solution is to replace encryption by a MAC function
(which is already suggested in [STS] as an option).

(Encryption should remain as an *option* for the sole purpose of anonymity).

*MACing the signature*: Photuris.01 has also authentication of the signature
message as an option. I could not find in the specification the field
in the message that carries the MAC (e.g., the result of key-ed MD5 applied
to the message), but I assume it was just omitted by mistake in the description.

If one MACs the signature, and also signs SK, then the comments above about
weaknesses of signing a secret key still apply. However, as in the case of
encryption, if one does authenticate the signature using SK then why
also sign SK?
If one does not sign SK then the protocol becomes essentially STS with
MAC instead of encryption. From all the variants considered above this is
the only one that looks sound. However, this should be taken with care, I
personally do not feel completely comfortable with my understanding of
this variant. Actually, I can even point out to some delicate issues with it.
If one MACs using SK, then the adversary gets a pair
(known-text, MAC_SK(known-text)). Does this help the attacker to learn
something about SK? First, it gives this pair of known
plaintext, ciphertext which is otherwise unavailable, and even more
seriously, a generic MAC function does not guarantee any specific
protection of the key (for example, it may leak several bits of
the key, or some other information, and still be unforgeable as a MAC).

Does this last problem has a solution. Yes: from g^xy derive two keys,
one for the MAC of signature, the second the actual SK to be shared
by the parties for subsequent communication. If the two keys are derived
such that knowledge of one does not reveal information on the other
then the above problem is solved. Such two keys can be derived by an
appropriate use of a pseudorandom function.
[I can further elaborate on this in a future note]

There is also another solution to all the problems with the signature
message pointed out in this note (and others not mentioned here):
just do not use signatures.
This is what Photuris Plus (a.k.a. Photuris variant) does.
However, let me be clear on this, all the points made at the top of this
note (points 1-5) apply to Photuris Plus as well.

I guess you had enough for one note.

Hugo