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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

Dr. 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).


-------- Forwarded Message --------
Subject: [saag] Standard Crypto API + Symmetric Crypto At Rest
Date: Sat, 7 Nov 2015 22:30:35 +0900
From: Massimiliano Pala [hidden email]
Organization: OpenCA Labs
To: [hidden email] [hidden email]

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:


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!


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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev