Public-key Asymmetric Cryptography via SynECC

ab · 2016-09-25 07:53:07

Asymmetric encryption, also known as public-key cryptography, uses pairs of keys:
- Public keys that may be disseminated widely;
- Paired with private keys which are known only to the owner.

The framework SynEcc unit features a full asymmetric encryption system, based on Elliptic curve cryptography (ECC), which may be used at application level (i.e. to protect your application data, by signing or encrypting it), or at transmission level (to enhance communication safety).
A full set of high-level features, including certificates and command line tool, offers a stand-alone but complete public-key infrastructure (PKI).

This forum thread is the place to discuss http://blog.synopse.info/post/2016/09/2 … via-SynECC

The associated documentation is http://synopse.info/files/html/Synopse% … l#TITL_187

Feedback is welcome, especially for code or documentation review.
If you have any doubt about the current implementation, please provide some ideas to enhance it!

ab · 2016-09-25 18:20:46

Extracted from the updated documentation:

There will no doubt be criticism of our decision to re-implement a whole public-key cryptography stack from scratch, with its own small choice of algorithms, instead of using an existing library (like OpenSSL), and existing standards (like X509). Here are some reasons:
- We did not start from scratch, since we used another Open Source library for the raw ECC computation, which was the most sensitive part;
- Most existing implementations have to deal with a lot of algorithms, options and old features: we wanted a reduced scope, to ease risk assessment - only well-known and future-proof algorithms were selected (AES-256-CFB, HMAC_SHA256, PBKDF2_HMAC_SHA256, ECDSA, ECIES...) and default values are very aggressive (password strength, 60,000 PBKDF2 iterations...);
- Existing libraries are so complex that interfacing with them makes the consuming code complex to write and maintain - SynEcc logic is implemented in a few dozen lines of code: most of the unit source is about wrapper methods and documentation, and an average programmer can understand and review it, even if he/she is no Delphi expert;
- A new implementation can always benefit from existing past issues: we followed all identified best practices, and tried to avoid, from the beginning, known issues which appeared on previous implementations, like buffer overflows, weak protocols, low entropy, low default values, serial collision, forensic vulnerabilities, evil optimizations;
- It integrates nicely with other mORMot features, and re-use the SynCrypto.pas unit for actual cryptography on all supported platforms, so the development effort was not big, and the resulting executables size did not increase;
- As always, we started by writing tests, and we have pretty good automated tests coverage, from low-level ECC functions up to the highest level (we even validate the ECC command line tool);
- We forbid file stamping, preferred JSON as any other text format, and used fixed sized binary buffers (e.g. for identifiers), with all-inclusive information, to avoid memory copies of sensitive data and logic flows depending on the feature set;
- Some unique features were introduced (like AFSpliting or enforcing passwords for private keys), and in doubt, we always did choose the paranoid solution;
- We are proud that mORMot application are stand-alone executables, so the last thing we want to do is to start mandating DLLs, or be coupled to a specific Operating System;
- Having our own embedded code fight against old/unsafe versions already installed, especially on an existing server (what is the OpenSSL version in your good old Debian VM?);
- It was fun, we learned a lot, and we hope you will enjoy using it, and contribute to it!

edwinsn · 2016-09-26 04:30:39

Arnaud, Well done!

emk · 2016-09-26 06:53:19

That means you can implement a custom wire encryption a-la SSL style - exchange key of symmetric encryption over asymmetric ECC channel? Please, please make this for Delphi clients of mORMot with the impossibility to accept on that port non-encrypted connection - if somebody needs also JS non-encrypted can launch from the same executable another httpServer on another port.

Note: Symmetric key could live in RAM memory for the life of Delphi client, so the costly handshake will be only the first time.

ab · 2016-09-26 07:10:32

Yes, we are willing to introduce asymmetric encryption as a new binary protocol for WebSockets remote access.
We will set a private/public key pair on each WebSockets side (client and server), for mutual authentication.
Or just a private/public key pair on the server side, for server-only authentication (like in most TLS usecase).

