As we have seen when dealing about Security, the framework offers
built-in encryption of the content transmitted between its REST client and
server sides, especially via Custom Encodings, or HTTPS.
The later, when using TLS 1.2 and proven patterns, implements state-of-the-art security.
But default mORMot encryption, even if using proven algorithms like AES-CFB-256 and SHA-256, uses symmetric keys, that is the same secret key is shared on both client and server sides.
Once you have generated a public/private pairs of keys, you can perform two functions:
- Authenticate a message originated with a holder of the private key; a certification system should be used to maintain a trust chain of authority;
- Encrypt a message with a public key to ensure that only the holder of the paired private key can decrypt it.
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 proven Open Source library for the raw ECC computation, which was the most sensitive part;
- Existing librairies 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 excluding ECB, 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 -
SynEcclogic 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 may benefits from past issues: we followed all identified best practices, and tried to avoid, from the beginning, buffer overflows, weak protocols, low entropy, low default values, serial collision, forensic vulnerabilities, hidden memory copies, evil optimizations;
- It integrates nicely with other mORMot features, and re-uses the
SynCrypto.pasunit 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 to 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 applications 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 is safer than using the old/unsafe already installed libraries, 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!