Subject: re: separation of signed and encrypted messages

From: "vedaal" <[email-masked]>
Date: Tue, 16 Oct 2001 10:01:57 -0400

David Hopwood wrote:

>vedaal wrote:
> is there any way to separate a message that was signed and encrypted
> to a dh key, into a free-standing verifiable signed message?

>If-and-only-if the private encryption key is known, yes. This is no
>different to 'sign and RSA-encrypt'

yes,
but is there any way to do it, short of rewriting gpg, pgp to include a -d
command similar to the -d command of 2.6.3?

on a related note:

the separation that can be done now, is from 2.6.x using the command:
  pgp -da (filename).pgp
which (after giving the correct passphrase), produces
 filename.asc
which is a free-standing armored signed file, verifiable, and displaying the
text of the original message,
but,
is clearly different from an intentional armored signature file, which
usually begins with 'ow' as the first two characters
of the pgp block,

so,

would it be possible to somehow link such a separated signed file, and show
that it had to be from a specific
signed and encrypted file?  {possibly through an mdc tag on the armor}

if it 'could' be done,

then, one would 'not' have to surrender a session key or secret key, to
decrypt a signed and encrypted e-mail,

one could simply {from a remote area, without anyone needed to 'witness' the
decryption process}
separate it into the armored signed file, and release that to the
'authorities', and show that it had to have come from
the specific signed and encrypted e-mail in question.

vedaal

---

From: "Michael Young" <[email-masked]>
Date: Tue, 16 Oct 2001 11:29:06 -0400

-----BEGIN PGP SIGNED MESSAGE-----

> > command similar to the -d command of 2.6.3?

It doesn't appear that GnuPG has such a switch now.  But it would
be easy to build.

> one could simply {from a remote area, without anyone needed to 'witness'
> the decryption process}

No.  The message(+signature) contents are symmetrically encrypted.
There is no way to prove that the plaintext generates that specific
ciphertext without giving up the session key.  Demonstrating
a decrypted signature or MDC shouldn't convince anyone that the
full plaintext matches that ciphertext.

If you're willing to show the plaintext, why do you care about
protecting the session key?  Are you reusing it?  This might be an
issue for a PGPdisk, for example, where one symmetric key protects the
entire contents...  you can't reveal+prove selected parts.  It
shouldn't be for ordinary OpenPGP uses.  Are you afraid that
your randomness source has been compromised, such that other
session keys could be deduced?  If so, you have a serious problem.

---

From: Derek Atkins <[email-masked]>
Date: 16 Oct 2001 11:40:18 -0400

Actually, revealing the encrypted-session-key for an OpenPGP message
should give you sufficient information to link the plaintext to the
encrypted message without actually giving away your private key or
passphrase.  Considering that PGP implementations should be choosing
random session keys, this implies that session keys should not be
re-used.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "vedaal" <[email-masked]>
Date: Tue, 16 Oct 2001 13:08:23 -0400

- ----- Original Message ----- 
From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 16, 2001 11:29 AM
Subject: Re: separation of signed and encrypted messages

> entire contents...  you can't reveal+prove selected parts.  

for an rsa key,
if one has the session key, ciphertext and plaintext,
and, at some point, 
*if*
md5 is 'fully' broken,
would it not be possible to retrieve the secret key and passphrase?

vedaal

---

From: "Michael Young" <[email-masked]>
Date: Tue, 16 Oct 2001 13:31:17 -0400

-----BEGIN PGP SIGNED MESSAGE-----

> would it not be possible to retrieve the secret key and passphrase?

I think you may have two different uses of symmetric keys mixed up.
A symmetric key protects the private part of your public/private keypair;
it is the one generated from your passphrase (using a hash, such as MD5).
Another "session key" protects the contents of a message; for messages
encrypted to a public key, it is random, and involves no hashing or
passphrase.

An "attacker" can already generate any number of session keys and
ciphertexts to go with your plaintext and signature (once you're
willing to reveal that).  They can encrypt those session keys with
your public key.  Giving out the one session key for a particular
ciphertext does no harm, unless that session key is (improperly)
related to others.

If you were considering encrypting directly to a passphrase, and the
hash were *badly* broken (such that you could generate pre-images of a
constrained pattern from an end hash), then indeed, this could be
a concern.  From the session key and salt, you might be able to
back-compute the passphrase.  If it were used elsewhere, then you
could be in trouble.  Still a little far-fetched.  Moreover,
you said "RSA", so I don't think this is what you meant.

---

From: "vedaal" <[email-masked]>
Date: Tue, 16 Oct 2001 14:17:59 -0400

Sent: Tuesday, October 16, 2001 1:31 PM

> encrypted to a public key, it is random, and involves no hashing or

yes,
am sorry,
did indeed confuse this and thought it was the 'same' symmetric key as the
session key,

thanks for clearing it up,

vedaal

---

From: Matthew Byng-Maddick <[email-masked]>
Date: Tue, 16 Oct 2001 19:40:45 +0100

> would it not be possible to retrieve the secret key and passphrase?

Erm. No.

Think about the encryption process in the first place.

MBM

-- 
Matthew Byng-Maddick         <[email-masked]>           http://colondot.net/

---

From: Florian Weimer <[email-masked]>
Date: 17 Oct 2001 10:05:47 +0200

> It doesn't appear that GnuPG has such a switch now.  But it would

The diff is a couple of lines.  I can provide details if someone wants
to work on it.  We've got a working patch for 1.0.3 or so, but chances
are minuscule that it will appear in the official GnuPG distribution.
(That's not Werner's fault, the FSF is not interested in contributions
from the University of Stuttgart in general.)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: Werner Koch <[email-masked]>
Date: Wed, 17 Oct 2001 10:42:36 +0200

> from the University of Stuttgart in general.)

That is a bit too simplistic view.  The fact is that the FSF requires
copyright assignment for all core GNU software (see
http://www.gnu.org/copyleft/why-assign.html).  For reasons German
lawyers - specialized on Free Software issues - can't agree with, that
university does not want to sign such papers.

One of the reasons to found the FSF-Europe ist to tackle such legal
problems.  Eben Moglen is now working with European lawyers to get these
things solved. 

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: Florian Weimer <[email-masked]>
Date: 19 Oct 2001 12:52:30 +0200

Werner Koch <[email-masked]> writes:

> That is a bit too simplistic view.

It's the view most favorable for the FSF. ;-)

The contributions which had already been written were relatively minor
(a fraction of a man month, I think, at least if you exclude the
problem isolation phase and all the testing), so they weren't worth
the extra trouble an individual assignment contract would involve.  Of
course, this has stifled further development, but the FSF should not
be surprised by this.

> For reasons German lawyers - specialized on Free Software issues -
> can't agree with, that university does not want to sign such papers.

However, the FSF still has to tell the university the result of their
consultations. :-/

(We should take this to private mail, I think.)