Re: More info in my AES128-CBC question

2007-04-27 Thread Alexander Klimov
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 after it, effectively;
 basically an IV is just C_0 for some stream.

The order of events is important. Consider a chosen plaintext
attack: a secret message was sent other a CBC-encrypted channel.
For example, it was a single block with padded yes or no and
the encryption is x0||x1, where x0 is a random IV and

  x1 = E(x0 xor yes),

the attacker can now submit their message to find the secret
one. If the attacker knows that x1 is going to be used as the
next IV, they can try to submit

  m = x0 xor yes xor x1

it will be encrypted as

  x2 = E(m xor x1) = E(x0 xor yes) = x1

so if x2 = x1 the attacker knows that yes was sent, otherwise
it was no.

If the new IV is randomly selected *after* the attacker has made
his choice the attack is impossible.

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More info in my AES128-CBC question

2007-04-27 Thread Nicolas Williams
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 block of ciphertext must also be sent to the peer.
 
 Not true.  Since we are comparing confounders to IVs, let's make identical
 assumptions; that the value is somehow agreed upon in advance.

The term confounder as used in Kerberos V is as I described.

  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 after it, effectively; basically an IV is just
 C_0 for some stream.

The last ciphertext block of one message is the IV for the next.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: open source disk crypto update

2007-04-27 Thread Simon Josefsson
Alexander Klimov [EMAIL PROTECTED] writes:

 Are you afraid of attackers secretly changing your software (to
 monitor you?) while your computer is off?

I believe this is a not completely unreasonable threat.  Modifying files
on the /boot partition to install a keylogger is not rocket science, and
(more importantly) can be done remotely, if you gain unauthorized access
to the machine.

If you boot from a trusted USB stick instead, and check the integrity of
the hard disk, the attacker needs to modify BIOS in order to install the
keylogger.  This may be sufficient difficult to do on a large scale
(there are many different ways to update BIOS software), so that the
attacker goes away to try some other weakness instead.

There is one aspect that I don't recall seeing in this thread: if you
use a laptop, and suspend it to disk, there is no encryption or
authentication of the data as far as I know.  (I believe swsusp
optionally can use SHA-1 or MD5 to verify integrity, but the hash is not
keyed.)  For example, your SSH or PGP RSA key may be copied to disk
without warning.  In addition, someone could modify the on-disk RAM
image to add a new root process when you restart the machine.

 If so, are you sure that there is no hardware keylogger in your
 keyboard and there is no camera inside a ceiling mounted smoke
 detector [1]?

Installing or enabling such features remotely is difficult, and
(importantly) cannot be done in the same way for all hardware.

/Simon

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Training your customers to be phishing victims, part umpteen.

2007-04-27 Thread Russ Nelson
Perry E. Metzger writes:
  The following is a real email, with minor details removed, in which
  J.P. Morgan Chase works hard to train its customers to become phishing
  victims.

And no DomainKeys cryptographic signature??  You're right - for shame!

-- 
--my blog is athttp://blog.russnelson.com   | You can do any damn thing
Crynwr sells support for free software  | PGPok | you want, as long as you
521 Pleasant Valley Rd. | +1 315-323-1241   | don't expect somebody else
Potsdam, NY 13676-3213  | Sheepdog  | to pick up the pieces.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Public key encrypt-then-sign or sign-then-encrypt?

2007-04-27 Thread Jeff . Hodges
There's also this paper..

Donald T. Davis, Defective Sign  Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, 
and XML., Proc. Usenix Tech. Conf. 2001 (Boston, Mass., June 25-30, 2001), 
pp. 65-78
http://world.std.com/~dtd/#sign_encrypt


..which addresses some of the questions, in a certain context, that Travis 
raised.


=JeffH


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: crypto component services - is there a market?

2007-04-27 Thread Stefan Kelm
Ian,

 Stefan is talking about Germany which has issued a plethora of
 recommendations, laws and what-not to cause ecommerce to leap into
 life.  Unfortunately, they did not understand, and electronic documents
 are much much harder to do in these environments, with no general added
 benefit and lots of downside.

Moreoever, some other countries blindly copied what the Germans did,
thinking that would be a good idea. The Austrians made some of the
exact same mistakes but seem to have learned faster than the Germans.

 The German rules have defied, there is no easy way to get into them ...
 at least, the Germans have sworn to me it is impossible...

