Mailing List Archive

Stefan Claas <sac@300baud.de>:

>I was reading old GnuPG threads were people were asking if it's
>possible to extract a signature from an encrypted message.
>
>I would like to ask, I don't know if this is already possible or
>if it's planned, if Alice would request from Bob that he always
>signs his messages and Bob, lazy as he is, often forgets this,
>can Alice check if Bob's encrypted message(s) have signed byte(s)
>set, without actually decrypting or revealing Bob's identity?

As far as I know this is impossible, because messages are first
signed and then encrypted, i.?e. the signature is encrypted,
too.  Therefore there is no access to the signature unless the
message is decrypted. 

>If the encrypted messages would not be signed then Alice can
>simply discard the message(s).

Yes, but why should she want to be able to do that?  She could
decrypt the message and, if it turns out that the message is not
signed, discard the message. 

>And is this optional in GnuPG, in case it is already implemented?


As far as I know the order “first sign, then encrypt” is
mandatory, so there is no way for GnuPG to deviate from it. 

And this is a good thing, as it thwarts Eve eavesdropping on the
originator's identity (i.?e. Bob) of a message sent to Alice. 

Helmut

Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:

> Stefan Claas <sac@300baud.de>:
>
> >I was reading old GnuPG threads were people were asking if it's
> >possible to extract a signature from an encrypted message.
> >
> >I would like to ask, I don't know if this is already possible or
> >if it's planned, if Alice would request from Bob that he always
> >signs his messages and Bob, lazy as he is, often forgets this,
> >can Alice check if Bob's encrypted message(s) have signed byte(s)
> >set, without actually decrypting or revealing Bob's identity?
>
> As far as I know this is impossible, because messages are first
> signed and then encrypted, i.?e. the signature is encrypted,
> too.  Therefore there is no access to the signature unless the
> message is decrypted. 
>
> >If the encrypted messages would not be signed then Alice can
> >simply discard the message(s).
>
> Yes, but why should she want to be able to do that?  She could
> decrypt the message and, if it turns out that the message is not
> signed, discard the message.

It would allow Alice (in her organization), or others, to do a
pre-check, with procmail etc., to set-up an auto-responder, informing
Bob that he did not signed his message and that his message will be
discarded.

> >And is this optional in GnuPG, in case it is already implemented?
>
>
> As far as I know the order “first sign, then encrypt” is
> mandatory, so there is no way for GnuPG to deviate from it. 
>
> And this is a good thing, as it thwarts Eve eavesdropping on the
> originator's identity (i.?e. Bob) of a message sent to Alice. 

It should be not a mandatory feature and it should only append
secured bytes, which are stating that Bob's message contains a
signature (yes|no bytes), without revealing his identity.
Assuming the would technically possible.

Regards
Stefan

--
NaClbox: cc5c5f846c661343745772156a7751a5eb34d3e83d84b7d6884e507e105fd675
The computer helps us to solve problems, we did not have without him.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

* 2020-10-11 02:40:28+02, Stefan Claas wrote:

> I was reading old GnuPG threads were people were asking if it's
> possible to extract a signature from an encrypted message.

It seems that there is a visible signature packet in encrypted and
signed messages. See the output of this command:

echo message | gpg --encrypt --sign --default-recipient-self | \
gpg --list-packets

--
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

Stefan Claas wrote:

> Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:
>
> > Stefan Claas <sac@300baud.de>:
> >
> > >I was reading old GnuPG threads were people were asking if it's
> > >possible to extract a signature from an encrypted message.
> > >
> > >I would like to ask, I don't know if this is already possible or
> > >if it's planned, if Alice would request from Bob that he always
> > >signs his messages and Bob, lazy as he is, often forgets this,
> > >can Alice check if Bob's encrypted message(s) have signed byte(s)
> > >set, without actually decrypting or revealing Bob's identity?
> >
> > As far as I know this is impossible, because messages are first
> > signed and then encrypted, i.?e. the signature is encrypted,
> > too.  Therefore there is no access to the signature unless the
> > message is decrypted. 
> >
> > >If the encrypted messages would not be signed then Alice can
> > >simply discard the message(s).
> >
> > Yes, but why should she want to be able to do that?  She could
> > decrypt the message and, if it turns out that the message is not
> > signed, discard the message.
>
> It would allow Alice (in her organization), or others, to do a
> pre-check, with procmail etc., to set-up an auto-responder, informing
> Bob that he did not signed his message and that his message will be
> discarded.
>
> > >And is this optional in GnuPG, in case it is already implemented?
> >
> >
> > As far as I know the order “first sign, then encrypt” is
> > mandatory, so there is no way for GnuPG to deviate from it. 
> >
> > And this is a good thing, as it thwarts Eve eavesdropping on the
> > originator's identity (i.?e. Bob) of a message sent to Alice. 
>
> It should be not a mandatory feature and it should only append
> secured bytes, which are stating that Bob's message contains a
> signature (yes|no bytes), without revealing his identity.
> Assuming the would technically possible.

I think something along the lines like Zero Knowledge Proof Encryption.

Regards
Stefan

