On Fri, 15 Feb 2013, Joel Dice wrote:
On Fri, 15 Feb 2013, Joel Dice wrote:
On Thu, 14 Feb 2013, Dr. Stephen Henson wrote:
On Thu, Feb 14, 2013, Joel Dice wrote:
Although OpenSSL seems to allow CBC-based suites with DTLS, from
what I've read a block in a CBC stream can't be properly decoded
without the prior block being available
(http://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-block_chaining_.28CBC.29).
With that in mind, is it still reasonable to expect that a CBC-based
suite would work with DTLS and an unreliable transport?
The format for CBC ciphers in DTLS (and TLS v1.1 and later) includes an
explicit IV at the start of the record.
Thanks, Steve. I went ahead and wrote a simple test for this, and I can
confirm that TLS_DH_anon_WITH_AES_256_CBC_SHA does work, at least. Which
means the data corruption I reported must be due a mistake somewhere in my
application code.
Oops, wrote too soon.
I've updated the test to allow the user to specify how many packets to send
and which ones to drop. It seems that if I drop any but the first packet
sent after the handshake completes, there's no problem. However, if I do
drop the first packet, I get garbage. Can you explain why that is?
I've put an updated test here:
https://github.com/dicej/dtls-test/blob/master/dtls-test.cpp
For the record, the latest OpenSSL from git://git.openssl.org/openssl.git
works fine, whereas OpenSSL 1.0.1c currently part of Debian Wheezy does
not work. I haven't taken the time to determine exactly what the
difference is, but I assume it was a bugfix that was applied sometime
since 1.0.1c.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
