[86481] in cryptography@c2.net mail archive
Re: Public key encrypt-then-sign or sign-then-encrypt?
daemon@ATHENA.MIT.EDU (Travis H.)
Thu Apr 26 08:44:16 2007
Date: Wed, 25 Apr 2007 21:15:33 -0500
From: "Travis H." <travis+ml-cryptography@subspacefield.org>
To: cryptography@metzdowd.com
Mail-Followup-To: cryptography@metzdowd.com
In-Reply-To: <462F9CC6.8060904@lsitec.org.br>
--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 25, 2007 at 03:24:06PM -0300, Mads Rasmussen wrote:
> Hugo Krawczyk [1] showed in the symmetric key setting that the=20
> encrypt-then-authenticate was the way to go about securing the integrity=
=20
> of an encrypted message.
Haven't read this yet, but will... and may have comments.
Without reading it, I do have some comments.
At least one authentication protocol failed because it was possible
to strip off a signature then re-use an encrypted blob (e.g. with
one's own signature on it). So they are malleable.
In _many_ poorly-designed systems it becomes possible to use a system
as a signature oracle to sign arbitrary things. Smartcards with a
hostile PC are just one of these cases.
One must be very careful what a signature is supposed to attest.
Also there's a semantic issue; am I attesting to the plaintext,
or the ciphertext? It's possible the difference could be important.
Do we sign letters, or sign envelopes? If I sign an envelope
containing a letter, I deprive you of much of the evidentiary
value that a signed letter would carry; you cannot easily prove
to someone what I signed without revealing your decryption key(s).
With encrypt-then-authenticate, one can check authentication, and
if it fails, avoid decryption - while in theory this could avoid
DoS, in practice the authentication is more costly than decryption.
In my reading on information-theoretic security, I found that if one
does encryption around the authentication, then one can prevent the
opponent from learning anything about the message. Specifically, if
Enc(x) is a one-time-pad, then one can use very efficient and
ostensibly unsecure hash functions such as a selection from the
universal hash family ax + b (mod n) for one's integrity and
authentication, and (for certain restrictions on a, b, and n, and
under the assumption of secrecy of a and b) one can have
_information-theoretic security for authentication and integrity_.
That is, no matter how many messages sent, no matter how many CPU
cycles the opponent has available, the opponent can learn nothing new.
I've been discussing and developing a prototype system that aims to
provide information-theoretic security (and at worst, conventional
computational security) for low-bandwidth purposes (i.e. email or IM),
and I will post details here when I have them in a relatively stable
form, for those who are interested.
--=20
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -><- <URL:http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email john@subspacefield.org.
--17pEHd4RhPHOinZp
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (OpenBSD)
iQIVAwUBRjALRWQVZZEDJt9HAQJTYA//bE02uyKddIiOrJ9eYgZuVgH6KOYlez0A
GER6rb1oxmlswrll0VWcWLQj/POBs1o3cV0v6JEkG8Ayt00NkTddUIw1wz+zENje
e5PWsuU/szIRKrBRSAumyNzHNGTR7a2PNbU75W71B84/oebg97JR1KtwdWmKK5t4
MSYT1Vgi8f7fhLUjYwRlYMx96h64BQ5FJlZGVKxjEjqNyMG+R71hOhNEHzpgKE4c
aWyO+t69b/+i8X8ges3XG3SGHbHYnHlGIDTATrKcN/FwS2tB132e06PJJJMYZox9
k+gmxW6/5Z+jG5Bq192D9bKhzAa4dWaUT6R9zg9nev8nhcvxAEBScY63YqDRQaWn
lrL1tcMrD9R70bahm+y1UuVWVNXFHSozPRSsXv7IBg0qXpvYreYrqJSZUzd1Tx71
HCaA5txghkrpixKVy9GkV8mFeWXgP8YwItsdB1W7Tny9kpDX/mpoSuvpYs7snUFJ
Uyo57NVEwXpddJmhAwZ6ONRZ0uf6D1YB6HkMeV53WOYtPZ5Aj4WYy/0Ot6wGs8S9
a0wB4erwUUGeIhq3pOjYiUkfXku/Toi+P5h9JTqUFrz5ny4Wvv0GnHYtlQMyIhwA
UsMuEq00XJxuJd02Ko1FtaduhSUOW4+FRh+tjJ/muLx9dc2dNZlLYcKeKfxci/Zn
doq99j0Mvtk=
=BCR7
-----END PGP SIGNATURE-----
--17pEHd4RhPHOinZp--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
