Seald: documentation

English

Français

English

Français

Cryptographic mechanisms ​

Here you will find a brief definition of the cryptographic mechanisms used by Seald.

Their implementation used in Seald is SSCrypto.

Randomness generation ​

Depending on the target environment, different random generators are used:

Asymmetric key pair generator ​

The keys used are of type RSA (see RFC 8017).

Depending on the target environment, different asymmetric key pair generators are used:

Symmetric encryption ​

To encrypt symmetrically, two algorithms are used to ensure both confidentiality and integrity: an encryption scheme that provides confidentiality only, and a MAC to ensure integrity.

Sizing ​

Two symmetric keys are used

  • a 256-bit encryption key noted encryptionKey;
  • a 256-bit key for the MAC, noted authenticationKey.

Their concatenation in this order is noted messageKey.

Lifetime ​

Keys are used for an indefinite period of time for the data they protect.

Encryption ​

Symmetric encryption of clearText with a messageKey (concatenation of encryptionKey and authenticationKey) to obtain cipheredMessage is done as follows

  • generation of a random initialization vector denoted iv of 128 bits;
  • encryption:
  • MAC:
    • algorithm: HMAC-SHA-256 (see RFC 6234 §8.3);
    • argument (message_array in RFC 6234): the concatenation of iv and cipherText;
    • key (key in RFC 6234): authenticationKey;
    • result: hmac;
  • return: cipheredMessage which is the concatenation of iv, cipherText, and hmac.

Decryption ​

Symmetric decryption of cipheredMessage (concatenation of iv, cipherText, and hmac) with a messageKey (concatenation of encryptionKey and authenticationKey) to obtain clearText is done as follows:

  • MAC:
    • algorithm: HMAC-SHA-256 (see RFC 6234 §8.3);
    • argument (message_array in RFC 6234): the concatenation of iv and cipherText;
    • key (key in RFC 6234): authenticationKey;
    • result: hmac;
  • comparison of hmac with hmac2, if equal continue;
  • decryption:
  • return clearText.

Envelope ​

When using the SDK, cipheredMessage is put in an envelope format:

Implementation ​

The implementation used depends on the target environment;

Asymmetric cryptography ​

The keys used are of type RSA (see RFC 8017).

One pair of keys is reserved for encryption operations, another for signature operations.

Sizing ​

The keys are generated with a modulus n of 4096 bits and a public exponent e of 65537.

Lifetime ​

These keys are generated for a duration not exceeding 157680000 seconds (5 years), with a default lifetime of 94608000 seconds (3 years).

Asymmetric encryption ​

The asymmetric encryption of a clearText with a public key (n,e) given to obtain cipheredMessage is performed as follows

  • computing a checksum of type CRC32 (see POSIX.1-2017 §chksum) on clearText to give crc32 of length 32 bits;
  • encryption:
    • RSAES-OAEP algorithm (see RFC 8017 §7.1.1) with the following parameters:
      • SHA1 as the hash function
      • MGF1-SHA1 (see RFC 8017 §B.2.1) as the mask generation function
      • the L label left empty
    • argument (noted M in RFC 8017 §7.1.1): concatenation of crc32 and cleartext
    • key used (noted (n,e) in RFC 8017 §7.1.1): public key of the recipient
    • result `cipheredMessage
  • return: cipheredMessage

TIP

The use of SHA-1 as a hash function in RSAES-OAEP is robust and compliant with RGS v2.0 (see §B1.2.2.2), even considering that collisions are possible. For more information, see What Hashes Make RSA-OAEP Secure?.

Asymmetric decryption ​

Asymmetric decryption of a cipheredMessage with a private key denoted K given to obtain clearText is performed as follows:

  • decryption:
    • RSAES-OAEP algorithm (see RFC 8017 §7.1.2) with the following parameters:
      • SHA1 as the hash function;
      • MGF1-SHA1 (see RFC 8017 §B.2.1) as mask generation function;
      • the L label left empty;
    • argument (noted C in RFC 8017 §7.1.2): concatenation of crc32 and cleartext;
    • key used (noted K in RFC 8017 §7.1.2): private key of the recipient;
    • result decipheredMessage;
  • decompose decipheredMessage into crc32 and clearText;
  • compute a checksum of type CRC32 (see POSIX.1-2017 §chksum) on clearText to give crc32-2 of length 32 bits;
  • compare crc32 and crc32-2, if equal continue;
  • return: clearText.

Signature ​

The production of a signature signature of a textToSign using a private key denoted K is performed as follows:

  • signature:
    • RSASSA-PSS algorithm (see RFC 8017 §8.1.1), using in the first step the EMSA-PSS encoding (see RFC 8017 §9.1.1) with the following parameters:
      • SHA256 as the hash function;
      • MGF1(see [RFC 8017 §B.2.1](https://tools.ietf.org/html/rfc8017)) withSHA256` as the hash function;
      • sLen: the maximum length worth 478 bytes given the chosen hash function and the length of the chosen key module;
    • argument (noted M in RFC 8017 §8.1.1): textToSign;
    • key used (noted K in RFC 8017 §8.1.1): Private key of the signer;
    • result: signature;
  • return: signature.

Signature verification ​

Verification of a signature signature of a textToSign using a public key denoted (n,e) associated with the private key K used to sign is performed as follows:

  • signature verification:
    • RSASSA-PSS algorithm (see RFC 8017 §8.1.1), using in the first step the EMSA-PSS encoding (see RFC 8017 §9.1.1) with the following parameters:
      • SHA256 as the hash function;
      • MGF1 (see RFC 8017 §B.2.1) with SHA256 as the hash function;
      • sLen: the maximum length worth 478 bytes given the chosen hash function and the length chosen for the key module;
    • arguments:
    • key used (noted (n,e) in RFC 8017 §8.1.2): signer's public key;
    • result: boolean signatureIsValid indicating if the signature is valid for the message;
  • return: signatureIsValid.

Implementation ​

The implementation used depends on the target environment;

Key derivation ​

Deriving a key from a passphrase and a salt to obtain key is done as follows

  • derivation:
    • algorithm: SCrypt, with the following parameters:
      • N: 16384;
      • r: 8;
      • p: 1;
      • output size: 64 bytes;
    • arguments: passphrase and salt given;
    • result: key;
  • return: key.

Implementation ​

The implementation used depends on the target environment;