It is the next logical thing to do, indeed.

emk · 2016-09-26 08:58:35

If I understand correctly, it will be only for websockets? If yes, that's to bad for me because, I would like to use SOA over websockets, but in current implementation it's only one connection per thread and it's not scalable for thousands of connections.
So, I'll still use "http.sys" http-like connections until so scalable "http.sys" websockets are fully implemented(by the way if you fully implement "http.sys" websockets, you will dust over any framework, including MS ones

Thank you for your wonderful framework and if it's possible please implement a-la SSL encryption also for normal http requests, not only for websocket.

ab · 2016-09-26 13:14:40

I'll try to make it available also for plain HTTP connections.
May be a dedicated encoding...

Idea is to re-use the very same ECDHE-based algorithm for both WebSockets and HTTP.

Note that the http.sys web-socket has its own branch, and is reported to work on production - see http://synopse.info/fossil/timeline?r=WinWebSocket

emk · 2016-09-26 14:43:31

Yes, I know, but Pavel says that mORMot features (SOA, ..) are not implemented yet like for standard websockets. He uses http.sys websockets only for light notification.
I'll be really grateful to access SOA(in request+response style)+mORMot authentication via http.sys websockets.

What I'm saying that other users will be delighted to have standard way of working things and protocol options (http.sys-http, or http.sys-websockets) to be just one parameter in constructor. Think about 5000 cell-phones connected thru websocket and receiving real time updates, or JS applications who respond instantaneous.

mpv · 2016-09-26 19:01:55

BTW my colleagues use a http.sys websockets from branch not only for notifications, but also for live video streaming with WebRTC as a client part.

ab · 2016-09-26 21:56:26

@mpv
This may be interesting to have feedback from them, if we may add this as a framework feature, it may push me to merge everything.

mpv · 2016-09-28 09:53:04

I have a deadline till the end of September. I'll finish my project and when extract the WebRTC part as a sample to Project31WinHTTPEchoServer.dpr form WinWebSocket brunch

oz · 2016-10-18 19:25:31

@mpv:
Any news about about this? I just can't wait to get @ab pushed to merge everything!

igors233 · 2020-09-30 12:43:09

Hi @mpv, could you share more info about video streaming through WebSockets?
I do need something similar and I'm very interested to learn more about it.

mpv · 2020-10-01 10:16:21

@igors233 - it was an experiment from our side. We completely stopped using Windows/http.sys based solutions due to many reasons and switch to Linux on productions. For WebSocket communications we use a RabbitMQ, for Video Chats - Jitsi (https://github.com/jitsi).

mORMot Open Source

#1 2016-09-25 07:53:07

Public-key Asymmetric Cryptography via SynECC

#2 2016-09-25 18:20:46

Re: Public-key Asymmetric Cryptography via SynECC

#3 2016-09-26 04:30:39

Re: Public-key Asymmetric Cryptography via SynECC

#4 2016-09-26 06:53:19

Re: Public-key Asymmetric Cryptography via SynECC

#5 2016-09-26 07:10:32

Re: Public-key Asymmetric Cryptography via SynECC

#6 2016-09-26 08:58:35

Re: Public-key Asymmetric Cryptography via SynECC

#7 2016-09-26 13:14:40

Re: Public-key Asymmetric Cryptography via SynECC

#8 2016-09-26 14:43:31

Re: Public-key Asymmetric Cryptography via SynECC

#9 2016-09-26 19:01:55

Re: Public-key Asymmetric Cryptography via SynECC

#10 2016-09-26 21:56:26

Re: Public-key Asymmetric Cryptography via SynECC

#11 2016-09-28 09:53:04

Re: Public-key Asymmetric Cryptography via SynECC

#12 2016-10-18 19:25:31

Re: Public-key Asymmetric Cryptography via SynECC

#13 2020-09-30 12:43:09

Re: Public-key Asymmetric Cryptography via SynECC

#14 2020-10-01 10:16:21

Re: Public-key Asymmetric Cryptography via SynECC

Board footer