ietf-openpgp
[Top] [All Lists]

Re: Chosen-ciphertext attack on receiver anonymity

2005-07-05 04:22:08

On Tuesday 05 July 2005 04:13, Peter Gutmann wrote:

It's not just misleading, it's an absolute bastard to support for
implementors.  So I think it should be deprecated not only because it serves
little useful purpose, but also because the large amount of complexity added
in supporting it isn't reflected by any matching payback in security.

Right, that's what I feared.  Has anyone actually
implemented it *and* seen a benefit out in the field?

To which Brent answered:
As far as whether it is a problem, I believe that Hushmail uses such 
feature to implement BCC functionality. Also, I PGP is used in some other 
contexts such as newsgroups like alt.anonymous. In short it seems that 
some applications might rely on the feature whether it was intended to be 
strong or not.

Bummer.  Well, any views from Hushmail or from
whoever is encrypting to alt.anonymous?

Is there any reason why it has to be supported?
It's a MAY - just don't support it would be one
answer.  Hushmail supporting it in their 'closed'
system is fine, and as soon as they go out into
the broader world this is at their risk.

Maybe just mark the feature as only supported
within a given cooperating group of users - so
Hushmail can do it within their users, but it
won't be supported outside?

In the short term it might help to serve notice in some way. 
Perhaps a note of the RFC would be good. While there does seems to be a 
bit of work to do, it seems feasible to implement the feature properly. 
My opinion is that eventually it would probably be best to either provide 
the feature fully or remove it. Which one to do probably depends on what 
goals of PGP are.

I don't recall that the goals of PGP in the wider sense
ever really considered anonymity or psuedonymity
except in the sense of avoiding mistakes surrounding
meatspace identity and ending up with engineering
psuedonymity.  PGP history quite clearly expresses
that you can call yourself Micky Mouse, but it doesn't
extend much if any guarantees about whether the software
protects you against any threats that might arise in that
cartoon.

Certainly *this RFC* is not the place to start on that.
It would seem that we need some project or team
to explore the possibilities, and create some demo
patches to gpg, and a paper or two.  Starting another
RFC might be possible but on our current record, I'd
not suggest that.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting