Re: [openpgp] Proposal for a separable ring signature scheme compatible

On 03/14/2014 01:37 PM, Werner Koch wrote:
> It is all about probability.
>
> > goal here is simply cryptographic non-repudiability, Alice's peer is
> There is no such thing as mechanically created non-reputability.  But
> why make it too easy.
>
> > it doesn't make sense to rely on non-cryptographic signals (e.g. typical
> > OpenPGP implemnetation version information, etc) to rule out possible
> > cryptographic signers.
> I case we are speaking about this: The whole point of criminial
> investigations is to collect lots of evidence from _different sources_
> to prove or disprove a claim.
sure, i'm not claiming that cryptographic deniability is a particularly
useful feature in the courts.  Even with the extra limits you're
proposing, i'm not convinced it has much utility, though.  I've written
about this here (slightly different context, but much of the reasoning
applies):

  https://www.debian-administration.org/users/dkg/weblog/104

Do you think that saying "ring signatures are limited to these
new-fangled keys" would make the arguments for deniability stronger?

if so, why does making the specification *possible* to use with older
keys make them any weaker?  That is, if the spec makes it possible to
work with multiple key types, two users exchanging ring signatures with
ECC keys will be no worse off than if the spec constrains its users to
only allow ECC keys.  But a user corresponding with someone who still
uses an RSA key has *no way* to make a ring signature under the
constrained proposal, thereby removing what little argument they could
have made otherwise.  Why not leave the proposal open to those users?

So perhaps some guidance is suggested, along the lines of "Due to the
novelty of this scheme within OpenPGP as of this writing, making a ring
signature over multiple ECC keys offers more plausible deniability than
a ring signature covering an ECC key and any other form of public key"

Is there another argument for constraining ring signatures to ECC keys,
though?  for example, arguments by implementation simplicity,
efficiency, or mathematical clarity might be a good reason to constrain
the spec to new key types.

        --dkg

signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp