AES an schannel
Dave Harvey (Medical Connections)
(which uses TLS, but is not http), and generally it works!
However, now I need to add AES support, and I can't find how to
enable/control AES usage in conjunction with schannel. So my questions are:
1) Does the schannel provider (Microsoft Unified Security Protocol Provider)
support AES?
2) If so, how do I enable/control it?
3) Is AES supported only in XP/server 2003, or is there an upgrade for 2000
(and earlier?)
4) Is there a better way to do TLS which I should now be using other than
schannel ?
Dave Harvey
Medical Connections
Vishal Mishra [MS]
--
Vishal Mishra [MSFT]
This posting is provided "AS IS" with no warranties and confers no rights.
Use of any included samples is subject to the terms specified at
http://www.microsoft.com/info/copyright.htm"
-------------------------------------------------------------------------
"Dave Harvey (Medical Connections)" <da...@medicalconnections.co.uk> wrote in
message news:Oz3me77...@tk2msftngp13.phx.gbl...
Dave Harvey (Medical Connections)
> Schannel does not support AES presently.
Thanks for the information....., so this leaves me with 2 options:
1) Wait for AES support to be added to SChannel - you say "presently" in
your response - do you know if this is planned, and when it might happen?
2) Move to managing TLS myself using lower level crptoAPI functions. I have
considered doing this before, in order to get greater control over cipher
suites offered/accepted, but I have never found any example code to get me
started. Do you know if any such samples exist?
Dave Harvey
Pieter Philippaerts
> your response - do you know if this is planned, and when it might happen?
Is there any specific reason why you want AES support? Both RC4 and
TripleDES are considered secure ciphers and both are supported by SCHANNEL.
Also note that SCHANNEL has some AES support already, only not what you're
looking for. On Windows Server 2003, SCHANNEL supports the following two
cipher suites: TLS_NTRU_NSS_WITH_AES_128_CBC_SHA and
TLS_NTRU_NSS_WITH_AES_256_CBC_SHA. Instead of using RSA as the public key
algorithm, they use the new NTRU algorithm. This algorithm has some nice
properties such as very efficient key generation. These two cipher suites
may also be present on Windows XP computers, however I doubt they're
available on older Windows versions.
> 2) Move to managing TLS myself using lower level crptoAPI functions. I
have
> considered doing this before, in order to get greater control over cipher
> suites offered/accepted, but I have never found any example code to get me
> started. Do you know if any such samples exist?
You can control the SCHANNEL cipher suites by editing the registry. There's
a knowledge base article detailing how it's done:
http://support.microsoft.com/default.aspx?scid=kb;en-us;245030
Also, what language are you programming in? If you're using C or C++, you
may want to consider OpenSSL.
Regards,
Pieter Philippaerts
SSL and TLS for .NET: http://www.mentalis.org/go.php?sl
Dave Harvey (Medical Connections)
Thanks for your comments:
> Is there any specific reason why you want AES support? Both RC4 and
> TripleDES are considered secure ciphers and both are supported by
SCHANNEL.
Yes, it is now part of the "DICOM" standard used for medical imaging, and as
VERY large images are regularly sent, using it will benefit from the
improved efficiency compared to DES - also as a toolkit supplier, I really
need to offer my customers every facility in the standard. (see
ftp://medical.nema.org/medical/dicom/final/cp338_ft.pdf if you're
intertested!)
> You can control the SCHANNEL cipher suites by editing the registry.
There's
> a knowledge base article detailing how it's done:
> http://support.microsoft.com/default.aspx?scid=kb;en-us;245030
I've just checked on a Server 2003 machine, and there aren't any keys for
AES, so either it doesn't exists for schannel on 2003, or at least doesn't
have the same control options....
> Also, what language are you programming in? If you're using C or C++, you
> may want to consider OpenSSL.
Thanks for the suggestions!
Dave
Pieter Philippaerts
> AES, so either it doesn't exists for schannel on 2003, or at least doesn't
> have the same control options....
I don't think it's documented yet. Since the NTRU/AES cipher suites are
currently only specified in drafts and not in RFCs, I guess Microsoft's
implementation is a test implementation.
Dave Harvey (Medical Connections)
way to use:
TLS_RSA_WITH_AES_128_CBC_SHA
Dave
"Pieter Philippaerts" <Pie...@nospam.mentalis.org> wrote in message
news:u1WO8%23McDH...@TK2MSFTNGP12.phx.gbl...
Pieter Philippaerts
> way to use:
> TLS_RSA_WITH_AES_128_CBC_SHA
Then OpenSSL is your best choice.
John Banes [MS]
safely say that they are not implemented in Windows Server 2003.
Regards,
John Banes
[Microsoft Security Developer]
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"Pieter Philippaerts" <Pie...@nospam.mentalis.org> wrote in message
news:u1WO8%23McDH...@TK2MSFTNGP12.phx.gbl...
Dave Harvey (Medical Connections)
Thanks again for the info - one further question....
As I work in a generic Microsoft environment (my product is packaged as an
ActiveX component), one advantage of using native Microsoft procedures is
that my developers have Capicom available for all their certificate
loading/manipulation/checking, without me needing to duplicate all that.
How easy is it to interface Microsoft Certificate objects with the OpenSLL
library?
Dave
"Pieter Philippaerts" <Pie...@nospam.mentalis.org> wrote in message
news:OC5JVrNc...@TK2MSFTNGP11.phx.gbl...
Pieter Philippaerts
> Hmmm. I've never heard of the NTRU/AES cipher suites, but I think that I
can
> safely say that they are not implemented in Windows Server 2003.
After looking into it again, I noticed that the NTRU draft and the "56-bit
Export Cipher Suites For TLS" draft [you should be familiar with it ;-)] are
using overlapping cipher suite identifiers, hence the mixup.
The NTRU draft uses {0,61} <=> {0,68} and your draft uses {0,62} <=> {0,66}
as identifiers.
Regards,
Pieter Philippaerts
SSL and TLS for .NET: http://www.mentalis.org/go.php?sl
P.S.: in case you're interested, both drafts are available at
http://www.ietf.org/proceedings/01aug/51-118.htm
Pieter Philippaerts
> library?
OpenSSL uses its own certificate loading/checking/manipulation functions,
and it certainly wasn't designed with CryptoAPI compatibility in mind.
However I wouldn't know how easy or hard it is to make the two libraries
interoperate; you should ask that on the OpenSSL newsgroup
[mailing.openssl.users]
Thomas Pornin
> Is there any specific reason why you want AES support? Both RC4 and
> TripleDES are considered secure ciphers and both are supported by SCHANNEL.
Actually, RC4 is not considered as secure as TripleDES. There is no
known practical attack on SSL/TLS with RC4, but the amount of "trust"
which can be put in RC4 security is much less than what can be bet
on TripleDES or AES. There are academic attacks such as a practical
distinguisher (a way of telling that the RC4 output is not pure random).
Security is about not being broken into (and, I repeat, RC4 is quite
adequate for that) and being absolutely sure of it (and there, RC4 is
not as good as TripleDES or AES).
Therefore there are reasons why one would prefer TripleDES or AES over
RC4. Those reasons are more related to psychology and marketing than to
actual security, but psychology and marketing are not to be neglected.
Besides, TripleDES seems quite secure but is known to be quite slow.
DES was optimized for hardware implementations, and uses some bit
permutations which are really cheap on a specialized ASIC but very
painful to implement in software. TripleDES is (almost) three times
slower than DES. A few figures: on a modern PC such as an Athlon,
TripleDES requires about 1200 clock cycles to encrypt 8 bytes of data.
Therefore, a 1.2 GHz Athlon can encrypt / decrypt about 8 mega-bytes
of data per second, which is less than the bandwidth of a standard
100baseT network -- and this is with full cpu usage; usually, when you
communicate data from one machine to another, you have some operations
to perform on that data. You do not always have your full 1.2 GHz to
waste on the SSL/TLS encryption itself.
AES can encrypt 16 bytes of data in about 400 cycles; this is 6 times
faster than TripleDES.
In brief, there are some good reasons one might, in some settings,
prefer AES over both TripleDES and RC4 in SSL/TLS sessions. As a side
note, the TLS standard (RFC 2246) has been published on early 1999,
but the AES cipher suites (with RSA or Diffie-Hellman key exchange)
are standardized only in RFC 3268, from June 2002. This explains why
the Microsoft implementation does not yet have them.
--Thomas Pornin
Eugene Mayevski
> Thanks for the information....., so this leaves me with 2 options:
Three. Third is to use custom SSL/TLS implementation. For example, see
http://www.secureblackbox.com/
--
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com