--
NaClbox: cc5c5f846c661343745772156a7751a5eb34d3e83d84b7d6884e507e105fd675
The computer helps us to solve problems, we did not have without him.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi Teemu,

On Sun, 11 Oct 2020 11:02:00 +0200,
Teemu Likonen wrote:
> * 2020-10-11 02:40:28+02, Stefan Claas wrote:
>
> > I was reading old GnuPG threads were people were asking if it's
> > possible to extract a signature from an encrypted message.
>
> It seems that there is a visible signature packet in encrypted and
> signed messages. See the output of this command:
>
> echo message | gpg --encrypt --sign --default-recipient-self | \
> gpg --list-packets

The signature information is normally (that is, when doing sign then
encrypt) completely encapsulated by the encryption container. What I
think you are seeing is gpg caching something. If you replace 'gpg
--list-packets' with 'pgpdump', then you probably won't see any
signature information.

:) Neal

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

* 2020-10-11 22:47:01+02, Neal H. Walfield wrote:

> On Sun, 11 Oct 2020 11:02:00 +0200,
> Teemu Likonen wrote:
>> It seems that there is a visible signature packet in encrypted and
>> signed messages. See the output of this command:
>>
>> echo message | gpg --encrypt --sign --default-recipient-self | \
>> gpg --list-packets
>
> The signature information is normally (that is, when doing sign then
> encrypt) completely encapsulated by the encryption container. What I
> think you are seeing is gpg caching something. If you replace 'gpg
> --list-packets' with 'pgpdump', then you probably won't see any
> signature information.

Thank you. I was surprised to see all the packets listed with "gpg
--list-packets" but trusted its output. It seems that my "gpg
--list-packets" command (see above) decrypts the message using the
cached secret key and then shows all the packets.

As you said "pgpdump" don't show any signature information. There is
just a public key encrypted session key packet and a symmetrically
encrypted message packet.

--
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

On Sun 2020-10-11 09:59:12 +0200, Stefan Claas wrote:
> Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:
>> Yes, but why should she want to be able to do that?  She could
>> decrypt the message and, if it turns out that the message is not
>> signed, discard the message.
>
> It would allow Alice (in her organization), or others, to do a
> pre-check, with procmail etc., to set-up an auto-responder, informing
> Bob that he did not signed his message and that his message will be
> discarded.

The traditional answer for supporting this kind of workflow for e-mail
is called "triple-wrapping" -- see RFC 2634. That is, there is an inner
signature, then a layer of encryption, and an outer signature that is
intended to be visible to the transport agents handling the encrypted
message. Those transport agents (or procmail, or autoresponders, or
whatever) may may routing or handling decisions based on the outer
signature without any knowledge of the inner signature. However, i have
not seen triple-wrapping in wide-spread, interoperable use. Most MUAs i
have experience with do not generate triple-wrapped messages, and i've
found very few transport agents that interpret using them. IIUC, the
only triple-wrapping implementations out there use S/MIME cryptographic
e-mail, not PGP/MIME.

More common on today's e-mail interactions is "Domain-keyed Internet
Mail" or DKIM -- see RFC 6376. This is a cryptographic signature over
the entire message that is typically added by the sender's relaying
transport agent -- the first transport agent that handles the e-mail
message.

Subsequent transport agents can verify the DKIM signature using the DNS
as a form of proof-of-origin (typically, this is managed at the domain
level, though domain operators may carve up the "selector" space for
outsourced transports, or may also permit users to manage their own
selectors [0]). This isn't exactly the same as an individual sending a
message that is signed by the message origin, because DKIM signing tends
to happen away from the originating endpoint. But for spam abatement
and reputational systems, knowing that a message is signed by the domain
itself is often good enough in practice.

[0] https://tools.ietf.org/html/rfc6376#section-3.1
https://www.giovannimascellani.eu/dkim-for-debian-developers.html

So there isn't really a good (or reasonable) way to do what you're
asking for with OpenPGP directly. Given that mail is a complicated
interoperability space, you're probably better off conditioning your
procmail filters or autoresponder based on DKIM signature validity
(though i advise reading and understanding the associated DMARC
specifications before choosing to aggressively reject mail).

Hope this helps,

--dkg

