1
$\begingroup$

I want to end-to-end encrypt items in a stateless environment. These items have an identifier (random string). Now I want to add encryption by adding a random key. The URL could be https://server.tld/item#key which users can share with each other.

I want to only use Web Crypto API (SubtleCrypto) without any additional libraries.

My idea so far:

Now I need an iv. I thought about using the hash of the item identifier via window.crypto.subtle.digest(). However AES-CBC needs 16 bytes.

Is it a good idea to use the first 16 bytes of SHA-1 (20 bytes long) as IV?

Improve this question
$\endgroup$
  • 1
    $\begingroup$ Why not just add a random IV in the URL? I.e. for example have the URLs be https://server.tld/item#key$iv. $\endgroup$ – dsprenkels Jun 18 '20 at 16:14
1
$\begingroup$

Is it a good idea [from a security perspective] to use the first 16 bytes of SHA-1 (20 bytes long) as IV?

It depends.

For CBC, the main requirements is the IV are that it should be unpredictable for the attacker. In particular, you should never ever use the same IV more than once for encrypting messages under the same key.

This implies that, in your system, it should be impossible to edit or overwrite these items. If editing an item is ever possible, then deriving the IV from the item identifier is definitely a bad idea.

If you want to support the editing of items, you should always generate a (pseudo-random) IV. (I.e. it should not be predictable for an attacker.)

Improve this answer
$\endgroup$
  • $\begingroup$ The specific use case is a minimalistic pad. The point is about editing and sharing a piece of text. The URI must not change to keep it usable. While only one version is available at a point of time, an attacker might record multiple versions. So you say that there is no secure way of encoding the IV in the URI, but instead the document format must be changed to include the IV (e.g. prepend)? Or do you see any other simple solution (keep in mind that the whole app is less than 3kB even without minification)? $\endgroup$ – darkdragon Jun 18 '20 at 17:16
  • $\begingroup$ Yes. The point is that the IV should change every time the piece of text is encrypted with the same key. I suppose you are storing the ciphertext on the server. Then you could also store the IV on the server, right? $\endgroup$ – dsprenkels Jun 19 '20 at 9:14
  • $\begingroup$ I am prepending it to the ciphertext. See my pull-request for the implementation. It would be awesome if you could have a look. $\endgroup$ – darkdragon Jun 19 '20 at 17:15
  • $\begingroup$ It doesn't have to look random? Is there a reason why that should apply for CBC mode encryption as stated in the question? $\endgroup$ – Maarten Bodewes♦ Jun 22 '20 at 22:47
  • 1
    $\begingroup$ For CBC mode the IV is required to be unpredictable by an adversary, and CBC mode is named explicitly in the question. "Unpredictable" in this case basically means pseudo-random. $\endgroup$ – Maarten Bodewes♦ Jun 23 '20 at 11:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.