Prev: affine cipher problem
Next: Uncertainty in Privacy and Security @ IPMU 2010
From: Thomas Pornin on 12 Dec 2009 17:51
According to pk <pk(a)pk.invalid>:
> (BTW, is there an official list of those ciphers, along with the numbers
> assigned to them, somewhere?)

RFC 5246 and 4492. See my previous message (at the end).


--Thomas Pornin
From: pk on 12 Dec 2009 17:49
Thomas Pornin wrote:

> According to pk <pk(a)pk.invalid>:
>> (BTW, is there an official list of those ciphers, along with the numbers
>> assigned to them, somewhere?)
>
> RFC 5246 and 4492. See my previous message (at the end).

Ah, I was just about to read them :)

Thanks! (and to all the other respondents as well)
From: Anne & Lynn Wheeler on 13 Dec 2009 12:35

ssl/tsl ... my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

click on "Term (term->RFC#)" in the "RFCs listed by" section, then
click on "TLS" in the "Acronym fastpath" ... brings up:

transport layer security (TLS )
see also encryption , security
5734 5590 5539 5489 5487 5469 5430 5425 5422 5421 5289 5288 5281 5246
5238 5216 5114 5081 5077 5054 5018 4934 4851 4785 4762 4681 4680 4642
4572 4513 4507 4492 4366 4347 4346 4279 4261 4217 4162 4132 3943 3788
3749 3734 3546 3436 3268 3207 2847 2830 2818 2817 2716 2712 2595 2487
2246

....

clicking on RFC number, brings up RFC summary in lower frame ... aka:

5246 PS
The Transport Layer Security (TLS) Protocol Version 1.2, Dierks T.,
Rescorla E., 2008/08/15 (104pp) (.txt=222395) (Obsoletes 3268, 4346,
4366) (Updates 4492) (Refs 793, 1321, 1948, 2104, 2246, 2785, 3268,
3280, 3447, 3526, 3749, 3766, 4086, 4279, 4302, 4303, 4307, 4346, 4366,
4492, 4506, 5081, 5116) (Ref'ed By 5247, 5288, 5289, 5327, 5333, 5352,
5353, 5355, 5369, 5370, 5371, 5387, 5404, 5408, 5409, 5415, 5422, 5425,
5430, 5440, 5458, 5469, 5479, 5482, 5486, 5487, 5489, 5505, 5539, 5550,
5567, 5577, 5582, 5590, 5616, 5626, 5630, 5636, 5677, 5691, 5697, 5734)

....

Clicking on the ".txt=nnn" field retrieves the actual RFC; normally in
the upper frame ... but with browser-tabs ... can bring RFC into other
tabs.

I do updates & updated-by, I've also done some amount of scanning rfc
text to come up with REFs (and therefor REF'ed-By).

i.e.

4492 I
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS), Blake-Wilson S., Bolyard N., Gupta V., Hawk C., Moeller
B., 2006/05/16 (35pp) (.txt=72231) (Updated by 5246) (Refs 2246, 3268,
3279, 3280, 4346, 4366) (Ref'ed By 5114, 5246, 5289, 5430, 5479, 5489)

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: David Thompson on 30 Dec 2009 03:45
On Sat, 12 Dec 2009 22:17:58 +0000, pk <pk(a)pk.invalid> wrote:
<snip>
> However, what I find strange is that OpenSSL does not seem to support any of
> the EC ciphersuites, at least according to the list provided here:
>
> http://www.openssl.org/docs/apps/ciphers.html
>
> Indeed, a quick check with "openssl ciphers -v" on my system shows no EC
> ciphers.
>
At least through 0.9.8g, which is what I have to hand, they are
disabled for TLS by default, and component-matching doesn't get them
for some reason; I think I did track this down at one point, but don't
remember what I found. Instead your cipher selection string aka
cipherlist must specify either the exact suite name(s) individually or
'ECCdraft' to get all of them.

> However, it DOES support the generation and handling of EC keys from the
> command line, which is a bit odd then.
>
And CSRs and certs (req, x509, ca); and I assume CRLs, but didn't
test. And the EVP (or lowlevel) API supports them. It's only the TLS
suites that default off.

> In other words, it would seem that the problem in this case is lack of
> /server/ support for newer ciphers like EC, rather than (as I thought)
> client support.
> If I understand your explanation correctly, a web server linked against
> OpenSSL wouldn't even be able to use a SSL certificate containing an EC
> public key, because that would necessarily involve having support for one of
> the *EC* ciphers!
>
It must enable at least one of the EC suites, which was also offered
by the client. And have the cert and matching key, like all PK. The
algorithms (ECDSA and ECDH aren't exactly 'ciphers') are there.

I assume you mean 'use' to cover only server authentication.
Any openssl program -- client or server -- can use a parent (CA) cert
with an EC(DSA)-key to verify an ECDSA-signed child cert -- which
child cert could be for an entity using RSA or DSA authentication.
I'd be a bit surprised if anyone serious would think it makes sense
for an EC-using (and implicitly EC-requiring) CA to certify
non-EC-using parties, but I tested and technically it works.

First  |  Prev  | 
Pages: 1 2
Prev: affine cipher problem
Next: Uncertainty in Privacy and Security @ IPMU 2010