On 2020-10-13 17:02, Daniel Kahn Gillmor via Gnupg-users wrote:
> On Sun 2020-10-11 09:59:12 +0200, Stefan Claas wrote:
>> Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:
>>> Yes, but why should she want to be able to do that?  She could
>>> decrypt the message and, if it turns out that the message is not
>>> signed, discard the message.
>>
>> It would allow Alice (in her organization), or others, to do a
>> pre-check, with procmail etc., to set-up an auto-responder, informing
>> Bob that he did not signed his message and that his message will be
>> discarded.
>
> The traditional answer for supporting this kind of workflow for e-mail
> is called "triple-wrapping" -- see RFC 2634. That is, there is an inner
> signature, then a layer of encryption, and an outer signature that is
> intended to be visible to the transport agents handling the encrypted
> message. Those transport agents (or procmail, or autoresponders, or
> whatever) may may routing or handling decisions based on the outer
> signature without any knowledge of the inner signature. However, i have
> not seen triple-wrapping in wide-spread, interoperable use. Most MUAs i
> have experience with do not generate triple-wrapped messages, and i've
> found very few transport agents that interpret using them. IIUC, the
> only triple-wrapping implementations out there use S/MIME cryptographic
> e-mail, not PGP/MIME.
>
> More common on today's e-mail interactions is "Domain-keyed Internet
> Mail" or DKIM -- see RFC 6376. This is a cryptographic signature over
> the entire message that is typically added by the sender's relaying
> transport agent -- the first transport agent that handles the e-mail
> message.
>
> Subsequent transport agents can verify the DKIM signature using the DNS
> as a form of proof-of-origin (typically, this is managed at the domain
> level, though domain operators may carve up the "selector" space for
> outsourced transports, or may also permit users to manage their own
> selectors [0]). This isn't exactly the same as an individual sending a
> message that is signed by the message origin, because DKIM signing tends
> to happen away from the originating endpoint. But for spam abatement
> and reputational systems, knowing that a message is signed by the domain
> itself is often good enough in practice.
>
> [0] https://tools.ietf.org/html/rfc6376#section-3.1
> https://www.giovannimascellani.eu/dkim-for-debian-developers.html
>
> So there isn't really a good (or reasonable) way to do what you're
> asking for with OpenPGP directly. Given that mail is a complicated
> interoperability space, you're probably better off conditioning your
> procmail filters or autoresponder based on DKIM signature validity
> (though i advise reading and understanding the associated DMARC
> specifications before choosing to aggressively reject mail).
>
> Hope this helps,

Thank you very much for your detailed reply, much appreciated!

P.S. already replied yesterday off-list and had deleted the message,
hence my short reply here.

Best regards
Stefan

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Stefan Claas <sac@300baud.de>:
>Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:
>> Stefan Claas <sac@300baud.de>:

[.The ability to check that an encrypted message has been signed.] 


>It would allow Alice (in her organization), or others, to do a
>pre-check, with procmail etc., to set-up an auto-responder,
>informing Bob that he did not signed his message and that his
>message will be discarded.

>>> And is this optional in GnuPG, in case it is already
>>> implemented?
>>
>> As far as I know the order “first sign, then encrypt” is
>> mandatory, so there is no way for GnuPG to deviate from it. 
>>
>> And this is a good thing, as it thwarts Eve eavesdropping on the
>> originator's identity (i.?e. Bob) of a message sent to Alice. 
>
>It should be not a mandatory feature and it should only append
>secured bytes, which are stating that Bob's message contains a
>signature (yes|no bytes), without revealing his identity.

What do you mean by the term “secured bytes”?


To check, whether a message pretends to have been signed by Bob,
one could check, that the “content-type” message header field has
got the value “multipart/signed” (look at my message, for
example). 

I say “pretends to have been signed” rather than “has been
signed”, because Mallory could grab the (unencrypted) message,
remove the signature (if present), either put it into a
“multipart/signed” structure, attaching an (of course then) bad
signature of one of Bob's signed messages or just sign it by
herhelf.  Then she would send the result to Alice. 

To be sure, whether the message has actually been signed by Bob,
Alice would of course have to check the signature.  But this would
reveal the identity of the signing key, and, if (the owner of) the
signing key is known to the recipient, the identity of the
signer.  (After all, proving the identity of the signer and the
authenticity of the signed message is the purpose of signing a
message.) 

Helmut

Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:

> Stefan Claas <sac@300baud.de>:
> >Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:
> >> Stefan Claas <sac@300baud.de>:
>
> [.The ability to check that an encrypted message has been signed.] 
>
>
> >It would allow Alice (in her organization), or others, to do a
> >pre-check, with procmail etc., to set-up an auto-responder,
> >informing Bob that he did not signed his message and that his
> >message will be discarded.
>
> >>> And is this optional in GnuPG, in case it is already
> >>> implemented?
> >>
> >> As far as I know the order “first sign, then encrypt” is
> >> mandatory, so there is no way for GnuPG to deviate from it. 
> >>
> >> And this is a good thing, as it thwarts Eve eavesdropping on the
> >> originator's identity (i.?e. Bob) of a message sent to Alice. 
> >
> >It should be not a mandatory feature and it should only append
> >secured bytes, which are stating that Bob's message contains a
> >signature (yes|no bytes), without revealing his identity.
>
> What do you mean by the term “secured bytes”?

Well, there should be a way that appended bytes to a signed and
encrypted message could not be exchanged by third parties, to
allow a pre-check (procmail etc.), like I explained, without the
need that Alice has to decrypt the message manually and then check
if the message was signed.

While not being off-topic, how does for example Zero Knowledge Proof
Encryption does a check that the identity of a user is proven, while
the user does not have to reveal his actual age? He only proves with
that, that he his over 18 years of age.

While I am no programmer or cryptographer, I think if this is possible
than something that I asked for should be somehow possible too, or not?

Regards
Stefan

--
NaClbox: cc5c5f846c661343745772156a7751a5eb34d3e83d84b7d6884e507e105fd675
The computer helps us to solve problems, we did not have without him.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users