3
$\begingroup$

We are working on a project in which we will need to encode and encrypt 1 - 1.3 kb worth of data at a time. We need the result of each piece of data to be the same size it was before, or be smaller, or be only slightly bigger. Basically as small as it can be while still being secure and still being able to get the original data back by decrypting and decoding.

If you were doing something like this how would you best approach it? Is there an encryption algorithm that only adds minimal (if any) size compared to the size of the unencrypted data?

This is in JavaScript and will run in browsers.

$\endgroup$
  • 1
    $\begingroup$ Two things (among others) limit security of an encryption scheme: the confidentiality of its decryption key, and the integrity of the encryption software. Both are hard in a JavaScript run in browsers. If you trust the https link to the server, why do you need more encryption than that? If you don't, how do you insure said confidentiality and integrity? $\endgroup$ – fgrieu Apr 3 '18 at 7:08
  • 1
    $\begingroup$ What is your threat model? Since this is going to run in JavaScript in a browser, you are already trusting the network to a high degree. Make sure you are not violating your security objectives, that those goals are clearly defined and are realistic considering your attack tree. $\endgroup$ – Patriot Apr 4 '18 at 12:22
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ – e-sushi Apr 12 '18 at 0:12
  • $\begingroup$ @fgrieu maybe the javascriot runs on browsers on unconnected laptops in separate bank vaults. $\endgroup$ – daniel Apr 13 '18 at 12:09
3
$\begingroup$

A steam cipher does not increase the size of the plaintext, but you need an IV (which then does increase the size) or different key each time, so effectively this doesn’t help. You can get a relatively small increase of size by using AES-GCM with a tag size of 10 bytes and IV of size 12 bytes. So this increases by 22 bytes overall.

If this is too much, then it depends if you can guarantee that the same plaintext never repeats. If yes, then you could use AES-GCM-SIV with a fixed IV and save the IV bytes. Alternatively, if you don’t need authentication, then you can use XTS but this is far from ideal.

In general, an additional 22 bytes for about 1KB is only about 2% overhead so it’s not significant and your best using a full blown authenticated encryption mode.

$\endgroup$
  • 2
    $\begingroup$ You should not use XTS for general purpose file encryption. $\endgroup$ – forest Apr 3 '18 at 11:10
  • 2
    $\begingroup$ Also truncating AES-GCM tags is somewhat risky and should only be considered very carefully (see also SP 800-38D), because security drops off much faster than with eg AES-CCM or AES-EAX. $\endgroup$ – SEJPM Apr 3 '18 at 12:17
0
$\begingroup$

As your data is longer than the usual block size of a cipher, you can use cipher text stealing, which combines the last (partial) block with the second last block in a way that prevents any length expansion.

$\endgroup$

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.