Sad but true. This year'll mark the 10th anniversary of our signature
law. I reckon nobody will be celebrating that event...

 Qualified certificates are defined in the European Digital Signature
 Directive, which is an over-arching design for all the EU countries to
 pass into local law.

Yes, this has already happened and has even been evaluated by the
European Commission in 2003:
http://www.law.kuleuven.ac.be/icri/itl/elsig.php
http://www.secorvo.de/publikationen/electronic-sig-report.pdf

 It's only under the German code where they try and define it all, as far
 as I can see.  We are talking about a country where they tried to tax
 servers so as to pay for their TV...

Yeah, bloody Germans...  :-)

Cheers,

Stefan.


T.I.S.P.  -  Lassen Sie Ihre Qualifikation zertifizieren
vom 25.-30.06.2007 - http://www.secorvo.de/college/tisp/

Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Ettlinger Strasse 12-14, D-76137 Karlsruhe
Tel. +49 721 255171-304, Fax +49 721 255171-100
[EMAIL PROTECTED], http://www.secorvo.de/
PGP: 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

Mannheim HRB 108319, Geschaeftsfuehrer: Dirk Fox

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: crypto component services - is there a market?

2007-04-27 Thread Stefan Kelm
Nicholas,

 Stefan is talking about Germany 
 
 I realise that, but he said Europe, so I felt a UK counter-example was
 in order!

Point taken.  :)  However, there are other countries w/ similar rules.

 Qualified certificates are defined in the European Digital Signature
 Directive, which is an over-arching design for all the EU countries to
 pass into local law.

 Basically, they are personal smart cards operating under (harsh and
 uneconomic) secure conditions, because they really tried hard to make
 the results like human signatures.
 
 As I read it, the cards are the so-called secure signature creation
 devices, while the certificates are, well, just certificates.

Yep.

 I received and continue to receive electronic invoices from time to
 time, but none appear to be digitally signed, nor have I seen evidence
 of time-stamping in operation.

 UK probably ignored the whole thing.  More power to them. Under Anglo
 common law this is not an issue, as long as there is a lightweight
 digsig model shall not be denied legal standing solely on the basis
 that it is a digsig.
 
 Well, we implemented the Directive, which didn't require much change to
 the law, as you note.  But there has been little take-up for a solution
 in search of a problem.

There's another EU Diretive on simplifying, modernising and harmonising
the conditions laid down for invoicing in respect of value added tax.

   Invoices sent by electronic means shall be accepted
   by Member States provided that the authenticity of
   the origin and integrity of the contents are guaranteed:

   - by means of an advanced electronic signature
 within the meaning of Article 2(2) of Directive
 1999/93/EC of the European Parliament and of
 the Council of 13 December 1999 on a
 Community framework for electronic signatures;
 Member States may however ask for
 the advanced electronic signature to be based on
 a qualified certificate and created by a secure-signature-
 creation device, within the meaning of
 Article 2(6) and (10) of the aforementioned
 Directive;

That's the one I was talking about earlier. eInvoicing
slowly seems to take off in a few european countries.
I have no idea as to how this Directive has been
transposed into UK law, though.

Cheers,

Stefan.


T.I.S.P.  -  Lassen Sie Ihre Qualifikation zertifizieren
vom 25.-30.06.2007 - http://www.secorvo.de/college/tisp/

Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Ettlinger Strasse 12-14, D-76137 Karlsruhe
Tel. +49 721 255171-304, Fax +49 721 255171-100
[EMAIL PROTECTED], http://www.secorvo.de/
PGP: 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

Mannheim HRB 108319, Geschaeftsfuehrer: Dirk Fox

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Public key encrypt-then-sign or sign-then-encrypt?

2007-04-27 Thread Joe Cooley

A discussion (with references) of sign-then-encrypt wrt to public key
crypto can be found here.  In answer to sign or encrypt first
(assuming RSA), sign first, then encrypt--see section 1.2.

http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

Joe

On 4/25/07, Travis H. [EMAIL PROTECTED] wrote:

On Wed, Apr 25, 2007 at 03:24:06PM -0300, Mads Rasmussen wrote:
 Hugo Krawczyk [1] showed in the symmetric key setting that the
 encrypt-then-authenticate was the way to go about securing the integrity
 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.

--
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 [EMAIL PROTECTED]




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Randomness

