[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A hole in esp-stream-01
Angelos D. Keromytis wrote:
> >a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the
> > last 4 bytes before encryption. This just hopes that something different
> > will do the error detection, including the last four bytes...
> At least one of the attacks will still hold (toggling the lower order
> bit of the TCP/UDP port in the header and the checksum).
Right. But only if nobody checks the checksum over the whole packet, which I
just introduced. And yes, I hate myself for doing it, I would much more
prefer to have a formal MAC which ist fast enough to calculate such that
esp-stream would fit into the cum MAC philosophy of IPSEC.
>
> >b) Add preceeding plaintext byte and cypertext byte to current byte before
> > encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain-
> > text unless you know the plaintext anyway.
>
> But the problem is that the attacker already knows the plaintext of
> the header...unless i'm missing something ?
Yes, I believe he now needs to know the *whole* plaintext. Otherwise all
the rest after the header he changed will be garbled. Or do I have a
gross mistake in my thinking here?
Germano
To: Germano Caronni <caronni@tik.ee.ethz.ch>
cc: ipsec@TIS.COM
Subject: Re: A hole in esp-stream-01
In-reply-to: Your message of "Thu, 24 Oct 1996 01:03:59 +0200."
<199610232303.BAA07552@kom30.ethz.ch>
Date: Wed, 23 Oct 1996 21:34:28 -0400
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610240721.aa28311@neptune.TIS.COM>
In message <199610232303.BAA07552@kom30.ethz.ch>, Germano Caronni writes:
>
>a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the
> last 4 bytes before encryption. This just hopes that something different
> will do the error detection, including the last four bytes...
At least one of the attacks will still hold (toggling the lower order
bit of the TCP/UDP port in the header and the checksum).
>b) Add preceeding plaintext byte and cypertext byte to current byte before
> encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain-
> text unless you know the plaintext anyway.
But the problem is that the attacker already knows the plaintext of
the header...unless i'm missing something ?
-Angelos
To: Germano Caronni <caronni@tik.ee.ethz.ch>
cc: ipsec@TIS.COM
Subject: Re: A hole in esp-stream-01
In-reply-to: Your message of "Thu, 24 Oct 1996 03:41:33 +0200."
<199610240141.DAA09828@kom30.ethz.ch>
Date: Wed, 23 Oct 1996 21:49:20 -0400
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610240722.aa28351@neptune.TIS.COM>
-----BEGIN PGP SIGNED MESSAGE-----
In message <199610240141.DAA09828@kom30.ethz.ch>, Germano Caronni writes:
>Right. But only if nobody checks the checksum over the whole packet, which I
>just introduced. And yes, I hate myself for doing it, I would much more
>prefer to have a formal MAC which ist fast enough to calculate such that
>esp-stream would fit into the cum MAC philosophy of IPSEC.
Assuming you're using the standard CRC algorithm, i don't see why this
would make any difference. That particular change is still possible.
>Yes, I believe he now needs to know the *whole* plaintext. Otherwise all
>the rest after the header he changed will be garbled. Or do I have a
>gross mistake in my thinking here?
So, he'll get P(i) + K(i-1)...he can recursively break this, starting
from the first ciphertext unit (bit or byte, depending on the
algorithm) and working towards the end of the packet.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMm7LH70pBjh2h1kFAQFbnAP+Pfg/G8ot4Ufs/wQsyVMAE/limc4aW1wy
XE+Jy+GJrVuDRLRzkq1cd3fBW90v4t1N59D/JJ1vjMLTsaA7d1ombRQnNKQmwjvF
DXif0TLJRRZfFi1SCwrJOgnyqJyVgaEb3wHxX3C/uB4UHem3zDTtjVLDNpakY2Kt
C1pfs0FKj80=
=vkoW
-----END PGP SIGNATURE-----
Message-Id: <199610232314.QAA07259@toad.com>
To: Karl Fox <karl@ascend.com>
cc: perry@piermont.com, ipsec@TIS.COM, gnu@toad.com
Subject: Re: NSA's opinion on what it's legal to do
In-reply-to: <199610222108.RAA09089@carp.morningstar.com>
Date: Wed, 23 Oct 1996 16:14:38 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> As to exporting development, the NSA told us that not only couldn't we
> export source with any kind of hook for encryption, we couldn't even
> hire someone outside of the country to add encryption to an existing
> product without running afoul of the U.S. laws. Of course, I'm not a
> lawyer, and am not suggesting that their claims were necessarily valid.
I am stating, not suggesting, that their claims are deliberately invalid.
The NSA regularly lies to people who ask it for advice on export control.
They have no reason not to; accomplishing their goal by any legal means
is fine by them. Lying by government employees is legal.
NSA recently "distanced itself" from statements made by an NSA
employee to Dan Bernstein, plaintiff in our lawsuit to overturn the
export controls. In an official submission to the court, they cited
court cases supporting the position that the advice that government
employees give to citizens is not binding on the government and does
not define the government's policy.
One thing this employee had said to Dan, when he called up asking for
advice about his crypto export, was that it wasn't legal to publish
export-controlled technical data "with the intent" that it leave the
country, even though published materials are exempt from the export
controls on technical data. NSA now finds that position hard to
defend in court, so they are claiming it never was their "official"
position; their employee must simply have been mistaken. We
tape-recorded their employee making the statement (with permission),
so they couldn't simply deny that he'd said it.
Karl, see what happens when you ask for NSA to restate their opinion,
in writing.
Jerry Rainville of NSA did a tremendous job in this regard a few years
back. He convinced the standards committee for digital cellphones
that if they even discussed encryption in open meetings, they would
violate the ITAR. It was all complete bullshit, of course, but the
committee believed it. The result is that digital cellphones ended up
with no privacy. Just what NSA wanted -- with almost no effort on
their part!
In short, if you rely on NSA for legal advice, you have a malicious
and untrustworthy lawyer. Get your own export lawyer! Since you're
in Ohio, I suggest talking to Peter Junger's lawyers. Peter is a law
prof at Case Western who is also challenging the ITAR in court. Try:
Gino Scarselli, <gscarsel@mail.multiverse.com>, +1 216 291 8601; or
Raymond Vasvari, <freespeech@mail.multiverse.com>, +1 216 522 1925.
John
PS: Whether you can "export source with any kind of hook for
encryption" is at the heart of our court case (see
http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/). Our judge has
already ruled that publication of source code is protected by the
First Amendment. The NSA "hook" doctrine (that they can control the
distribution of source code that doesn't even include crypto, just
hooks where it might be inserted or called) doesn't stand a chance.
They are unlikely to prosecute any such case because of the serious
risk that the law would be invalidated as a result. Fear, uncertainty
and doubt serves their purposes much better than a narrow and
enforceable law would. Fortunately for us, vague and overbroad laws
are unconstitutional.
PPS: Whether you can hire someone outside the country to add
encryption to an existing product is legal in many circumstances (in my
own opinion, though lawyers have provided signed opinions of counsel
concurring with it). I believe that if the work is done by an outside
contractor which is less than 50% owned by your company, it's
definitely legal. There are probably other circumstances in which
it's legal as well. Get a good lawyer to help you figure it out.