info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Consequences to draw from the latest Snowden revelations?
71 views
Skip to first unread message
Niklas Schnelle
Sep 7, 2013, 8:56:14 AM9/7/13
to
Dear OpenSSL users,
so as most of us probably have, I've read both the Guardian article [1] as well as Bruce Schneier's comments [2] on the newest revelations. So I was wondering given what little information is available
what can be done to improve the situation.
Here is my take on what we know:
- It's clear SSL and thus OpenSSL as one of it's most important implementation are very likely
Here is my take on what we know:
- It's clear SSL and thus OpenSSL as one of it's most important implementation are very likely
to be the prime target of whatever Bullrun does.
- It looks like the NSA has actively sabotaged any and all NIST standardization processes.
- A quick check reveals that both Facebook and Google
- People have to ask themselves whether it's a coincidence RC4 is still used even by Google
- Schneier who has read hundreds of the Top Secret NSA files in his article claims he wouldn't trust
Elliptic Curves anymore because there are doubts about some of the constants used.
So what do you guys and girls think? What can be done and is there any chance for a bigger audit to find NSA influences?
Gary
Sep 7, 2013, 11:32:54 AM9/7/13
to
In a recent Q&A with Bruce Schneier and James Ball (a journalist)[1],
Ball said, "Because the NSA and GCHQ have been influencing standards,
and working to covertly modify code, almost anything could potentially
have been compromised. Something as simple as – hypothetically –
modifying a basic random-number-generator could weaken numerous
implementations of open-source code."
In 2007, there was a fair amount of discussion about some elliptic
curve algorithms -- and specifically random-number generators
introduced by NIST in special publication 800-90 (now split off in to
800-90A)[2]. Here's a list of highlights from Bruce's article back
then[3]:
"... one of those generators -- the one based on elliptic curves -- is
not like the others. Called Dual_EC_DRBG, not only is it a mouthful to
say, it's also three orders of magnitude slower than its peers. It's
in the standard only because it's been championed by the NSA, which
first proposed it years ago in a related standardization project at
the American National Standards Institute. ... Problems with
Dual_EC_DRBG were first described in early 2006. The math is
complicated, but the general point is that the random numbers it
produces have a small bias. The problem isn't large enough to make the
algorithm unusable ... [but] at the CRYPTO 2007 conference in August,
Dan Shumow and Niels Ferguson showed that the algorithm contains a
weakness that can only be described a backdoor. ...
What Shumow and Ferguson showed is that these numbers have a
relationship with a second, secret set of numbers that can act as a
kind of skeleton key. If you know the secret numbers, you can predict
the output of the random-number generator after collecting just 32
bytes of its output. To put that in real terms, you only need to
monitor one TLS internet encryption connection in order to crack the
security of that protocol. If you know the secret numbers, you can
completely break any instantiation of Dual_EC_DRBG.
The researchers don't know what the secret numbers are. But because of
the way the algorithm works, the person who produced the constants
might know; he had the mathematical opportunity to produce the
constants and the secret numbers in tandem. ... We don't know where
the constants came from in the first place. We only know that whoever
came up with them could have the key to this backdoor. And we know
there's no way for NIST -- or anyone else -- to prove otherwise. ...
Even if no one knows the secret numbers, the fact that the backdoor is
present makes Dual_EC_DRBG very fragile. If someone were to solve just
one instance of the algorithm's elliptic-curve problem, he would
effectively have the keys to the kingdom. ...
I don't understand why the NSA was so insistent about including
Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's
public, and rather obvious. It makes no sense from an engineering
perspective: It's too slow for anyone to willingly use it. And it
makes no sense from a backwards-compatibility perspective: Swapping
one random-number generator for another is easy.
My recommendation, if you're in need of a random-number generator, is
not to use Dual_EC_DRBG under any circumstances. If you have to use
something in SP 800-90, use CTR_DRBG or Hash_DRBG."
So from Ball's recent comments one might suppose that software to keep
an eye on are those that use or could potentially be using
Dual_EC_DRBG from NIST special publication 800-90A. It so happens that
there is a list of implementations using the DRBG validation suite[4].
Some of them could be repeats but I count about 65 hits on
Dual_EC_DRBG -- including the OpenSSL FIPS module. What I find
interesting is that Bruce has been helping the Guardian vet all the
documents they're publishing and aside from talking about his own
methods for remaining secure[5], he's not gone on record about his
speculation as to what technical methods the NSA have used to
compromise so much at once. However, I have seen much call for
industry insiders to come forward if they've taken part in any known
compromise of products. This is the closest I've come to tracking down
anything useful -- and my hand was heavily tipped by a friend that did
some sleuthing of his own to suggest Dual_EC_DRBG in the first place.
But I am surprised to find just how many have implemented Dual_EC_DRBG
despite all the warnings against it in light of how crucial random
number generation is to the integrity of PKI.
-Gary
1. http://www.theguardian.com/commentisfree/2013/sep/06/nsa-surveillance-revelations-encryption-expert-chat
2. http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
3. http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115
4. http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
5. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Ball said, "Because the NSA and GCHQ have been influencing standards,
and working to covertly modify code, almost anything could potentially
have been compromised. Something as simple as – hypothetically –
modifying a basic random-number-generator could weaken numerous
implementations of open-source code."
In 2007, there was a fair amount of discussion about some elliptic
curve algorithms -- and specifically random-number generators
introduced by NIST in special publication 800-90 (now split off in to
800-90A)[2]. Here's a list of highlights from Bruce's article back
then[3]:
"... one of those generators -- the one based on elliptic curves -- is
not like the others. Called Dual_EC_DRBG, not only is it a mouthful to
say, it's also three orders of magnitude slower than its peers. It's
in the standard only because it's been championed by the NSA, which
first proposed it years ago in a related standardization project at
the American National Standards Institute. ... Problems with
Dual_EC_DRBG were first described in early 2006. The math is
complicated, but the general point is that the random numbers it
produces have a small bias. The problem isn't large enough to make the
algorithm unusable ... [but] at the CRYPTO 2007 conference in August,
Dan Shumow and Niels Ferguson showed that the algorithm contains a
weakness that can only be described a backdoor. ...
What Shumow and Ferguson showed is that these numbers have a
relationship with a second, secret set of numbers that can act as a
kind of skeleton key. If you know the secret numbers, you can predict
the output of the random-number generator after collecting just 32
bytes of its output. To put that in real terms, you only need to
monitor one TLS internet encryption connection in order to crack the
security of that protocol. If you know the secret numbers, you can
completely break any instantiation of Dual_EC_DRBG.
The researchers don't know what the secret numbers are. But because of
the way the algorithm works, the person who produced the constants
might know; he had the mathematical opportunity to produce the
constants and the secret numbers in tandem. ... We don't know where
the constants came from in the first place. We only know that whoever
came up with them could have the key to this backdoor. And we know
there's no way for NIST -- or anyone else -- to prove otherwise. ...
Even if no one knows the secret numbers, the fact that the backdoor is
present makes Dual_EC_DRBG very fragile. If someone were to solve just
one instance of the algorithm's elliptic-curve problem, he would
effectively have the keys to the kingdom. ...
I don't understand why the NSA was so insistent about including
Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's
public, and rather obvious. It makes no sense from an engineering
perspective: It's too slow for anyone to willingly use it. And it
makes no sense from a backwards-compatibility perspective: Swapping
one random-number generator for another is easy.
My recommendation, if you're in need of a random-number generator, is
not to use Dual_EC_DRBG under any circumstances. If you have to use
something in SP 800-90, use CTR_DRBG or Hash_DRBG."
So from Ball's recent comments one might suppose that software to keep
an eye on are those that use or could potentially be using
Dual_EC_DRBG from NIST special publication 800-90A. It so happens that
there is a list of implementations using the DRBG validation suite[4].
Some of them could be repeats but I count about 65 hits on
Dual_EC_DRBG -- including the OpenSSL FIPS module. What I find
interesting is that Bruce has been helping the Guardian vet all the
documents they're publishing and aside from talking about his own
methods for remaining secure[5], he's not gone on record about his
speculation as to what technical methods the NSA have used to
compromise so much at once. However, I have seen much call for
industry insiders to come forward if they've taken part in any known
compromise of products. This is the closest I've come to tracking down
anything useful -- and my hand was heavily tipped by a friend that did
some sleuthing of his own to suggest Dual_EC_DRBG in the first place.
But I am surprised to find just how many have implemented Dual_EC_DRBG
despite all the warnings against it in light of how crucial random
number generation is to the integrity of PKI.
-Gary
1. http://www.theguardian.com/commentisfree/2013/sep/06/nsa-surveillance-revelations-encryption-expert-chat
2. http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
3. http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115
4. http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
5. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Steve Marquess
Sep 7, 2013, 5:26:29 PM9/7/13
to
On 09/07/2013 11:32 AM, Gary wrote:
> ...
> FIPS module. ...
OpenSSL FIPS Object Module.
The Dual EC DRBG was implemented at the request of a paying customer[*].
We were well aware at the time of the dubious reputation of that
algorithm, but it is a formal published standard. There is no disgrace
in *implementing* weak cryptography; OpenSSL already contains some
implementations of known weak crypto. The sin is in *using* weak
cryptography when not forced to by compelling circumstances.
And that's the rub. Cryptography in the U.S. Federal government is
heavily constrained by policy. FIPS 140-2 for instance, which the
OpenSSL FIPS module was specifically created to satisfy. I've long been
on the record as saying, loud and clear, that you shouldn't use FIPS
140-2 validated cryptography if you have a choice. I wasn't thinking of
standards sabotage at the time; that just reinforces the argument.
Unfortunately some OpenSSL users don't have a choice, specifically the
ones selling cryptographic products in the USG marketplace.
New validations (such as #1747, the latest OpenSSL FIPS Module) are
rare. Once done new algorithms can't be added to an existing module, so
there is a tendency (ours and the paying sponsors, of which there were
dozens) to include everything we think might be relevant over the
lifespan of the module (years). So we added a number of new
algorithms for that validation (AES-CCM and AES-XTS for instance). The
#1747 validation includes more algorithms than any other.
Note that Dual EC DRBG is *NOT* used by default and a calling
application must specifically and deliberately enable it; that cannot be
done accidentally. Any application which does so will hopefully be fully
aware of the consequences (and probably must do so for
policy reasons).
-Steve M.
[*]Who was the customer? OSF is bound by some 200 separate NDAs
(Non-Disclosure Agreements). Occasionally a client tells us about some
product plans or technologies or whatever that they at least consider
sensitive and valuable information, but the usual purpose of the NDA
is to protect the identity of the client. Acme Corp doesn't want WigitCo
to know Acme is using new features in the worlds finest crypto library
and toolkit. I don't like NDAs but they are standard practice in the
business world and we will honor them.
I can say that for damn sure none of my OSF colleagues have implemented
any back-doors or deliberate vulnerabilities (other than those inherent
in the technical standards themselves). We don't implement features in
the baseline code that aren't based on open standards.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marq...@opensslfoundation.com
marq...@openssl.com
gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc
> ...
>
> Here's a list of highlights from Bruce's article back
> then[3]:...
>
> "...
> Here's a list of highlights from Bruce's article back
> then[3]:...
>
> My recommendation, if you're in need of a random-number generator, is
> not to use Dual_EC_DRBG under any circumstances. If you have to use
> something in SP 800-90, use CTR_DRBG or Hash_DRBG."
>
> ... I count about 65 hits on Dual_EC_DRBG -- including the OpenSSL
> not to use Dual_EC_DRBG under any circumstances. If you have to use
> something in SP 800-90, use CTR_DRBG or Hash_DRBG."
>
> FIPS module. ...
> But I am surprised to find just how many have implemented Dual_EC_DRBG
> despite all the warnings against it in light of how crucial random
> number generation is to the integrity of PKI.
I can shed some light, at least regarding the implementation of the
> despite all the warnings against it in light of how crucial random
> number generation is to the integrity of PKI.
OpenSSL FIPS Object Module.
The Dual EC DRBG was implemented at the request of a paying customer[*].
We were well aware at the time of the dubious reputation of that
algorithm, but it is a formal published standard. There is no disgrace
in *implementing* weak cryptography; OpenSSL already contains some
implementations of known weak crypto. The sin is in *using* weak
cryptography when not forced to by compelling circumstances.
And that's the rub. Cryptography in the U.S. Federal government is
heavily constrained by policy. FIPS 140-2 for instance, which the
OpenSSL FIPS module was specifically created to satisfy. I've long been
on the record as saying, loud and clear, that you shouldn't use FIPS
140-2 validated cryptography if you have a choice. I wasn't thinking of
standards sabotage at the time; that just reinforces the argument.
Unfortunately some OpenSSL users don't have a choice, specifically the
ones selling cryptographic products in the USG marketplace.
New validations (such as #1747, the latest OpenSSL FIPS Module) are
rare. Once done new algorithms can't be added to an existing module, so
there is a tendency (ours and the paying sponsors, of which there were
dozens) to include everything we think might be relevant over the
lifespan of the module (years). So we added a number of new
algorithms for that validation (AES-CCM and AES-XTS for instance). The
#1747 validation includes more algorithms than any other.
Note that Dual EC DRBG is *NOT* used by default and a calling
application must specifically and deliberately enable it; that cannot be
done accidentally. Any application which does so will hopefully be fully
aware of the consequences (and probably must do so for
policy reasons).
-Steve M.
[*]Who was the customer? OSF is bound by some 200 separate NDAs
(Non-Disclosure Agreements). Occasionally a client tells us about some
product plans or technologies or whatever that they at least consider
sensitive and valuable information, but the usual purpose of the NDA
is to protect the identity of the client. Acme Corp doesn't want WigitCo
to know Acme is using new features in the worlds finest crypto library
and toolkit. I don't like NDAs but they are standard practice in the
business world and we will honor them.
I can say that for damn sure none of my OSF colleagues have implemented
any back-doors or deliberate vulnerabilities (other than those inherent
in the technical standards themselves). We don't implement features in
the baseline code that aren't based on open standards.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marq...@opensslfoundation.com
marq...@openssl.com
gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc
Niklas Schnelle
Sep 7, 2013, 6:41:46 PM9/7/13
to
Ok this sounds like Dual EC DRBG is not really a problem for someone not bound to use it.
So what about ECDH, I've read in many places e.g. on this cryptography mailinglist [1] that
it could be trouble when the curves have been suggested by the NSA.
What about the use of hardware rngs?
What about the use of hardware rngs?
Graham Leggett
Sep 7, 2013, 8:13:33 PM9/7/13
to
On 07 Sep 2013, at 11:26 PM, Steve Marquess <marq...@opensslfoundation.com> wrote:
> Note that Dual EC DRBG is *NOT* used by default and a calling
> application must specifically and deliberately enable it; that cannot be
> done accidentally. Any application which does so will hopefully be fully
> aware of the consequences (and probably must do so for
> policy reasons).
Is the Dual EC DRBG used in any hardware crypto implementations, and if so, how would we avoid using those hardware implementations with certainty in OpenSSL?
> Note that Dual EC DRBG is *NOT* used by default and a calling
> application must specifically and deliberately enable it; that cannot be
> done accidentally. Any application which does so will hopefully be fully
> aware of the consequences (and probably must do so for
> policy reasons).
I'm thinking specifically of the Intel one described here: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator
Regards,
Graham
--
Randolph D.
Sep 8, 2013, 4:16:06 AM9/8/13
to
what can be done to improve the situation.
One option is to switch from central SSL Certs to selfsigned SSL Certs in a p2p environment
SSL sends the key over D/H exchange, which could be attacked by MITM.
One better option would be to send the key for SSL over an AES End to End encryption.
is a secure multi encrypting messenger, which provides e.g. the AES over RSA and then third uses OpenSSL in a p2p environment with self signed certificates as a channel, to send the AES encrypted message over it.
It would be good, if the SSL cert could be exportable to be sent as well over AES and not DH.
This is the homework, OpenSSL developers have to do to provide that in their library for self signed certificates, that they can be sent over different ways than just over Diffie-Hellmann-Exchange.
What needs to be done to establish an SSL connection using an AES channel to share the secret?
Regards Randoph
Gary Driggs
Sep 8, 2013, 5:28:56 AM9/8/13
to
On Sep 8, 2013, at 1:16 AM, "Randolph D." <rdoh...@gmail.com> wrote:
What needs to be done to establish an SSL connection using an AES channel to share the secret?
If you're just looking for better trust models for SSL certificates, have a look at the methods proposed by the DANE working group...
Jakob Bohm
Sep 11, 2013, 10:49:23 PM9/11/13
to
On 9/8/2013 2:13 AM, Graham Leggett wrote:
> On 07 Sep 2013, at 11:26 PM, Steve Marquess <marq...@opensslfoundation.com> wrote:
>
>> Note that Dual EC DRBG is *NOT* used by default and a calling
>> application must specifically and deliberately enable it; that cannot be
>> done accidentally. Any application which does so will hopefully be fully
>> aware of the consequences (and probably must do so for
>> policy reasons).
>
> Is the Dual EC DRBG used in any hardware crypto implementations, and if so, how would we avoid using those hardware implementations with certainty in OpenSSL?
>
> I'm thinking specifically of the Intel one described here: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator
>
That new Intel design sounds suspiciously like they are feeding their
> On 07 Sep 2013, at 11:26 PM, Steve Marquess <marq...@opensslfoundation.com> wrote:
>
>> Note that Dual EC DRBG is *NOT* used by default and a calling
>> application must specifically and deliberately enable it; that cannot be
>> done accidentally. Any application which does so will hopefully be fully
>> aware of the consequences (and probably must do so for
>> policy reasons).
>
> Is the Dual EC DRBG used in any hardware crypto implementations, and if so, how would we avoid using those hardware implementations with certainty in OpenSSL?
>
> I'm thinking specifically of the Intel one described here: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator
>
high quality hardware random through a 256 bit EC DRBG before allowing
any user code to see it, so if that EC DRBG used is compromised, so are
all the random bits.
Besides, I gave up using Intel-promoted hardware crypto when they
removed the firmware hub RNG just after convincing everybody to add
software support for it.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Jakob Bohm
Sep 11, 2013, 11:06:39 PM9/11/13
to
On 9/8/2013 10:16 AM, Randolph D. wrote:
> 2013/9/7 Niklas Schnelle <niklas....@gmail.com
> <mailto:niklas....@gmail.com>>
The problem is not how the certificates are distributed but how the
crypto that uses the certificates is done.
And when I looked at the Goldbug code I found so many signs of bad
coding that I wouldn't recommend it for anything without a competent
redesign and reimplementation, this time with proper expert reviewed
protocol docs.
> It would be good, if the SSL cert could be exportable to be sent as well
> over AES and not DH.
AES alone is completely vulnerable to man-in-the-middle attacks and to
after-the-fact decryption once the reused key has been cracked or
confiscated. DH is only vulnerable to man-in-the-middle. RSA alone is
vulnerable only to after-the-fact decryption. DH followed by a digital
signature (RSA, ElGamal, DSA, SRP etc.) on the key exchange messages is
vulnerable to neither problem, and this is what SSL's EDH and ECDH
suites use (SSL also has suites that omit the EDH/ECDH part, those are
vulnerable to after-the-fact decryption).
Now regardless of what crypto you use, you remain vulnerable to 3
things:
- Bad random numbers.
- Algorithms that are not as secure as expected/advertised. No one
knows if some secret agency has cracked one of the currently trusted
algorithms and not told us, similar to what happened to the German
Enigma algorithm during world war II and just after (Enigma machines
were sold to newly freed colonies by countries that knew that Enigma
had been secretly cracked during the war).
- Badly designed protocols that allow cracking the transmission without
cracking any of the quality parts it was made from. The BEAST and CRIME
attacks against some versions of SSL do just that.
> This is the homework, OpenSSL developers have to do to provide that in
> their library for self signed certificates, that they can be sent over
> different ways than just over Diffie-Hellmann-Exchange.
>
> 2013/9/7 Niklas Schnelle <niklas....@gmail.com
> <mailto:niklas....@gmail.com>>
>
> Dear OpenSSL users,
>
> what can be done to improve the situation.
>
>
> One option is to switch from central SSL Certs to selfsigned SSL Certs
> in a p2p environment
> http://en.wikipedia.org/wiki/Self-signed_certificate
> SSL sends the key over D/H exchange, which could be attacked by MITM.
> One better option would be to send the key for SSL over an AES End to
> End encryption.
>
> http://goldbug.sf.net
>
> is a secure multi encrypting messenger, which provides e.g. the AES over
> RSA and then third uses OpenSSL in a p2p environment with self signed
> certificates as a channel, to send the AES encrypted message over it.
>
You obviously understand nothing about crypto.
> Dear OpenSSL users,
>
> what can be done to improve the situation.
>
>
> One option is to switch from central SSL Certs to selfsigned SSL Certs
> in a p2p environment
> http://en.wikipedia.org/wiki/Self-signed_certificate
> SSL sends the key over D/H exchange, which could be attacked by MITM.
> One better option would be to send the key for SSL over an AES End to
> End encryption.
>
> http://goldbug.sf.net
>
> is a secure multi encrypting messenger, which provides e.g. the AES over
> RSA and then third uses OpenSSL in a p2p environment with self signed
> certificates as a channel, to send the AES encrypted message over it.
>
The problem is not how the certificates are distributed but how the
crypto that uses the certificates is done.
And when I looked at the Goldbug code I found so many signs of bad
coding that I wouldn't recommend it for anything without a competent
redesign and reimplementation, this time with proper expert reviewed
protocol docs.
> It would be good, if the SSL cert could be exportable to be sent as well
> over AES and not DH.
after-the-fact decryption once the reused key has been cracked or
confiscated. DH is only vulnerable to man-in-the-middle. RSA alone is
vulnerable only to after-the-fact decryption. DH followed by a digital
signature (RSA, ElGamal, DSA, SRP etc.) on the key exchange messages is
vulnerable to neither problem, and this is what SSL's EDH and ECDH
suites use (SSL also has suites that omit the EDH/ECDH part, those are
vulnerable to after-the-fact decryption).
Now regardless of what crypto you use, you remain vulnerable to 3
things:
- Bad random numbers.
- Algorithms that are not as secure as expected/advertised. No one
knows if some secret agency has cracked one of the currently trusted
algorithms and not told us, similar to what happened to the German
Enigma algorithm during world war II and just after (Enigma machines
were sold to newly freed colonies by countries that knew that Enigma
had been secretly cracked during the war).
- Badly designed protocols that allow cracking the transmission without
cracking any of the quality parts it was made from. The BEAST and CRIME
attacks against some versions of SSL do just that.
> This is the homework, OpenSSL developers have to do to provide that in
> their library for self signed certificates, that they can be sent over
> different ways than just over Diffie-Hellmann-Exchange.
>
> What needs to be done to establish an SSL connection using an AES
> channel to share the secret?
>
Your are wrong, see above.
> channel to share the secret?
>
0 new messages