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

Security problems in Photuris #2



Ref:  Your note of Thu, 12 Oct 95 00:51:30 GMT (attached)

Here are my answers to Bill's message.
The moral is:

   We need a robust and secure Photuris for many years to come.
   Let's do it right.
   The mechanisms I propose pay no extra penalty relative to what is
   in Photuris today and they increase security and robustness.
   Let's not wait to last minute to do changes because I want my own
   proposals scrutinized by others.


 >
 > > From: hugo@watson.ibm.com
 > >
 > >      Summary of this message: I claim that the security of Photuris
 > >      needs to be guaranteed not only based on its default transforms,
 > >      but for any replacement of these transforms by other secure algorithms.
 >
 > I dispute your claim.  You did not specify the scope of "secure".

I wish the Photuris draft would have specified this scope. It would make the
whole specification clearer and more robust. I was not trying to get
too much into specifications. But, I believe it is clear from the rest
of my original message that the security of an algorithm is relative to the
functionality it gives.

For example, a signature algorithm provides for authentication and
unforgeability AND NOT FOR SECRECY.

 >
 > This statement would require that a zero-knowledge proof of a
 > Hamiltonian cycle (to pick something randomly from Schneier) would be an
 > appropriate algorithm for Photuris.

If you read my message it says

      To me this means that the protocol with the defined default algorithms is
      secure, but also that substituting any default algorithm by another that
      has the same required security functionality, e.g., encryption, signature,
      would result in a secure implementation of the protocol.

Notice the words "same required security functionality"; a zero-knowledge
proof of Hamiltonian cycle is a beautiful protocol but no one has claimed it
achieves any of the functionalities required by Photuris, like signature,
encryption, authentication, etc.

 >
 > >      The current definition of Photuris does not satisfy this criterion.
 > >      As an example, use of plain RSA signature as the signature attribute
 > >      in the protocol discloses the exchanged DH key.
 >
 > I cannot find _anywhere_ in our documents where a "plain" RSA signature

Plain RSA is not explicitely specified in Photuris. I gave it as a natural,
easy to understand, example of a signature function that does not hide the
signed text.

The basic point is: digital signatures do not hide text by definition (or
requirement). Hiding the text may (or may not) be achieved as a "side
effect" of particular mechanisms like hashing.
But even hashing, in general,  does *not* guarantee the hiding of text.
We are not even sure about this property for the current natural candidates
like MD5. We definitely cannot guarantee that property for each of the
algorithm that with time people will want to use with Photuris.
On the other hand, Photuris is "plain insecure" if this secrecy property is
not provided by the signature attribute.

Photuris has to be robust enough to remain secure for long time, even when
algorithms change (and they will!) because of efficiency or security reasons!!!!


 > is mentioned, let alone used.  Plain RSA alone is not secure for digital
 > signatures over any hidden text.  And it is "just plain inefficient"!

I don't want to discuss the merits of plain RSA. I am not proposing (or
recommending) using this mode of RSA. It is just a very natural, practical
example. (And if efficiency is your issue, then let me remark that it
is *more* efficient if the signed text is no longer than the RSA modulus,
as the case of Photuris with 155-bit elliptic curve)

 >
 > The forms of signatures specified are currently DNS-SIG, DSS, MD2, MD4,
 > MD5, PGP, PKCS, SHA, and X.509.  MD5 is required.  The others are not
 > specified in the base document, but have been split off to an extensions
 > document.  Therefore, I refuse to discuss their details until the base
 > is complete.
 >
 >
 > > Photuris is intended to be algorithm independent.
 >
 > No, it is not.

HUH?!

I thought Photuris follows the decisions of the IPSEC WG.
Let me cite from RFC1825 " Security Architecture for IP":

   This section describes some of the design objectives of this security
   architecture and its component mechanisms.  The primary objective of
   this work is to ensure that IPv4 and IPv6 will have solid
   cryptographic security mechanisms available to users who desire
   security.

   These mechanisms are designed to avoid adverse impacts on Internet
   users who do not employ these security mechanisms for their traffic.
   These mechanisms are intended to be algorithm-independent so that the
   cryptographic algorithms can be altered without affecting the other
   parts of the implementation.  These security mechanisms should be
   useful in enforcing a variety of security policies.

   Standard default algorithms (keyed MD5, DES CBC) are specified to
   ensure interoperability in the global Internet.

Let me highlight this part from the above citation:

 *************************************************************************
 * These mechanisms are intended to be algorithm-independent so that the *
 * cryptographic algorithms can be altered without affecting the other   *
 * parts of the implementation.                                          *
 *************************************************************************

And just to be clear about the point I made above, let me repeat it

    Photuris has to be robust enough to remain secure for long time, even when
    algorithms change because of efficiency or security reasons !!!!

 >               Only a few, well chosen, algorithms are specified.

For immediate interoperability purpose this is perfect.
But please give guidance to the future implementor/user on how to decide
on "well chosen" algorithms.


 >
 > Anything else would destroy interoperability and burden the implementor.
 >
 > Protocol designers are expected to have both knowledge and common sense.

Well, at least an issue where we are in complete agreement!!!

 >
 > Implementors are expected to follow the specification.

Again we are in agreement. This is *exactly* why I am so concerned about the
current specifications

 >
 > Bad assumptions lead to a bogus argument.
 >
 > 'Nuff said.
 >
 > Bill.Simpson@um.cc.umich.edu
 >           Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Bill, please. We are wasting time here. Let's go on. Stubborn defiance will
not help us.

And Phil, where are you????????

Hugo



Follow-Ups: