[openssl-users] Fwd: [saag] Standard Crypto API + Symmetric Crypto At Rest

[Massimiliano Pala]

Hi OpenSSL Community,

I originally posted this message on the security area ML at IETF and I 
am trying to reach out to a broad audience of experts, implementers, and 
vendors. I would love to have contributions and implementations (once we 
have some initial specs) around this initiative. I am still trying to 
find the right host for the mailing list where to discuss all aspects of 
this initiative, but I hope that this message will spark some interest 
and (especially from one of the most vibrant crypto library community 
out there) possibly inspire the community to join the envisioned effort.


Any comments and feedback are welcome (positive and negative alike).

Cheers,
Max

 Forwarded Message 
Subject:[saag] Standard Crypto API + Symmetric Crypto At Rest
Date:   Sat, 7 Nov 2015 22:30:35 +0900
From:   Massimiliano Pala 
Organization:   OpenCA Labs
To: s...@ietf.org 



Hi all,

I am not sure this is the right place to write this e-mail, but I hope
is. At the meeting I spoke with several people about an idea I had some
time ago but never landed at IETF. Since I got positive feedback and
suggestion to post the idea to this list to see if others might be
interested, here's the summary e-mail.

The idea is very simple: provide specifications for interfaces to
cryptographic libraries. The basic idea is to provide an API that
different vendors can implement on top of their libraries to provide a
standard interface for applications. If successful, an application could
make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that
provides that interface without having to re-write the crypto-related
code. This allows for portability (wider adoption of crypto-enabled
applications), code/modules re-usability, and the possibility for
applications to switch between vendors (e.g., switching to a better
crypto library or dismissing a library that has shown vulnerabilities).

