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

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

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

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 at

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,

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

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

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]

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

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

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