Re: [openssl-users] iOS FIPS armv7, armv7s, arm64

[Brian Jost]

>
> I have been trying for the life of me to get the FIPS module to compile
> for those supported platforms. Our app compiles for those platforms so
> without a compatible version of the openssl FIPS it causes errors.
>
> Is there any plans to have the FIPS module support those architectures?
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Custom Random number generation while in Fips mode

[Thomas Francis, Jr.]

> On Jul 28, 2016, at 11:00 AM, pratyush parimal  
> wrote:
> 
> Hi Thomas,
> 
> Thanks for your response! It clears up matters a lot :)
> 
> There's one thing that I thought of though -- even though I'm generating the 
> salt via non-OpenSSL means, the actual function that I'm using for hashing is 
> "SHA512" from FIPS OpenSSL.
> Does the mere usage of salt that was generated via a non-FIPS-recommended 
> approach violate my compliance ?

You used what is typically considered a cryptographic function (some form of 
RNG) from a source other than your cryptographic module running in approved 
mode.  Unless you can fully justify that use as for non-cryptographic purposes, 
your product is not complying with FIPS 140.  Given that it’s a salt for 
hashing passwords, I think you’ll have a really hard time convincing customers 
and auditors that the salt generation is for non-cryptographic purposes.  After 
all, if that’s not cryptographic, why didn’t you use something more 
deterministic (like a counter, or a user name) for the salt?

> I understand what you mean by "I'm not an auditor or a lawyer" , but I'd 
> still appreciate your opinion / experience in the matter :)

In my limited experience, auditors are not computer security experts.  They’re 
smart people, but they tend to fall back on very simple guidelines when it 
comes to things outside their own expertise (like what’s a cryptographic 
algorithm, and what’s a cryptographic purpose).  You might be able to get away 
with it, but I wouldn’t want to stake a sale on it.  Especially not if there 
are penalties attached for failing an audit.

TOM

> Thanks,
> Pratyush.
> 
> On Thu, Jul 28, 2016 at 10:23 AM, Thomas Francis, Jr. 
>  wrote:
> 
> > On Jul 27, 2016, at 8:18 PM, pratyush parimal  
> > wrote:
> >
> > Hi all,
> >
> > I work on a consumer application which is striving to be fips-140-2 
> > compliant.
> >
> > I'm using OpenSSL as recommended in the fips guide by invoking 
> > fips_mode_set(). However, in certain parts of the same application, I'm 
> > using my own non-OpenSSL random number generator to generate salts for 
> > hashing passwords for the app user accounts(I'm not using RAND_bytes).
> >
> > Does anyone know if using my custom random number generator in this way 
> > violates the app's fips compliance?
> 
> That’s almost certainly a violation.  There might be a few edge cases where 
> it is not, but they’re very unlikely.  To determine if you’re even close to 
> such cases, ask: Does the RNG I’m using come from another FIPS 140 validated 
> cryptographic module?  Am I using that module in approved mode?  Am I using 
> that module according to its security policy?  Do I have explicit permission 
> from the customers’ auditors to mix two modules in my product?
> 
> If the answer to all of those questions is yes, you _might_ be OK, for now.  
> A few auditors (in the past, anyway) considered it OK to mix modules, while 
> other auditors say no.  My own reading of FIPS 140-2 is that you may not mix 
> modules.  But I’m not an auditor or a lawyer. :)
> 
> The other question to ask is: can I clearly explain that the use of the 
> non-approved RNG is for non-cryptographic purposes, and easily justify that 
> explanation?  Given what you said about why you’re using it, I’m pretty sure 
> the answer to that one is “no”. :)  And even if you could, that’s still a 
> very weak argument to be making to your customers’ auditors, who may decide 
> it’s still not allowed even if they agree it’s for non-cryptographic purposes.
> 
> > Am I really supposed to be using
> > RAND_bytes for compliance reasons?
> 
> Yes.
> 
> > Thanks in advance!
> > Pratyush.
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] different encrypted text for the same plain text message

[Short, Todd]

Rich Salz basically told this guy to read Wikipedia about cryptography… :)
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jul 28, 2016, at 11:15 AM, Benjamin Kaduk 
> wrote:

There are several places where a per-connection random input is introduced, 
with a specific goal of making encryptions of the same plaintext produce 
different ciphertexts (as well as other benefits).  If a plaintext always 
produced the same ciphertext, then an attacker could make a dictionary of 
different observed ciphertexts and know when the same plaintext was being 
repeated, which violates the confidentiality property desired from the protocol.

