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 decode
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 availabl
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_
On Thu, Feb 14, 2013, Joel Dice wrote:
> Hi all,
>
> I've been experimenting with the DTLS support in OpenSSL recently
> and discovered that my application was receiving garbage plaintext
> when packets were lost or reordered. Closer inspection suggested a
> possible cause: I was only enabling c
On Sat, Dec 27, 2008 at 08:42:19PM -0500, Hector Santos wrote:
> I'm finally catching up and updating our OPENSSL *.dll distribution
> with the latest build (0.9.8i). We had 0.9.8a (2006 time frame)
>
> The main reason is because we got inquiries regarding AES and SSL3 and
> cipher suites.
>
> If nothing else, you can implement your own interpretation of "HIGH"
> and "MEDIUM", and then for MEDIUM as specified by the user change the
> string passed to the cipher setup function to include "MEDIUM+" and
> the AES128 algorithm names.
Thanks Kyle. After giving this some thought I can see i
Hi Richard,
> The docs are outdated. AES is strong.
That makes sense. In that case I could let users choose either MEDIUM
or "Strong" along with which Cipher group (RC4, 3DES, DES, AES).
Of course if they choose Medium and only AES, they would not have any
cipher in the result list, so I could
If nothing else, you can implement your own interpretation of "HIGH"
and "MEDIUM", and then for MEDIUM as specified by the user change the
string passed to the cipher setup function to include "MEDIUM+" and
the AES128 algorithm names.
-Kyle H
On 1/28/06, Chris Clark <[EMAIL PROTECTED]> wrote:
> H
The docs are outdated. AES is strong.
--
SOA Appliance Group
IBM Application Integration Middleware
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-u
Hi Steve,
> Also there are grounds for classifying AES in general as "stronger" (for some
> value of stronger) due its 128 bit block length compared to the other block
> ciphers which have a 64 bit block length.
So I won't be able to use the MEDIUM and HIGH settings to let the
users choose betwee
On Sat, Jan 28, 2006, Chris Clark wrote:
>
> I was hoping for a simpler solution, so rather then letting users
> choose the exact cipher suite names they could simply choose between
> AES, 3DES, DES, RC4, and they could also choose if they want MEDIUM
> (128 bit) encryption, or HIGH (greater the
Hi Richard,
> The openssl "ciphers" command shows the text format of the cipher suites
> supported Allow you users to choose from (a subset of) that list, and
> set the env var or config param appropriately. Like PATH, it's a
> colon-separated list in order of priority.
Yes, but that would
The openssl "ciphers" command shows the text format of the cipher suites
supported Allow you users to choose from (a subset of) that list, and
set the env var or config param appropriately. Like PATH, it's a
colon-separated list in order of priority.
/r$
--
SOA Appliance Group
IB
Hi Richard,
> The high medium and low are arbitrary terms, and date back to then the US
> had stricter export controls on cryptography.
>
> Ignore them.
But I want my client/server application to allow users to select the
level of encryption they wish to use. It is my understanding that 128
bit A
The high medium and low are arbitrary terms, and date back to then the US
had stricter export controls on cryptography.
Ignore them.
/r$
--
SOA Appliance Group
IBM Application Integration Middleware
__
OpenSSL Project
, 2003 9:19 PM
Subject:
Re: Cipher Suites explanation
Neil Humphreys wrote:
My app is a listening server
with 2 ports. The less secure one is for performance, when it doesn't
matter if someone sees the data being sent, so it is not worth
encrypting/decry
I changed the subject line so that it makes more sense!
Neil Humphreys wrote:
Hi all,
I have an app that requires 2 types
of secure communications:
-one fully secured channel with
encrypted data
-one fully secured channel, *except*
that the data itself is not secret, and d
:
Ashutosh
Jaiswal
To: [EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 9:19
PM
Subject: Re: Cipher Suites
explanation
Neil Humphreys wrote:
My app is a listening server with 2 ports. The
less secure one is for performance, when it doesn't matter if someone
Aslam <[EMAIL PROTECTED]> writes:
> Hi..
>
> man SSL_CTX_set_cipher_list
Yeah, read the man page. Check out the documents on www.openssl.org
> but what should be the string format for the last parameter of above
> function call..
This is described in the ciphers man page.
-Ekr
___
Hi..
man SSL_CTX_set_cipher_list
but what should be the string format for the last parameter of above
function call..
Thanks
Aslam
-Original Message-
From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 3:27 PM
To: '[EMAIL PROTECTED]'
Subject:
On Tue, Aug 14, 2001 at 02:09:09PM -0400, Aslam wrote:
> How can I set or add specific TLS cipher suite in SSL_CTX. Cause what I
> found is in get_client_hello() there is some default sting for cipher suite
> and acoordingly all the default cipher suites r added. Isn't there any API
> which takes
21 matches
Mail list logo
