Soter cryptostack
Soter is a cross-platform multipurpose cryptographic library serving Themis as it's backbone. It provides a set of highly secure cryptographic primitives through a well-defined, consistent and simple interface. Some features are: necessary cryptographic primitives for building robust secure solutions with high security level intuitive, well-defined interface to cryptographic functions compile-time support for different (interchangeable) underlying (donor) cryptographic implementations (libraries and platform-specific functions) object-oriented design
Soter does not provide all possible cryptoalgorithms out there. Instead we tried to select the best ones for our cryptosystems (and future features) and provide a simple way to use them even for an inexperienced user. Also, we tried to provide the freedom in choosing underlying cryptographic implementation for each of them. The code is cleanly split into generic part and implementation-(and/or platform-) specific part, so moving the library to different crypto implementation is very easy. Every function can be re-implemented using different cryptographic libraries and compile-time switches are used to select appropriate source files to compile. Thus, every instance of soter library can be tweaked to support any platform-preferred implementation of the algorithms while still providing consistent interface to its users.
Currently, we're using LibreSSL / OpenSSL's libcrypto, but plan to replace it in next releases.
While selecting necessary cryptographic building blocks for our solutions we had following concepts in mind:
- all basic cryptographic operations should be supported (symmetric cryptography, key agreement, digital signatures, data integrity and authentication)
- all algorithms should be open and well established (undergone significant industry review)
- algorithms should use/support latest "state-of-the art" achievements and techniques in information protection
- cryptographic modes of operation should be as most transparent as possible for user and impose little additional overhead
- combination of such primitives should allow information protection with high security level
Choices for cryptographic algorithms
Symmetric encryption
We prefer Advanced Encryption Standard (AES) as our main symmetric encryption algorithm. This algorithm is rather simple, fast and proven to be secure. Also, many platforms currently have hardware support for AES, so our solutions can get additional performance improvement on such platforms.
We are considering ChaCha as another future choice for our solutions as well.
Encryption modes
We prefer using Galois Counter Mode (GCM) as our main cryptographic mode of operation for AES. GCM is a relatively new concept in symmetric cryptography and is a variant of "authenticated encryption" - a mode, which combines information confidentiality, integrity and authentication in one pass. When information is being decrypted, it's integrity and authenticity is verified at the same time. This is not only faster and more convenient, but generally considered more secure as well than just applying encryption and message authentication code separately. Also, key management is easier, since one key is used for encryption and data authentication.
Since GCM mode requires adding (storing, passing) additional message authentication code (MAC), in the end, the size of protected information increases. This behavior may not be desirable or even acceptable for some use-cases, so for such scenarios we use counter mode (CTR) instead. Counter mode does not require original information to be padded and has additional properties that allow implementations to parallel computations of ciphertext. While counter mode does not provide information integrity and authentication functionality, it still ensures high level of confidentiality while having less strict requirements to cryptographic parameters compared to other modes (like CBC).
Digital signatures
We prefer Elliptic Curve Digital Signature Algorithm (ECDSA) as our main digital signature scheme. Elliptic curve-based cryptosystems usually provide higher security levels with smaller keys. As for now, there are no efficient algorithms to break elliptic curve keys out there in public. Also, since keys are much smaller, they are easier to generate and store. The overall computational load is reduced as well.
We also support RSA mainly to provide some level of compability with already established solutions. However, this is a safe "back-up" only.
Key agreement
We prefer Elliptic Curve Diffie–Hellman (ECDH) as our key agreement scheme. Some of the reasons are similar to ECDSA: elliptic curve-based cryptosystems are just better than their "plain" counterparts. Also, much of the elliptic curve implementation is reused (if same or similar cryptographic parameters are used), so most of the code is shared between ECDH and ECDSA.
Diffie-Hellman as well as ECDH are susceptible to man-in-the-middle-attack (MiTM), so we usually combine its usage with strong authentication in our solutions (mostly ECDSA digital signatures) to mitigate such attacks.
Asymmetric encryption
While Soter supports RSA asymmetric encryption we recommend (and prefer to use in our modules) elliptic curve-based cryptosystems. However, there are no direct well-established asymmetric encryption schemes in ECC-based domain. But a simple combination of ECDSA+ECDH can be used to provide similar functionality in two steps:
-
Use peer's public ECDH key and own private ECDH key to compute a shared secret (which will be used to encrypt the message as in RSA encryption).
-
Send own signed ECDH public key to the peer, so he/she can compute the same shared secret and decrypt the message.
This approach even has advantage over RSA encryption: ECDH keys may be random and used only once, which provides perfect forward secrecy (PFS) to overall communication.
Data integrity and authentication
We use SHA-family of algorithms to check data integrity in our solutions. They have been out for a while in public and so far no significant attacks were developed. We prefer using SHA-2 in our schemes (SHA-256 or SHA-512) keeping SHA-1 for compability only.
For data authentication we use GCM mode were applicable (usually combined with encryption). In other cases we use hash-based message authentication code (HMAC). Security level of HMAC mostly depends on security level of underlying hash functions, so in our implementation it is high, since we mostly use SHA-2. Every supported hash function can be used in HMAC as well.