-Ben

On 07/28/2016 06:19 AM, R-D intern wrote:

Hello,
I am using ECDSA-ECDHE-AES-SHA cipher suite for client -server security.I
tried understanding the mechanism handshake mechanism. What still quizzes me
is ; communication between a specific client -server for a specific session
generates different encrypted text for the same plain text message. What
leads  to this? Can anybody elaborate?
Please reply.
Thanks and regards,
Suman



--
View this message in context: 
http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595.html
Sent from the OpenSSL - User mailing list archive at 
Nabble.com.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] different encrypted text for the same plain text message

[Benjamin Kaduk]

There are several places where a per-connection random input is
introduced, with a specific goal of making encryptions of the same
plaintext produce different ciphertexts (as well as other benefits).  If
a plaintext always produced the same ciphertext, then an attacker could
make a dictionary of different observed ciphertexts and know when the
same plaintext was being repeated, which violates the confidentiality
property desired from the protocol.

-Ben

On 07/28/2016 06:19 AM, R-D intern wrote:
> Hello,
> I am using ECDSA-ECDHE-AES-SHA cipher suite for client -server security.I
> tried understanding the mechanism handshake mechanism. What still quizzes me
> is ; communication between a specific client -server for a specific session
> generates different encrypted text for the same plain text message. What
> leads  to this? Can anybody elaborate?
> Please reply.
> Thanks and regards,
> Suman
>
>
>
> --
> View this message in context: 
> http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Custom Random number generation while in Fips mode

[pratyush parimal]

Hi Thomas,

Thanks for your response! It clears up matters a lot :)

There's one thing that I thought of though -- even though I'm generating
the salt via non-OpenSSL means, the actual function that I'm using for
hashing is "SHA512" from FIPS OpenSSL.
Does the mere usage of salt that was generated via a non-FIPS-recommended
approach violate my compliance ?

I understand what you mean by "I'm not an auditor or a lawyer" , but I'd
still appreciate your opinion / experience in the matter :)

Thanks,
Pratyush.

On Thu, Jul 28, 2016 at 10:23 AM, Thomas Francis, Jr. <
thomas.francis...@pobox.com> wrote:

>
> > On Jul 27, 2016, at 8:18 PM, pratyush parimal <
> pratyush.pari...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I work on a consumer application which is striving to be fips-140-2
> compliant.
> >
> > I'm using OpenSSL as recommended in the fips guide by invoking
> fips_mode_set(). However, in certain parts of the same application, I'm
> using my own non-OpenSSL random number generator to generate salts for
> hashing passwords for the app user accounts(I'm not using RAND_bytes).
> >
> > Does anyone know if using my custom random number generator in this way
> violates the app's fips compliance?
>
> That’s almost certainly a violation.  There might be a few edge cases
> where it is not, but they’re very unlikely.  To determine if you’re even
> close to such cases, ask: Does the RNG I’m using come from another FIPS 140
> validated cryptographic module?  Am I using that module in approved mode?
> Am I using that module according to its security policy?  Do I have
> explicit permission from the customers’ auditors to mix two modules in my
> product?
>
> If the answer to all of those questions is yes, you _might_ be OK, for
> now.  A few auditors (in the past, anyway) considered it OK to mix modules,
> while other auditors say no.  My own reading of FIPS 140-2 is that you may
> not mix modules.  But I’m not an auditor or a lawyer. :)
>
> The other question to ask is: can I clearly explain that the use of the
> non-approved RNG is for non-cryptographic purposes, and easily justify that
> explanation?  Given what you said about why you’re using it, I’m pretty
> sure the answer to that one is “no”. :)  And even if you could, that’s
> still a very weak argument to be making to your customers’ auditors, who
> may decide it’s still not allowed even if they agree it’s for
> non-cryptographic purposes.
>
> > Am I really supposed to be using
> > RAND_bytes for compliance reasons?
>
> Yes.
>
> > Thanks in advance!
> > Pratyush.
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How can I generate an RSA Public Key with OAEP padding?

[Viktor Dukhovni]

> On Jul 28, 2016, at 2:33 AM, Socrates  wrote:
> 
> The question is how can I use openssl command line tool to create a public 
> key using RSAES-PKCS1-v1_5, RSA-OAEP, or RSA-OAEP-256 (paddings?)?

