[149191] in cryptography@c2.net mail archive
Re: [Cryptography] Does PGP use sign-then-encrypt or
daemon@ATHENA.MIT.EDU (Natanael)
Tue Jan 21 22:03:50 2014
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <FE2F960D-399B-4AA3-8860-5C704E9000D3@lrw.com>
Date: Wed, 22 Jan 2014 00:48:52 +0100
From: Natanael <natanael.l@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: John Kelsey <crypto.jmk@gmail.com>, Tony Arcieri <bascule@gmail.com>,
Cryptography Mailing List <cryptography@metzdowd.com>,
James Cloos <cloos@jhcloos.com>,
Stephan Neuhaus <stephan.neuhaus@tik.ee.ethz.ch>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7504888263832114127==
Content-Type: multipart/alternative; boundary=047d7b86de8296240604f083a678
--047d7b86de8296240604f083a678
Content-Type: text/plain; charset=UTF-8
Den 22 jan 2014 00:32 skrev "Jerry Leichter" <leichter@lrw.com>:
>
> On Jan 21, 2014, at 5:13 PM, Tony Arcieri wrote:
> > I am distinguishing MACs from "signatures", as at least in my
nomenclature digital signature systems are an inherently pubkey system.
> MAC's and digital signature systems are different in a more fundamental
way: With a signature system, Bob can prove to anyone that a message was
signed by Alice without himself being able to produce messages with Alice's
signature on them. With a MAC, Bob has everything needed to produce
messages "MAC'ed" by Alice. But that's fine, because the entire purpose of
a MAC is for Bob to be able to prove *to himself* that Alice produced a
message. There's not much point in him forging a message and then proving
to himself that he forged it!
>
> While this certainly has a flavor similar to the symmetric/asymmetric
system distinction, it's not quite the same thing. DSA does signatures,
but doesn't in and of itself provide an asymmetric encryption system. And
while it's much less convenient and requires a trusted third party, you can
construct a signature-like system using only symmetric primitives: The
trusted third party holds the actual MAC key and will apply it for message
creation only for Alice, but for anyone for message verification. (Alice's
messages to the trusted third party are MAC'ed using a key known only to
the two of them; the TTP can forge messages from Alice, but we assume that
away because it's *trusted*. Similarly the TTP shares a unique key with
anyone who might want a signature verification done. Bob still can't prove
to anyone else that the message was from Alice - but he can point anyone at
the TTP to do it for him.)
You can do signatures directly with symmetric primitives like hashes.
See Lamport signatures (commit to 2*[signature hash bitlength] hashes that
are numbered, reveal one per pair chosen depending on if the corresponding
signature hash bits are 1 or 0) and the Fawkes signature scheme (commit to
a codeword and timestamp it, commit to a message that also reveals the
codeword & timestamp, and optionally commits to a new codeword, then reveal
that message.)
- Sent from my phone
--047d7b86de8296240604f083a678
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Den 22 jan 2014 00:32 skrev "Jerry Leichter" <<=
a href=3D"mailto:leichter@lrw.com">leichter@lrw.com</a>>:<br>
><br>
> On Jan 21, 2014, at 5:13 PM, Tony Arcieri wrote:<br>
> > I am distinguishing MACs from "signatures", as at least=
in my nomenclature digital signature systems are an inherently pubkey syst=
em.<br>
> MAC's and digital signature systems are different in a more fundam=
ental way: =C2=A0With a signature system, Bob can prove to anyone that a me=
ssage was signed by Alice without himself being able to produce messages wi=
th Alice's signature on them. =C2=A0With a MAC, Bob has everything need=
ed to produce messages "MAC'ed" by Alice. =C2=A0But that'=
s fine, because the entire purpose of a MAC is for Bob to be able to prove =
*to himself* that Alice produced a message. =C2=A0There's not much poin=
t in him forging a message and then proving to himself that he forged it!<b=
r>
><br>
> While this certainly has a flavor similar to the symmetric/asymmetric =
system distinction, it's not quite the same thing. =C2=A0DSA does signa=
tures, but doesn't in and of itself provide an asymmetric encryption sy=
stem. =C2=A0And while it's much less convenient and requires a trusted =
third party, you can construct a signature-like system using only symmetric=
primitives: =C2=A0The trusted third party holds the actual MAC key and wil=
l apply it for message creation only for Alice, but for anyone for message =
verification. =C2=A0(Alice's messages to the trusted third party are MA=
C'ed using a key known only to the two of them; the TTP can forge messa=
ges from Alice, but we assume that away because it's *trusted*. =C2=A0S=
imilarly the TTP shares a unique key with anyone who might want a signature=
verification done. =C2=A0Bob still can't prove to anyone else that the=
message was from Alice - but he can point anyone at the TTP to do it for h=
im.)</p>
<p dir=3D"ltr">You can do signatures directly with symmetric primitives lik=
e hashes.</p>
<p dir=3D"ltr">See Lamport signatures (commit to 2*[signature hash bitlengt=
h] hashes that are numbered, reveal one per pair chosen depending on if the=
corresponding signature hash bits are 1 or 0) and the Fawkes signature sch=
eme (commit to a codeword and timestamp it, commit to a message that also r=
eveals the codeword & timestamp, and optionally commits to a new codewo=
rd, then reveal that message.) </p>
<p dir=3D"ltr">- Sent from my phone</p>
--047d7b86de8296240604f083a678--
--===============7504888263832114127==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7504888263832114127==--