Although I received positive feedback about the idea (I know, it has be
attempted in the past.. ), I was never able to get the green light to
proceed with a proposal for IETF (unfortunately the answer was always
"we don't do APIs" ... which, actually, it is not true), so I decided to
move forward anyway, since it is a real pain that needs to be solved. If
the IETF will like to pick up the work in the future, great. If not,
we'll solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing
specs, participating in the discussion, provide feedback, or writing
code) please contact me and we'll take it from there. I wrote a couple
of pages today (very quick and dirty work for now.. so.. don't judge!),
but I hope we'll be able to gather momentum and work together on this.
The website is reachable at:

http://cryptoapi.openca.org/

Last but not least - I am starting also another project that targets the
use of SYMMETRIC crypto by providing support for encryption at rest.
This library will provide support for storing encrypted data, signed
(hmac) data, symmetric keys, and symmetric keys bundles (stack of keys)
in such a way that it is simple to use (e.g., dealing with symmetric
crypto is hard for the average developer since not much support, outside
TLS, is provided). By defining a simple high-level API for symmetric
crypto we want to fill the gap and, hopefully, increase the use of
crypto also in those environment where asymmetric is not an option
(e.g., latency constraints). The idea is to actually write a standard
for symmetric crypto ... "at rest".

Also for this project, please contact me directly (I still do not have
pages for this project for various reasons - most importantly I still
have to see if I get to open source what I did for my employer of if we
have to start from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions
to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the
PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the
Public Key (Discovery) System (PKS).


  



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

Re: [openssl-users] Fwd: Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d?

[Matt Caswell]

On 11/11/15 15:32, Paul Hebert wrote:
> Hello,
> 
> After long delays with the client vendor (rhymes with 'Big Red'), I
> finally have a packet capture detailing the failing two-way
> authentication TLS 1.2 protocol exchanges - our handshake begins at
> packet 199 and proceeds with packet 214 being sent from the Apache
> 2.2.29/OpenSSL 1.0.2d server at 136.223.23.16 sending a bad
> ChangeCipherSpec record (I've attached packet excerpts from a failing
> two-way client and server auth session).  It looks like our server is
> sending a {ChangeCipherSpec, Finished} record - but the ChangeCipherSpec
> shows a length of 25 (19 hex) which causes the client to respond with an
> Alert (97).
> 
> Any suggestions you can provide would be appreciated?

The key point here is that this is a *renegotiation* handshake. You can
see this from the "Hello Request" coming from the server at the start of
your handshake. TLS record headers are always sent in the clear, but the
payload will be encrypted for all records after the CCS in the first
handshake. Whilst in an initial handshake you would expect a CCS length
of 1 the encrypted length in a renegotiation will be dependant on the
ciphersuite selected (e.g. MAC sizes, IVs, padding etc). In fact I just
had a look at a default s_server->s_client connection (which negotiated
ECDHE-RSA-AES256-GCM-SHA384), and the CCS length was indeed 25 (correctly).

You can see this in some of the other records in your trace. For example
the alert coming from the client has a length of 26 instead of 2 for an
unencrypted alert.

The client is failing with an alert of "Illegal Parameter". You need to
find out what parameter it is choking on, although my guess is, given
where it is in the handshake, that the client doesn't like the verify
data provided in the Finished message. That's quite tricky to pin down
because it essentially means that the handshake hashes differ for some
reason.

Does this happen for all handshakes or only some? Does it only ever
happen with a reneg handshakes (an initial handshake will be easier to
diagnose)? Are you only ever talking to one type of client or are there
others (and do the others work)? What ciphersuite is being negotiated?
Does it work with other ciphersuites?

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

[openssl-users] (2013) : PKCS12 keystore creation failing in fips mode (RT3515)

[jonetsu]

Hello,


There is a thread in 2013 (30 May 03:15) in which Steve writes that OpenSSL 
1.0.1 has a bug regarding the use of PKCS12 in FIPS mode since it tries to 
handle a certificate using a non-FIPS component.  I think I found the commit 
that fixes this, although it is part of a quite huge commit of 33,065 lines 
(7e1b7485706c2b11091b5fa897fe496a2faa56cc) done earlier this year.  


There is perhaps a simpler commit that fixes only this issue 
(92830dc1ca0bb2d12bf05a12ebb798709595fa5a) although I can't see the commit in 
the git tree I have fetched last week, even by branching to 
remotes/origin/OpenSSL_1_0_1-stable.


We are using 1.0.1.e.  My question is, was bug RT3515 included in a later 1.0.1 
release ?  If so, which one ?


(If you can also clear up why the patch is not seen... :)


Much appreciated, thanks.



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

Re: [openssl-users] Elliptic curves approved or recommended by government

[Alex Chen]

Thanks for the reply Jakob.  Is there a mapping in the government's 
elliptic curve names to the names in OpenSSL?
For instance, the API EC_KEY_new_by_curve_name( int nid ) takes an id of 
the EC name where the id can be something like
NID_X9_62_prime256v1, NID_X9_62_prime239v3, etc. that are defined in 
ob_jmac.h.
What I would like to know is how the names are related to NIST's 
recommendation list?

Is there a convention?

Thanks

On 11/11/2015 1:08 PM, Jakob Bohm wrote:

On 11/11/2015 21:02, Alex Chen wrote:
I see there is a list of recommended list by NIST in 
http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, 
but it is very old (1999)
Is there a up to date list of elliptic curves approved or recommended 
for government use in OpenSSL?

Is NID_X9_62_prime256v1 the strongest?

First of all, it depends on *which government*, NIST is for
the USA Government only, though some allied countries may have
copied their decisions.

Secondly, since ca. 1999, the official list has been mostly
unchanged, namely those that are listed in the official NIST
standard FIPS 186-2 for use with ECDSA and in NIST Special
publication SP 800-56A for ECDH.

So far, the public adjustments have been:

2005: The official Suite B list of ciphers was published and
 included the P-256 and P-384 bit curves as minimum.
  Around the same time they made a secret Suite A list of
 ciphers for stuff more secret than "top secret".
2015: NSA announced that they will soon start work on a new
 list, and that government departments should not waste
 taxpayers money doing the upgrade to Suite B just a few
 years before it becomes obsolete.
  However for use at this time they recommend P-384 or
 3072 bit RSA/DH as a good minimum while accepting the
 next step down (P-256 or 2048 bit RSA/DH) in already
 built systems.
  They also recommend the use of pure symmetric key
 solutions with strong (256 random bits) keys as the best
 current solution where possible.

The (non-classified) current official advice can be read at

https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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


___
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] Elliptic curves approved or recommended by government

[Alex Chen]

I see there is a list of recommended list by NIST in 
http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, but 
it is very old (1999)
Is there a up to date list of elliptic curves approved or recommended 
for government use in OpenSSL?

Is NID_X9_62_prime256v1 the strongest?

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

Re: [openssl-users] Elliptic curves approved or recommended by government

[jonetsu]

In the NSA page referred above, the p-384 curves are specifically mentioned
for DH.  These would be the ones covered by the Suite B NSA license
sub-licensed to OpenSSL, are they ?  Is it possible to build OpenSSL in FIPS
in such a way that only these curves will be used ?

Regards.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Elliptic-curves-approved-or-recommended-by-government-tp60944p60946.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] Elliptic curves approved or recommended by government

[Jakob Bohm]

On 11/11/2015 21:02, Alex Chen wrote:
I see there is a list of recommended list by NIST in 
http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, 
but it is very old (1999)
Is there a up to date list of elliptic curves approved or recommended 
for government use in OpenSSL?

Is NID_X9_62_prime256v1 the strongest?

First of all, it depends on *which government*, NIST is for
the USA Government only, though some allied countries may have
copied their decisions.

Secondly, since ca. 1999, the official list has been mostly
unchanged, namely those that are listed in the official NIST
standard FIPS 186-2 for use with ECDSA and in NIST Special
publication SP 800-56A for ECDH.

So far, the public adjustments have been:

