[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
(EDT)
Message-Id: <199610022051.QAA07632@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't
use HELO protocol
To: Rob Adams <adams@cisco.com>
Cc: ipsec@TIS.COM
Subject: Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion
Security Transform.
In-Reply-To: Your message of "Wed, 02 Oct 1996 13:43:49."
<19961002134349adams@161.44.128.127>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 02 Oct 1996 16:50:58 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Rob Adams writes:
> Your point about the replay window was lost on me. I never suggested an
> infinite replay window, only that I saw no advantage in supporting the
> negotiation of replay windows. If my implementation has a 32 bit replay
> window and the peer I'm communicating with has no window and requires
> packets in order, what do I care? Why should that be negotiated?
So that both sides will know what is in use?
> I had one person say that there was added vulnerability in using a
> window versus requiring packets in order and that negotiating would
> allow sites to not allow this vulnerability. I don't see the
> vulnerability.
Denial of service attacks.
> If my implementation is guaranteed to drop packets it has seen
> before, I can't fathom the vulnerability.
You have to save information on every packet you've already seen for
which the bottom of the window hasn't been passed. This leaves you
open to having attackers force you to consume memory and CPU if you
have a large window.
Perry
Date: Wed, 02 Oct 96 17:05:26 EST
From: "Whelan, Bill" <bwhelan@nei.com>
Message-Id: <9609038443.AA844353349@netx.nei.com>
Cc: ipsec@TIS.COM
Subject: CBC vs. ECB
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Without an IV, what you are running is the ECB mode of these
algorithms which is highly insecure. I do not think that should be
encouraged.
So CBC is more secure than ECB! I've been accepting statements such
as this as gospel for a while, but now I'm not so sure. Please excuse
my ignorance, but...
If I've got a sequence of ciphertext (C0, C1, C2,...) and an IV, then
P0 = IV ^ ECBDec(C0) (IV xor ECB Decryption of C0)
P1 = C0 ^ ECBDec(C1)
P2 = C1 ^ ECBDec(C2)
...
So, if you've got the IV and the ciphertext and you can figure out how
to do ECB decryption, it's a small step to do CBC decryption.
So why is CBC more secure than ECB?
Am I missing something?
Bill
Message-Id: <199609271404.KAA08489@jekyll.piermont.com>
To: Rob Adams <adams@cisco.com>
Cc: ipsec@TIS.COM
Subject: Re: Comments on ESP and AH IPSEC drafts.
In-Reply-To: Your message of "Thu, 26 Sep 1996 14:44:01."
<19960926144401adams@161.44.128.127>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 27 Sep 1996 10:04:59 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Rob Adams writes:
> I think including an IV in the packet should constitute a separate
> transform with a unique IANA designation. Optional fields slow
> performance and in this case, the keying material and caching information
> are different even though most of the actual operation is substantially
> the same.
Without an IV, what you are running is the ECB mode of these
algorithms which is highly insecure. I do not think that should be
encouraged.
> I don't see the purpose of negotiated window sizes unless there is some
> vulnerability in accepting out of order packets.
Serious denial of service attacks result if you are forced to keep an
infinite window.
Perry
To: "Whelan, Bill" <bwhelan@nei.com>
Cc: ipsec@TIS.COM
Subject: Re: CBC vs. ECB
Date: Thu, 03 Oct 1996 09:59:21 -0400
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610031149.aa09859@neptune.TIS.COM>
Without an IV, what you are running is the ECB mode of these
algorithms which is highly insecure. I do not think that should be
encouraged.
So CBC is more secure than ECB! I've been accepting statements such
as this as gospel for a while, but now I'm not so sure. Please excuse
my ignorance, but...
If I've got a sequence of ciphertext (C0, C1, C2,...) and an IV, then
P0 = IV ^ ECBDec(C0) (IV xor ECB Decryption of C0)
P1 = C0 ^ ECBDec(C1)
P2 = C1 ^ ECBDec(C2)
...
So, if you've got the IV and the ciphertext and you can figure out how
to do ECB decryption, it's a small step to do CBC decryption.
So why is CBC more secure than ECB?
Am I missing something?
CBC is more secure than ECB for a lot of reasons, most of which are
explained in any decent cryptography text. To name a few:
1) Common plaintext blocks will (in general) be mapped to different
ciphertext blocks.
2) If the IV is different, even the first block will be encrypted
differently. This in turn will cause all subsequent blocks to
be encrypted differently, even if the packets are identical.
Note that a constant IV may suffice (for this property) if the
first block of the plaintext is always different (i.e., if it
contains a sequence number).
3) Splicing messages is more difficult, as a CBC splice results
in a corrupted plaintext block.
But you're certainly right that an enemy who can already solve the
ECB encryption won't be hindered at all by use of CBC mode.
To: perry@piermont.com
Cc: Rob Adams <adams@cisco.com>, ipsec@TIS.COM
Subject: Re: Comments on ESP and AH IPSEC drafts.
Date: Thu, 03 Oct 1996 10:27:30 -0400
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610031153.aa10042@neptune.TIS.COM>
Rob Adams writes:
> I think including an IV in the packet should constitute a separate
> transform with a unique IANA designation. Optional fields slow
> performance and in this case, the keying material and caching inform
ation
> are different even though most of the actual operation is substantia
lly
> the same.
Without an IV, what you are running is the ECB mode of these
algorithms which is highly insecure. I do not think that should be
encouraged.
If the first block is guaranteed to be different -- and it is here,
since there's a sequence number -- you don't need an IV to protect the
first block. (Well, there are probable plaintext attacks, but that's
a far cry from ECB mode.)
> I don't see the purpose of negotiated window sizes unless there is s
ome
> vulnerability in accepting out of order packets.
Serious denial of service attacks result if you are forced to keep an
infinite window.
I don't see the point to negotiating the window size. It seems to me
to be a local implementation issue. Senders cannot, in general, control
the delivery patterns; that's more an artifact of the current state of
the network. Given that, what can the sender do with knowledge of the
receiver's window size?
An attacker can replay old packets which will be dropped. He or she
can also send random packets, but those will have a bad authentication
check, and so will not (or at least should not) affect the last packet
counter. I do not see any denial of service attacks here. (An attacker
who can intercept and reorder all packets to a destination has accomplished
nothing; the most that can be done by delaying a packet is to cause it
to be dropped.)