cryptoshred.initVector

[BernhardStreit-rms]

In the spring boot config, you are required to set cryptoshred.initVector.

Can you write a bit more in the documentation about this? For example:

• why is this configured and not randomly chosen at startup?
• what format should it be? any random string? what size?
• is it important that once set, it does never change? Or does not matter? Does it need to be the same value on two different services if they read the same crypto containers?
• Must it be kept as a secret or can be configured in plaintext?

[BernhardStreit-rms]

Also wondering if it's actually insecure to configure a fix initVector, but I'm not that familiar with crypto stuff...

JabRef/jabref#13687

[uweschaefer]

The IV currently is used as a kind of salt. It is supposed to be kept secret and make it harder to guess and also to decrypt, even if you had the encrypted data and a stolen key.
For this reason, the IV is currently not stored with the data.

Yes, the IV might reveal guessable patterns, at least for the first block.

We're currently escalating internally and explore the attack vectors for our usage scenario.
As you might have different ones, it would make sense to add random IVs optionally. We'd need to consider compatibility and/or migration procedures.

Anyway, thx for raising @BernhardStreit-rms

[BernhardStreit-rms]

I'm really not deep in the topic, but what I understand is that using a static IV with the same key (which happens for all events of the same user) makes the encryption deterministic.

This means the same input will always produce the exact same ciphertext.

This is a problem already, as an attacker wouldn't need to decrypt the data to see patterns, like when a normally fix value changed, or if they know or guess certain values (e.g., default values in an initial event, or they know certain values from elsewhere), they could identify those values every time they appear in our database (and track when they change).

Looks like a best practice is to generate a random IV for every single encryption process and prepend it to the ciphertext. The IV doesn't need to be kept secret; its purpose is to ensure that even if we encrypt the same string twice, the resulting ciphertexts look completely different.

This would also be an easy and backward-compatible fix, but most likely you should regenerate your events and encrypt the values stored with the fix IV again, using random ones...

I think it would make sense to fix this and then get a security audit by a security specialist for the code.

[BernhardBln]

@uweschaefer here is a draft

[uweschaefer]

thx, will have a look end of next week.
Did you benchmark the change? How does the change (that probably changes the lifecycle of the cipher?) impact the runtime performance profile?

---

Skimming though, i realized, the lifecycle does not even change, so asking secureRandom for a few bytes is the only thing that should have an (insignificant, for sure) impact.

[uweschaefer]

As it turns out, our security people are not fond of "loosing the IV as a factor". One idea would be to make the iv configuration optional (use a default one in that case) but either way hash the configured value with the secure random and only store the SR to the encrypted record, instead of the resulting IV.
That way, we'd increase the entropy, but keep the configured IV as a secret factor to decrypting.

[BernhardBln]

Did a small benchmark, see

cryptoshred-core/src/test/java/eu/prismacapacity/cryptoshred/core/Benchmark.java

Results

Basis are 100.000 objects to be serialised, with one String crypto container, and 1/3 of the strings had a size of 1.000 chars, 1/3 had a size of 10.000 chars, and 1/3 was 100.000 chars.

Old code (fix iv): Encryption took 15.972ms or 15s

New code (random iv): Encryption took 21.062ms or 21s

So new code is about 1/3 slower, but the average encryption time was 0 ms anyways (maybe should try again in nanos).

So if I break that down from the 100.000, it's an additional extra time of 0,05ms for the iv generation.

[uweschaefer]

Forget that request. I initially was under the assumption that we reused the cipher before. As we did not, there is no relevant change in performance. Sure the secureRandom takes a few cycles, but – as you pointed out – that is even hard to measure.

But thanks for providing it anyway.

[uweschaefer]

We'll need to have another switch to control the behavior when encoding, otherwise an update of a distributed system is not possible without downtime.
Will take care of it.