4
$\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.

Improve this question
$\endgroup$
4
  • 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, 2018 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, 2018 at 12:22
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – e-sushi
    Apr 12, 2018 at 0:12
  • $\begingroup$ @fgrieu maybe the javascriot runs on browsers on unconnected laptops in separate bank vaults. $\endgroup$
    – daniel
    Apr 13, 2018 at 12:09

2 Answers 2

Reset to default
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.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ You should not use XTS for general purpose file encryption. $\endgroup$
    – forest ♦
    Apr 3, 2018 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, 2018 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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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