2007-04-27 Thread Eastlake III Donald-LDE008
See http://xkcd.com/c221.html.

Donald

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More info in my AES128-CBC question

2007-04-27 Thread Leichter, Jerry
|  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 successful.  For this attack
|(commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to
|work, the attacker would need to know the Initialization Vector (IV)
|of the next block that is going to be encrypted.  In CBC mode that is
|the output of the encryption of the previous block.  If the attacker
|does not have any way to see the packet yet (i.e., it is in the
|internal buffers of the SSH implementation or even in the kernel),
|then this attack will not work.  If the last packet has been sent out
|to the network (i.e., the attacker has access to it), then he can use
|the attack.
| 
This still doesn't describe how the attack works.  It's very special-
ized: A chosen-plaintext attack that can confirm the decryption of a a
previously intercepted block (but cannot directly reveal it).

In the following, all encryptions are with respect to a fixed (but
unknown to the attacker) key.  Earlier, the attacker intercepted I and
E(I xor X), where X is some unknown data and I is the IV that was used
in encrypting it.  (That is, I is simply the previous encrypted block.)
The attacker has a guess Y as to what X is and wishes to confirm it.  He
also knows J, the next IV to be used; and can choose the next block to
be encrypted.  He chooses Y xor J xor I.  The CBC encryptor sends:

E(J xor Y xor J xor I) == E(I xor Y)

The attacker examines this block as it's transmitted, and compares it
to E(I xor X).  If they are the same, then X == Y.

Notice that this requires true *chosen* plaintext - known plaintext does
you no good at all.  And you have to be able to choose any plaintext -
what you're stuffing in there will look essentially random, because J
and for that matter I are essentially random.  Since all you'll see is
the encrypted result, you have to be able to choose *all* the bits.

Since SSH sends the password at a guessable point in the stream, the
block containing is locatable and it has high value.  If an attacker
grabs it, he could try password guessing attacks through the
subsequent encryption.

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 to cause information to leak.  Note that for this to be
an interesting attack, we have to posit that the plugin can be caused
to run within a browser during a secure session containing valuable
data, but also that the browser is sufficiently secure that the plugin
can't get at the data directly.  (The Java security model does try to
enforce this kind of separation.)

It's really tough to formalize exactly what is going on here, since
there's this whole funny notion of knowing the next IV to be used in
time to choose the next plaintext.  I guess we assume that the
implementation doesn't allow you to change the contents of a message
once you've passed it down to the crypto layer; otherwise, you could
in principle apply this attack between every pair of CBC-encrypted
blocks.  Unrealistic?  There were attacks against OS 360 in which
you passed in a channel program, then modified it while it was being
executed, sometimes from the CPU, sometimes by causing one element
in the channel program to do I/O that overwrote another element before
the channel got there.  So I would certainly not dismiss this as
completely impossible.

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
doesn't know the key, even knowing the IV used with this fixed message
doesn't tell him what IV will be used for the block after, the earliest
one he could specify.  The same IV will likely never by seen again
during the lifetime of the key, so knowing the output of encrypting the
fixed message with that IV is also useless.  Adding some random data to
the ignored block can be done but has no effect on the security.  Note
that the wire overhead is the same here as with sending a new IV: One
block.  You can avoid that by making the IV's computable by a party that
knows the key:  E.g., use E(n) as the IV for the n'th block.  Or even
simpler, take the saved IV and encrypt it an extra time before using it.
The advantage of the RFC's approach is that it works with older peers:
They messages they send remain vulnerable, but the messages a new
implementation sends them are not, but are completely understandable.
If you need to upgrade an already fielded protocol, this is the best 

Re: More info in my AES128-CBC question

2007-04-27 Thread Nicolas Williams
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 messages carry [random] data.

Effectively what the RFC is calling for is a confounder.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More info in my AES128-CBC question

2007-04-27 Thread Leichter, Jerry
|  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 RFC is calling for is a confounder.
No, not really, for any reasonable interpretation I can make of
that term.  You can send a message that consists of enough 0 bytes
to be sure that the entire first block is fixed, and you've gotten
all the security you can get against the attack in question.  (If
you're using SSH_MSG_IGNORE to protect against traffic analysis, you
might want to do something different - but that's a completely
distinct attack and the security considerations are entirely
different.)

-- Jerry
 
| Nico
| -- 
| 
| 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]