| Just being able to generate traffic over the link isn't enough to
| carry out this attack.
|
| Well, it depends on if you key per-flow or just once for the link. If
| the latter, and you have the ability to create traffic over the link,
| and there's a 1-for-1 correspondence between
Earlier someone asked about comparisons between full-width CFB and CBC.
They are very similar in certain ways. For example, the sequence of
operations for both are the same: xor the next block of plaintext; encrypt
the result; xor the next block of plaintext; encrypt the result; and so
on. The
| | Frankly, for SSH this isn't a very plausible attack, since
| | it's not clear how you could force chosen plaintext into an
| | SSH session between messages. A later paper suggested that
| | SSL is more vulnerable: A browser plugin can insert data into
| | an SSL protected
On Wed, May 09, 2007 at 06:11:03PM -0400, Leichter, Jerry wrote:
Just being able to generate traffic over the link isn't enough to
carry out this attack.
Well, it depends on if you key per-flow or just once for the link. If
the latter, and you have the ability to create traffic over the link,
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote:
| Frankly, for SSH this isn't a very plausible attack, since it's not
| clear how you could force chosen plaintext into an SSH session between
| messages. A later paper suggested that SSL is more vulnerable:
| A browser
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote:
However, cryptographically secure RNG's are typically just as expensive
as doing a block encryption. So why not just encrypt the IV once with
the session key before using it? (This is the equivalent of pre-pending
a block of
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
Frankly, for SSH this isn't a very plausible attack, since it's not
clear how you could force chosen plaintext into an SSH session between
messages. A later paper suggested that SSL is more vulnerable:
A browser plugin can
On Wed, 9 May 2007 15:35:44 -0400
Thor Lancelot Simon [EMAIL PROTECTED] wrote:
On Wed, May 09, 2007 at 01:13:36AM -0500, Travis H. wrote:
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
Frankly, for SSH this isn't a very plausible attack, since it's
not clear how you
| Frankly, for SSH this isn't a very plausible attack, since it's not
| clear how you could force chosen plaintext into an SSH session between
| messages. A later paper suggested that SSL is more vulnerable:
| A browser plugin can insert data into an SSL protected session, so
| might be
| Frankly, for SSH this isn't a very plausible attack, since it's not
| clear how you could force chosen plaintext into an SSH session between
| messages. A later paper suggested that SSL is more vulnerable:
| A browser plugin can insert data into an SSL protected session, so
| might be able
On Wed, 25 Apr 2007, Travis H. wrote:
If the IV chained across continguous messages as in SSHv2
then you have a problem (see above).
I don't fully understand what it means to have IVs chained
across contiguous (?) messages, as in CBC mode each ciphertext
block forms the IV of the block
On Wed, Apr 25, 2007 at 10:58:01PM -0500, Travis H. wrote:
On Wed, Apr 25, 2007 at 05:42:44PM -0500, Nicolas Williams wrote:
A confounder is an extra block of random plaintext that is prepended to
a message prior to encryption with a block cipher in CBC (or CTS) mode;
the resulting extra
| What problem does this (chaining IV from message to message) introduce
| in our case?
|
| See RFC4251:
|
|
|Additionally, another CBC mode attack may be mitigated through the
|insertion of packets containing SSH_MSG_IGNORE. Without this
|technique, a specific attack may be
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
What the RFC seems to be suggesting is that the first block of every
message be SSH_MSG_IGNORE. Since the first block in any message is now
fixed, there's no way for the attacker to choose it. Since the attacker
SSH_MSG_IGNORE
| What the RFC seems to be suggesting is that the first block of every
| message be SSH_MSG_IGNORE. Since the first block in any message is now
| fixed, there's no way for the attacker to choose it. Since the attacker
|
| SSH_MSG_IGNORE messages carry [random] data.
|
| Effectively what the
Aram Perez wrote:
Another response was you haven't heard of anyone breaking SD cards have
you?
I love responses like this. In the physical world there are the
examples of the Kyptonite lock and the Master Combination lock.
By the time you hear about the methodology of the attack someone
On Wed, Apr 25, 2007 at 05:42:44PM -0500, Nicolas Williams wrote:
A confounder is an extra block of random plaintext that is prepended to
a message prior to encryption with a block cipher in CBC (or CTS) mode;
the resulting extra block of ciphertext must also be sent to the peer.
Not true.
On Wed, 25 Apr 2007, Hagai Bar-El wrote:
It seems as Aram uses a different IV for each message encrypted with
CBC. I am not sure I see a requirement for randomness here. As far
as I can tell, this IV can be a simple index number or something as
predictable, as long as it does not repeat within
| Suppose we use AES128-CBC with a fixed IV. It's clear that the only
| vulnerability of concern occurs when a key is reused. OK, where do
|
| No, remember that if the IV is in the clear, an attacker can
| make some controlled bit changes in the first plaintext block.
| (There has been no
Hello Nico,
On 25/04/07 02:18, Nicolas Williams wrote:
If there isn't a good reason for rejecting what I suggest then one might
worry that changing the integrity key on every message (but not the
confidentiality key?) is something that a non-expert might do and that
there may be other
On Wed, Apr 25, 2007 at 05:20:30PM +0300, Hagai Bar-El wrote:
On 25/04/07 02:18, Nicolas Williams wrote:
But be careful. Simply chaining the IV from message to message will
create problems (see SSH).
What problem does this (chaining IV from message to message) introduce
in our case?
See
On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
No, there will be message integrity. For those of you asking, here's
a high level overview of the protocol is as follows:
[...]
3) Data needing confidentiality is encrypted with the SK in the mode
selected in step 1. The
Hi Nico,
On Apr 23, 2007, at 8:11 AM, Nicolas Williams wrote:
On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
No, there will be message integrity. For those of you asking, here's
a high level overview of the protocol is as follows:
[...]
3) Data needing confidentiality is
Some of the messages in this stream have demonstrated why it can be
difficult to get non-crypto people to listen to advice from crypto
experts: Cryptography research is, by its nature, a pretty absolute
thing. We find attacks, we try to eliminate them. There's a strong
tendency to view *any*
info in my AES128-CBC question
Some of the messages in this stream have demonstrated why it can be
difficult to get non-crypto people to listen to advice from crypto
experts: Cryptography research is, by its nature, a pretty absolute
thing. We find attacks, we try to eliminate them
On Mon, Apr 23, 2007 at 11:23:54AM -0700, Aram Perez wrote:
On Apr 23, 2007, at 8:11 AM, Nicolas Williams wrote:
On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
No, there will be message integrity. For those of you asking, here's
a high level overview of the protocol is as follows:
Sorry gang. In my response to David I forgot to provide the link
to a brief history of ulcers from the CDC which is very
interesting from the point of view of how long it takes for
experts to accept evidence.
http://www.cdc.gov/ulcer/history.htm
Have fun.
Allen
Hello David,
On 22/04/07 00:04, David Wagner wrote:
Hagai Bar-El writes:
What Aram wrote is many of the attendees have very little security
experience, not: there are no attendees with security experience.
There are people at the relevant OMA group who know enough about
security, but just
At 2:04 PM -0700 4/21/07, David Wagner wrote:
Hagai Bar-El writes:
What Aram wrote is many of the attendees have very little security
experience, not: there are no attendees with security experience.
There are people at the relevant OMA group who know enough about
security, but just like in the
On 2007-04-21, David Wagner wrote:
If you're sick and you go to a doctor, do you tell the doctor you'd
better come up with some very clear arguments if you want me to follow
your advice? Do you tell your doctor you'd better build a strong case
before I will listen to you? I would hope not.
Hello all,
On 20/04/07 08:32, Aram Perez wrote:
The proposal for using AES128-CBC with a fixed IV of all zeros is for
a protocol between two entities that will be exchanging messages.
This is being done in a standards body (OMA) and many of the
attendees have very little security experience.
On Thu, Apr 19, 2007 at 10:32:58PM -0700, Aram Perez wrote:
Hi Folks,
First, thanks for all your answers.
The proposal for using AES128-CBC with a fixed IV of all zeros is for a
protocol between two entities that will be exchanging messages. This is being
done in a standards body (OMA)
On Thu, 19 Apr 2007 22:32:58 -0700
Aram Perez [EMAIL PROTECTED] wrote:
Hi Folks,
First, thanks for all your answers.
The proposal for using AES128-CBC with a fixed IV of all zeros is for
a protocol between two entities that will be exchanging messages.
This is being done in a standards
Aram Perez wrote:
The proposal for using AES128-CBC with a fixed IV of all zeros is for
a protocol between two entities that will be exchanging messages.
This is being done in a standards body (OMA) and many of the
attendees have very little security experience.
We don't let a bunch of
34 matches
Mail list logo
