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

Re: A Photuris variant

> From: hugo@watson.ibm.com
> As for Photuris signature, when done off-line and without expiration
> (as proposed in the original draft) it indeed creates an opportunity
> for the attacker to steal ONE signature and use it "FOREVER" (i.e,
> for the duration of the public/private key pair). What is the "frame
> of minutes" you refer to?
>
Off-line?  By hand?  The Photuris draft has precomputation, but it is
very likely to be done on-line.

Despite the lack of a clear reference to a particular key database,
Photuris has _ALWAYS_ expected (at least in my recollection) to use
signatures with expirations.  Indeed, the initial implementations use
Kerberos tickets and Eastlake-Kaufman DNS Signatures.

The Photuris capability of using multiple databases is one of its
deployment strengths.  No waiting for X.509.


>    propose weakening the key structure to allow compromise of the traffic
>    (with a time frame of forever)!
>
> The idea is to let the user or implementation to choose the right
> tradeoff between computation and security without exposing it
> to hidden vulnerabilities.
>
Weakening.  A predictable future vulnerability may not be "hidden" from
security analysts, but it _is_ hidden from users.


> However, can you explain to me, as an author of the IPv4-AH draft,
> how perfect forward SECRECY works with NO SECRECY as is the case
> of parties using only AH (and there will be such parties, e.g.,
> when retrieving publicly available information that has no
> confidentiality but requires integrity protection)?
>
Of course.  That's obvious.


> Don't you think that some of these parties may prefer to save
> the four DH exponentiations (two each) and still get great
> security? The variant provides that (optionally, of course!).
>
Can't imagine why.  Would require user configuration on a connection by
connection basis.  Unlikely at best.  At worst, a vendor will make that
the default, because it's "faster".

And, in Photuris, it won't actually _be_ faster, when precomputation is
used.


> On the other hand, I was raising the issue of misuse of the protocol by
> your interlocutor in case you *sign* the fact that you are talking
> to him/her.
> That is one of the advantages of not using signatures. For example,
> nobody will be able to blackmail you saying that he/she can prove
> you were talking to him/her. This kind of privacy protection makes
> a lot of sense,  but it does not imply or require that you keep your
> identity secret from the guy you're talking to. Just do not provide
> a signed certificate that you did talk to him/her.
>
(sigh)  Blackmail?  Loaded words don't help here.

The signature is essential to identification, as used in the usual
terminology.  If the "name" is not a cryptologically signed certificate,
it is only a string of meaningless characters of no proven worth.


>    And the variant won't allow precomputation, so it is slower to setup.  A
>    fine new feature....
>
> The variant does allow for precomputation. You can precompute g^x exactly
> as before. As for precomputation of signatures, that is a trade-off
> existing in plain Photuris that represents a security weakness.
>
I disagree.  Let us stick to practical threats, not theoretical
ephemeral ones.  If your machine has been compromised, you will need new
signatures anyway.


> Most importantly, precomputation is NOT a requirement.
> The requirement, or desirable feature, is to provide clear computation/
> secuirty trade-offs. This is very cleanly provided by the variant.
>
Actually, I believe that precomputation _IS_ a requirement for realistic
deployment in existing hardware.  Again, practical.


>    Why would anyone want to go to the trouble of sending protected data,
>    using techniques that don't protect the data very well, to a party they
>    can't positively identify?
>
> I hope this problem with anonymity is now clear.

Yes, it is clear that you do not use the term "positively identify" in
the same fashion as the rest of us.


> As for not protecting data very well, my proposal protects data
> as good as Photuris does.
>
No, you do not in fact protect the data as well as Photuris.  Weakness
is weakness, even if it is "optional".

My question boils down to "why would anyone go to the trouble".  If you
say that nobody who knows what they are doing will use it, then why
define it?

Bill.Simpson@um.cc.umich.edu