2005: The official Suite B list of ciphers was published and
 included the P-256 and P-384 bit curves as minimum.
  Around the same time they made a secret Suite A list of
 ciphers for stuff more secret than "top secret".
2015: NSA announced that they will soon start work on a new
 list, and that government departments should not waste
 taxpayers money doing the upgrade to Suite B just a few
 years before it becomes obsolete.
  However for use at this time they recommend P-384 or
 3072 bit RSA/DH as a good minimum while accepting the
 next step down (P-256 or 2048 bit RSA/DH) in already
 built systems.
  They also recommend the use of pure symmetric key
 solutions with strong (256 random bits) keys as the best
 current solution where possible.

The (non-classified) current official advice can be read at

https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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

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

[openssl-users] No TLS Extended Master Secret Extension (RFC7627) support yet?

[Igor Sverkos]

Hi,

today I read [1] that Microsoft finally added support for TLS Extended
Master Secret Extension to their SSL implementation (SChannel).

The author was so kind to provide a test script [2] to check if your
own servers support TLS Extended Master Secret extension yet.

Looks like my servers don't support TLS Extended Master Secret
extension yet. This lead me to the question when OpenSSL will add
support for this extensions or if it is my fault. I am using

  nginx/1.9.6 build against OpenSSL 1.0.2d 9 Jul 2015

from source.

Looks like there was already a contribution [3] which was already
reviewed in some ways [4].

Any status update would be nice.


[1] 
http://www.tripwire.com/state-of-security/security-data-protection/security-hardening/tls-extended-master-secret-extension-fixing-a-hole-in-tls/

[2] https://github.com/Tripwire-VERT/TLS_Extended_Master_Checker

[3] 
https://github.com/alfredopironti/openssl/commit/5339db9ec81727456f7edb86aab186e7deefe819

[4] 
http://openssl.6102.n7.nabble.com/PATCH-Fix-for-Triple-Handshake-attacks-via-extended-master-secret-td50058.html


Regards,
Igor
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format

[Wim Lewis]

On Nov 9, 2015, at 3:46 PM, Peter P.  wrote:
> I'm writing an application using Openssl 1.0.2d where I am trying to take a 
> DER encoded unsigned CSR and read it into an X509_REQ data structure via the 
> d2i_X509_REQ_bio() function. This function errors out during when I attempt 
> to read in my unsigned CSR and I would like to know if there is any other way 
> to read in an unsigned CSR into an X509_REQ data structure.

A CSR (from PKCS#10 / RFC2986) has the structure:

   SEQUENCE { CertificationRequestInfo, AlgorithmIdentifier, BIT STRING }

where the actual request is the CertificationRequestInfo, and the signature is 
composed of the AlgorithmIdentifier + BIT STRING.

Are you trying to just read in a bare CertificationRequestInfo structure? I 
suspect you can do that with a call like

ASN1_item_d2i_bio(ASN1_ITEM_rptr(X509_REQ_INFO), bp, req)

which is the same as the body of d2i_X509_REQ_bio(), but with X509_REQ replaced 
by X509_REQ_INFO. I haven't tried it, though.

(Whether it's a *good idea* to pass bare CSR info structs around is another 
question but I'll leave that up to you.)


Wim.

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

Re: [openssl-users] No TLS Extended Master Secret Extension (RFC7627) support yet?

[Matt Caswell]

On 11/11/15 21:53, Igor Sverkos wrote:
> Hi,
> 
> today I read [1] that Microsoft finally added support for TLS Extended
> Master Secret Extension to their SSL implementation (SChannel).
> 
> The author was so kind to provide a test script [2] to check if your
> own servers support TLS Extended Master Secret extension yet.
> 
> Looks like my servers don't support TLS Extended Master Secret
> extension yet. This lead me to the question when OpenSSL will add
> support for this extensions or if it is my fault. I am using
> 
>   nginx/1.9.6 build against OpenSSL 1.0.2d 9 Jul 2015
> 
> from source.
> 
> Looks like there was already a contribution [3] which was already
> reviewed in some ways [4].
> 
> Any status update would be nice.

Extended Master Secret support is already merged into the current git
master branch. It will be supported in our forthcoming 1.1.0 release.
Our current release schedule puts this as being released on 28th April 2016:

https://www.openssl.org/policies/releasestrat.html


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

Re: [openssl-users] Elliptic curves approved or recommended by government

[Matt Caswell]

On 11/11/15 20:53, jonetsu wrote:
> In the NSA page referred above, the p-384 curves are specifically mentioned
> for DH.  These would be the ones covered by the Suite B NSA license
> sub-licensed to OpenSSL, are they ?  Is it possible to build OpenSSL in FIPS
> in such a way that only these curves will be used ?

OpenSSL 1.0.2 has Suite B support. It can be configured via the cipher
list. See SUITEB128, SUITEB128ONLY, SUITEB192 here:

https://www.openssl.org/docs/man1.0.2/apps/ciphers.html

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