On Thu, 28 Feb 2019 14:41:19 +0100,
Salz, Rich wrote:
>
> > There are two options. First, the application does the digest and
> > sign as two separate things.
>
> My memory is a foggy surrounding that scenario, so I might be wrong,
> but I think it was argued that this was
> There are two options. First, the application does the digest and
> sign as two separate things.
My memory is a foggy surrounding that scenario, so I might be wrong,
but I think it was argued that this was invalid use from a FIPS
perspective. Now, we can't actually
>From https://www.openssl.org/docs/fips/UserGuide-2.0.pdf
I got these lines
"OpenSSL provides mechanisms for interfacing with external cryptographic
devices, such as
accelerator cards, via “ENGINES.” This mechanism is not disabled in FIPS
mode. In general, if a
FIPS validated cryptographic
On 27/02/2019 22:20, Richard Levitte wrote:
>> I believe Richard is wrong here. Or at least his text could be
>> misleading. If the EVP API does the digesting with one module and
>> then calls another module to do the RSA signing, that is okay.
>
> Huh? From the design document, section
On Thu, 28 Feb 2019 00:51:24 +0100,
Dr. Matthias St. Pierre wrote:
>
>
> > Uhm, I'm confused. I thought we were talking about 3.0?
>
> Well, the original post started at FIPS 2.0:
>
> > I am using openssl-fips-2.0.16 and openssl-1.0.2e.
>
On Thu, 28 Feb 2019 00:17:13 +0100,
Salz, Rich wrote:
>
> >Huh? From the design document, section "Example dynamic views of
> algorithm selection", after the second diagram:
>
> An EVP_DigestSign* operation is more complicated because it
> involves two algorithms: a
> Uhm, I'm confused. I thought we were talking about 3.0?
Well, the original post started at FIPS 2.0:
> I am using openssl-fips-2.0.16 and openssl-1.0.2e.
https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html
But it seems like the discussion in the thread has drifted a
>Huh? From the design document, section "Example dynamic views of
algorithm selection", after the second diagram:
An EVP_DigestSign* operation is more complicated because it
involves two algorithms: a signing algorithm, and a digest
algorithm. In general those
Uhm, I'm confused. I thought we were talking about 3.0?
"Dr. Matthias St. Pierre" skrev: (27 februari
2019 23:34:23 CET)
>
>> -Ursprüngliche Nachricht-
>> > >I always understood "FIPS-capable OpenSSL" to refer
>specifically to an
>> > OpenSSL compiled with the options to
> -Ursprüngliche Nachricht-
> > >I always understood "FIPS-capable OpenSSL" to refer specifically to an
> > OpenSSL compiled with the options to incorporate the FIPS canister
> > module, not just any OpenSSL build that might be used in FIPS compliant
> > applications (as
On Wed, 27 Feb 2019 22:54:41 +0100,
Salz, Rich via openssl-users wrote:
>
> >I always understood "FIPS-capable OpenSSL" to refer specifically to an
> OpenSSL compiled with the options to incorporate the FIPS canister
> module, not just any OpenSSL build that might be used in FIPS
>I always understood "FIPS-capable OpenSSL" to refer specifically to an
OpenSSL compiled with the options to incorporate the FIPS canister
module, not just any OpenSSL build that might be used in FIPS compliant
applications (as that would be any OpenSSL at all).
Yes, that is
On 27/02/2019 22:18, Richard Levitte wrote:
On Wed, 27 Feb 2019 21:55:29 +0100,
Jakob Bohm via openssl-users wrote:
On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
If you change a single line of code or do not build it EXACTLY as documented,
you cannot claim to use the OpenSSL
On Wed, 27 Feb 2019 21:55:29 +0100,
Jakob Bohm via openssl-users wrote:
>
> On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
> > If you change a single line of code or do not build it EXACTLY as
> > documented, you cannot claim to use the OpenSSL validation.
> >
>
> I believe the
On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
If you change a single line of code or do not build it EXACTLY as documented,
you cannot claim to use the OpenSSL validation.
I believe the context here is one I also mentioned in my comment on
the 3.0 draft spec:
- OpenSSL FIPS
If you change a single line of code or do not build it EXACTLY as documented,
you cannot claim to use the OpenSSL validation.
No.
The OpenSSL FIPS Module is not written that way. It should not be permitting
any non-FIPS implementations (see Rich's email regarding a bug).
You could write your own engine, get that FIPS certified, and run it with
plain, vanilla OpenSSL.
There's a design spec out for OpenSSL 3.0.0 that
The requirement here is, to offload my "engine supported fips-compliant
methods" to engine and other "fips-complaint" functions to openssl
dynamically. Here I need to use openssl-fips module I guess.
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Thanks for the reply.
With non-fips openssl, it is possible to write my own fips-module. I
understood.
But, is it possible for me to write a fips-compliant/fips validated "dynamic
engine" with openssl-fips? Which allows me to offload "fips-compilant"
functions to my engine "dynamically"?
--
To clarify here, using the OpenSSL FIPS implementation does not allow you to
claim “FIPS Validated”, rather this would be “FIPS Compliant”. If you want to
claim “FIPS Validated”, you must get your own validation for your
implementation regardless of what you are using, OpenSSL FIPS module or
* Which means in fips mode ciphers never gets offloaded to engine?
* All other functions (digest, RSA etc) , it first updates to fips
function, and then engine function. Why only ciphers has this different
behaviour?
That seems like a bug. In FIPS mode you can only use the
Hi,
I am unable to use AES-cipher offload to my engine even though it was
registered with the proper flag (EVP_CIPH_FLAG_FIPS). I was able to use
RSA, digests, and ECDSA to the engine with corresponding flags.
I am using openssl-fips-2.0.16 and openssl-1.0.2e.
OPENSSL_FIPS is set.
I come
Dear guys,
I would to have some bright understand about AES cihper in openssl, based
what i understand it used a table loookupt to speed the performance of AES
operation.
What i would to know, is there any way to disable this table lookup feature
? Why i do in that way ? it is just a matter of
On 2/16/06, Kyle Hamilton wrote:
Yeah. Any cipher that is not explicitly added is denied. So, try just doing:
CString Shif = AES128-SHA;
When I just use this string, it automaticly adds AES256-SHA as well.
This appears to be a bug in OpenSSL 0.98a. Could anyone confirm this?
-Chris
On Fri, Feb 17, 2006, Chris Clark wrote:
On 2/16/06, Kyle Hamilton wrote:
Yeah. Any cipher that is not explicitly added is denied. So, try just
doing:
CString Shif = AES128-SHA;
When I just use this string, it automaticly adds AES256-SHA as well.
This appears to be a bug in
CString Shif = AES128-SHA;
When I just use this string, it automaticly adds AES256-SHA as well.
This appears to be a bug in OpenSSL 0.98a. Could anyone confirm this?
Yes I can confirm that. The ciphers command does the same.
Thanks Steve. Do you know if this has been fixed in the
On Fri, Feb 17, 2006, Chris Clark wrote:
CString Shif = AES128-SHA;
When I just use this string, it automaticly adds AES256-SHA as well.
This appears to be a bug in OpenSSL 0.98a. Could anyone confirm this?
Yes I can confirm that. The ciphers command does the same.
Thanks
I tried adding : as suggested, but this still did not work. :(
Does anyone have other suggestions?
-Chris
I'm trying to allow my program to be configurable for either AES 128
bit, or AES 256 bit. The problem is that when I select only the
AES128-SHA cipher, the AES256-SHA cipher gets added
Yeah. Any cipher that is not explicitly added is denied. So, try just doing:
CString Shif = AES128-SHA;
// C++ automatic type conversion converts Shif appropriately to LPSTR
SSL_CTX_set_cipher_list(m_ctx, Shif);
/* SSL_CTX_set_options(SSL_OP_NO_SSLv2); */
/* Since AES128 isn't an SSLv2 cipher
I'm trying to allow my program to be configurable for either AES 128
bit, or AES 256 bit. The problem is that when I select only the
AES128-SHA cipher, the other AES ciphers (including 256 bit) get added
automaticlly.
Is this a limitation of selecting AES, or am I doing something wrong?
Here is
On Mon, Feb 13, 2006 at 12:34:42PM -0800, Chris Clark wrote:
I'm trying to allow my program to be configurable for either AES 128
bit, or AES 256 bit. The problem is that when I select only the
AES128-SHA cipher, the other AES ciphers (including 256 bit) get added
automaticlly.
Is this a
Hi,
I would like do AES enrcyption in counter mode (CTR) if possible.
The evp.h include file for OpenSSL version 0.9.7e have these three
outcommented declarations:
#if 0
const EVP_CIPHER *EVP_aes_128_ctr(void);
#endif
#if 0
const EVP_CIPHER *EVP_aes_192_ctr(void);
#endif
#if 0
const EVP_CIPHER
Hi,
I have a TLS 1.0 client which supports AES cipher suites defined in RFC3268.
However, when it connects to a TLS server using OpenSSL 0.97. It gets a TLS
fatal alert, 20 (bad record MAC). I saw the version is 3.1 and the cipher
suite ID is 0x00 0x35 (TLS_RSA_WITH_AES_256_CBC_SHA) in the server
33 matches
Mail list logo
