XtsStream encryption key

Question

Hello,
We are considering XtsStream for encrypting/decrypting data on one end of our two-direction data exchange mechanism (the other would be XTS AES implementation developed on SWIFT). As I see actual key is derivative of some 'password'. Also size of encrypted data is increased by 64 bytes (I guess it's header with size or something). The questions are:
1. Can we set plain symmetric key for encryption/decryption by XtsStream?
2. Can we get the plain encrypted data out or XtsStream to be provided to the other XTS AES implementation given we know the key, block size and data size?

Thanks,
Denis

Answer 1

It seems that you need rather low level of the XTS-AES implementation instead of XtsStream, which is high-level API.

I have made our internal XTS-AES implementation public, so you can use it now like this:

using (var xts = new Rebex.Security.Cryptography.Xts(encryptionKey, tweakingKey))
{
    Console.WriteLine(BitConverter.ToString(plaintext));

    xts.EncryptSector(tweak, plaintext, 0, plaintext.Length, encrypted, 0);

    Console.WriteLine(BitConverter.ToString(encrypted));

    xts.DecryptSector(tweak, encrypted, 0, encrypted.Length, plaintext, 0);

    Console.WriteLine(BitConverter.ToString(plaintext));
}

Please note, that if you want to encrypt (or decrypt) data using more EncryptSector calls, the input sector (data length) should be multiple of the Xts.BlockSize (currently 16 bytes).

Also please note, that the single sector (input for the EncryptSector method) has to be at least Xts.BlockSize bytes long (currently at least 16 bytes).

You can download trial version here.

Update: This has been released with Rebex Security 2018 R1.

Comments

We have the same need -- namely to pass an encryption key (not the password) to XtsStream. Our application must guarantee that the key is derived from the password in a certain specific way (e.g., min 10k+ RFC2898 iterations, etc). Are you planning to natively support taking encryption key as an argument to XtsStream (e.g. by adding an additional constructor that takes the key) or are we expected to use the low level APIs which defeat the purpose of XtsStream?

---

For key derivation we are using PBKDF2 RFC2898 with 1000 iterations and salt of random 40 bytes, which are stored in first 40 bytes in the stream. Would it be enough for you if we add setting to specify number of iterations?

What are your other specific needs? We would prefer to add such things into Settings instead of accepting raw keys.

---

A configurable number of RFC2898 iterations (for cryptographic key derivation) is currently the only password->key transformation parameter we use (in addition to random salt). The number of 1000 that is mentioned by the RFC (dated 15 years ago) is no longer considered secure (presumably) - hence the need for more iterations. In any case, your proposed design (i.e., using Settings) will work. Thanks.

---

OK, we will add this to Settings and send you beta version ASAP.

However, 1000 iterations is not the security problem. The problem is size of keys and length of password.
E.g. using 10.000 iterations is insecure when used password of length 3 bytes or key size 64 bits. On the other hand, using 10 iterations is perfectly secure when used password of length 20 bytes and key size 256 bits.

---

You can try the beta build with XtsSettings.Iterations added. It is available at https://www.rebex.net/getfile/0873cf79b02f4099b43ec32845f8cdda/RebexSecurity-BetaBuild6671-Trial-Binaries.zip

If you have already purchased Rebex library and want to receive full version, please contact us at support@rebex.net.

---

P.S: default key size is 128 bits. You can increase it to 192 or 256 bits using XtsSettings as well.