Comment # 7
on bug 9499
from Hauke Mehrtens
(In reply to comment #6)
> (In reply to comment #2)
> > Created attachment 12210 [details]
> > ssl: use hex numbers of TLS Cipher suites
> >
> > The TLS Cipher Suites are referenced in Hex code everywhere, use that
> > also in the decode table.
>
> Good idea, I have updated my script to generate hexadecimal values for the
> cipher suite ID[1]. This should give more consistent (capitalization)
> numbers. Also, you updated the comments for three PSK suites here (139, 140,
> 141).
>
> [1]:
> https://git.lekensteyn.nl/peter/wireshark-notes/tree/generate-wireshark-cs
Nice script I will have a look at it. I did the changes manually, is there some
documentation I am missing which references this script?
> (In reply to comment #3)
> > Created attachment 12211 [details]
> > SSL: add decrypt support for CCM and CCM_8 Ciphers
> >
> > This adds decrypt support for CCM and CCM_8 Ciphers like the ones
> > specified in rfc6655.
>
> There is no "GenericCCMCipher" in the TLS RFCs, RFC 6655 names
> GenericAEADCipher too.
>
> Copy pasta error: the comment preceding the auth tag handling before
> SSL_CIPHER_MODE_CCM_8 is wrong, RFC 6655, sect. 6.1 "AES-128-CCM with an
> 8-Octet Integrity Check Value (ICV)" mentions a tag size of 8 octets.
I will change this comment.
> Since the nonce handling code is mostly shared with other GCM, I suggest to
> merge them (SSL_EX_NONCE_LEN_GCM is copied without changing as well).
> (According to RFC 6655, the nonce is exactly that of GCM). You seem to have
> implemented RFC 3610 which is not specific to TLS. Do you have an AES-CCM
> test cipher?
Yes I looked into how the GCM cipher is implemented and the encryption part is
very similar to the CCM encryption part, both are using AES CTR.
I will try to extend the GCM block so that it handles CCM and GCM.
Yes the nonce used for CCM is the same, but this nonce is used as input for RFC
3610, which specifies CCM. RFC 3610 does some conversions to it to convert it
to the nonce used in AES CTR. So the nonce used as input for RFC 3610, is not
the same as the nonce used for AES CTR.
The implementation I created the trace with was tested against some other DTLS
implementations supporting CCM_8, so I assume the trace is a valid TLS trace.
The trace was generated with TinyDTLS:
http://sourceforge.net/projects/tinydtls/
> I am fine with the "dtls: set ssl_set_server()" (note: `git am` does not
> take the fuzz, I manually applied it).
>
> The patch "dtls: add psk decrypt support" is mostly copying from
> packet-ssl.c and re-indenting previous code, it would be nicier if you
> refactored the code from packet-ssl.c to packet-ssl-utils.c to reduce code
> duplication.
Ok, I will try that. So then this code will be moved into packet-ssl-utils.c
and SSL and DTLSwill use it.
> Thanks for your efforts!
You are receiving this mail because:
- You are watching all bug changes.
