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 - 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 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.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 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!

Read the full story in the new dedicated chapter of our documentation.
Feedback is welcome in our forum, as usual.