RSA public keys don't have padding, signature and encryption formats have 
padding.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Custom Random number generation while in Fips mode

[Thomas Francis, Jr.]

> On Jul 27, 2016, at 8:18 PM, pratyush parimal  
> wrote:
> 
> Hi all,
> 
> I work on a consumer application which is striving to be fips-140-2 compliant.
> 
> I'm using OpenSSL as recommended in the fips guide by invoking 
> fips_mode_set(). However, in certain parts of the same application, I'm using 
> my own non-OpenSSL random number generator to generate salts for hashing 
> passwords for the app user accounts(I'm not using RAND_bytes).
> 
> Does anyone know if using my custom random number generator in this way 
> violates the app's fips compliance?

That’s almost certainly a violation.  There might be a few edge cases where it 
is not, but they’re very unlikely.  To determine if you’re even close to such 
cases, ask: Does the RNG I’m using come from another FIPS 140 validated 
cryptographic module?  Am I using that module in approved mode?  Am I using 
that module according to its security policy?  Do I have explicit permission 
from the customers’ auditors to mix two modules in my product?

If the answer to all of those questions is yes, you _might_ be OK, for now.  A 
few auditors (in the past, anyway) considered it OK to mix modules, while other 
auditors say no.  My own reading of FIPS 140-2 is that you may not mix modules. 
 But I’m not an auditor or a lawyer. :)

The other question to ask is: can I clearly explain that the use of the 
non-approved RNG is for non-cryptographic purposes, and easily justify that 
explanation?  Given what you said about why you’re using it, I’m pretty sure 
the answer to that one is “no”. :)  And even if you could, that’s still a very 
weak argument to be making to your customers’ auditors, who may decide it’s 
still not allowed even if they agree it’s for non-cryptographic purposes.

> Am I really supposed to be using 
> RAND_bytes for compliance reasons?

Yes.

> Thanks in advance!
> Pratyush.
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] server key exchange use case in ECDSA-ECDHE-AES-SHA

[Salz, Rich]

You have asked two very basic questions about cryptography.  I suggest you 
start doing a literature search; for example, Wikipedia.


--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] server key exchange use case in ECDSA-ECDHE-AES-SHA

[R-D intern]

Hello,
I have used ECDSA-ECDHE-AES-SHA as the cipher suite in my client- server
communication. To use ECDHE key exchange algorithm I used ECDHE parameters
and what I see is an additional server key exchange in my SSL handshake
process. What  does that imply? Does that increase the security strength of
the system?Is it redundant?
Please elaborate  its significance.
Thanks and regards,
Suman




--
View this message in context: 
http://openssl.6102.n7.nabble.com/server-key-exchange-use-case-in-ECDSA-ECDHE-AES-SHA-tp67596.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] different encrypted text for the same plain text message

[R-D intern]

Hello,
I am using ECDSA-ECDHE-AES-SHA cipher suite for client -server security.I
tried understanding the mechanism handshake mechanism. What still quizzes me
is ; communication between a specific client -server for a specific session
generates different encrypted text for the same plain text message. What
leads  to this? Can anybody elaborate?
Please reply.
Thanks and regards,
Suman



--
View this message in context: 
http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How can I generate an RSA Public Key with OAEP padding?

[Socrates]

Hi,

Even though I have used openssl or ssh-keygen for years to generate key pairs 
mainly for SSH purposes, I don't know much about the underlying theory and 
finer details of cryptography.

I want to use JSON Web Encryption (JWE) and there we have this concept of Key 
Encryption. Key Encryption can be done using RSAES-PKCS1-v1_5 or RSA-OAEP or 
RSA-OAEP-256 (c.f. https://tools.ietf.org/html/rfc7518#section-4.2 and 
https://tools.ietf.org/html/rfc7518#section-4.3).

The question is how can I use openssl command line tool to create a public key 
using RSAES-PKCS1-v1_5, RSA-OAEP, or RSA-OAEP-256 (paddings?)?

At the moment, I use the following command to create a PEM file:

openssl genrsa -out example.pem 2048

Then I use the following command to extract the public key:

openssl rsa -in example.pem -pubout example.pub

What padding is used for this public key? How can I specify that I want it to 
be generated with RSAES-PKCS1-v1_5, RSA-OAEP, or RSA-OAEP-256 paddings?

Thanks in advance,
Socrates-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users