2
$\begingroup$

Sorry if this is a duplicate but, to be honest, I don't even know how to search for an answer to it.

I'm working in an environment in which I cannot use streams to encrypt data (React Native using the react-native-aes-crypto module).

Unlike Java where I can use something like cipher.update(buffer) (where cipher is an javax.crypto.Cipher instance) here, I will have to encrypt each part individually.

What I'm concerned about is the inner workings of AES.

Does it encrypt each block using the result of the previously encrypted one ?

Does it deals with blocks based on their length and the key's length (I'm pretty sure that is the case, from what I've read, it adds some padding if the data to be encrypted does not match exactly) ?

My foremost concern is with the power of the encryption. Does it make a difference if I encrypt something in chunks or all at once ?

My second concern is with decrypting. Do I have to use the same size of chunks when I decrypt the data ?

$\endgroup$
4
  • 2
    $\begingroup$ I think you should first look up Modes of Operation in AES - en.wikipedia.org/wiki/Block_cipher_mode_of_operation $\endgroup$
    – user93353
    Commented Dec 6, 2022 at 0:35
  • $\begingroup$ @user93353 Thanks for the suggestion. I've skimmed that article and it seems that what I'm looking for is a mode that is parallelizable. For example CBC will not work for what I'm trying to do. And yes, most modes use padding. I will have to figure out how to deal with that. $\endgroup$
    – Titus
    Commented Dec 6, 2022 at 8:56
  • 2
    $\begingroup$ CTR mode is parallelizable $\endgroup$
    – user93353
    Commented Dec 6, 2022 at 14:21
  • 1
    $\begingroup$ From an application's perspective, when (a) every chunk of data to encrypt is exactly 16 bytes AND (b) every chunk has a unique value unique AND (c) only the confidentiality (not integrity) of the data chunks matter, then one can encrypt "chunks using the AES algorithm". In every other case, AES alone is inappropriate. In fact, for most practical applications (c) does not hold after a sound analysis, thus not only can't we use AES alone, but we need authenticated encryption and can't use AES-CTR, AES-CBC, AES-CFB, AES-OFB alone. $\endgroup$
    – fgrieu
    Commented Dec 7, 2022 at 14:06

1 Answer 1

2
$\begingroup$

What I'm concerned about is the inner workings of AES. Does it encrypt each block using the result of the previously encrypted one ?

No. AES is a block cipher. It ciphers a plaintext block using a key, and it generates a single ciphertext block. Note that in itself AES is not secure: it leaks information about the identity of the blocks; e.g. if you feed it the same plaintext block twice then it will generate the same ciphertext, which leaks information to any adversary which is able to eavesdrop.

In some modes such as the venerable CBC mode the encryption depends on the previous block. In that case the cipher is called plaintext aware; i.e. it depends on the previous plaintext and thus ciphertext block. This means that the cipher is also hard to parallelize for encryption as this dependency propagates all through the cipher mode.

Does it deals with blocks based on their length and the key's length (I'm pretty sure that is the case, from what I've read, it adds some padding if the data to be encrypted does not match exactly) ?

It only handles blocks of 128 bits / 16 bytes. The key length of 128, 192 or 256 bits does not directly influence the block size. It is somewhat useful to have a key size that is a multiple of the block size because otherwise it becomes tricky to encrypt / wrap keys with another key. This is one of the reasons to not use 192 bit AES. Some ciphers even allow for variable key sizes and multiple block ciphers. Actually AES is the Rijndael cipher, and Rijndael does allow additional block and key sizes.

The padding is required for the mode of operation of the block cipher. It only depends on the block size of the block cipher algorithm; the padding would remain exactly the same for any other block cipher that operates on 128 bit blocks. Most modes, including the popular AES-CTR and authenticated AES-GCM modes do not use padding at all. Basically it is only used for ECB, CBC and some related block cipher modes (PCBC). The reason why people think that padding is always necessary is the ubiquity of CBC mode - although even CBC can use ciphertext stealing to avoid it.

My foremost concern is with the power of the encryption. Does it make a difference if I encrypt something in chunks or all at once ?

In principle the power is mainly consumed within the block cipher. So the mode of operation doesn't really matter. If you use an authenticated cipher or HMAC then you generally need to pass the plaintext or ciphertext twice, which will of course increase the power consumption.

It depends on the API, but it might be that the latency increases if you have to perform multiple calls to an underlying AES implementation.

My second concern is with decrypting. Do I have to use the same size of chunks when I decrypt the data ?

No. The output of a block cipher mode of operation is well defined. How you chunk the data is entirely up to you. Obviously, for the block cipher mode of operation you have no choice: it is either 16 bytes or a multiple of 16 bytes if multi-block encryption (basically the insecure ECB mode) is supported. Most lower level API's will only buffer up to the block size internally.

ECB can be used to directly encrypt multiple consecutive counter values, in case the CTR mode is not directly available.

$\endgroup$
4
  • 1
    $\begingroup$ Thanks. To be honest, when I've posted the question, your answer will not make that much sense to me but, since then, I've did some research and I think I understand what you're saying. There are some AES modes that don't use the previous block to encrypt the current one and if there is padding in the mode that I use, I can chunk the data in such a way that none of the chunks (maybe just the last one) will require padding. $\endgroup$
    – Titus
    Commented Dec 7, 2022 at 15:39
  • 1
    $\begingroup$ I've just got started with React Native and the most suggested package for AES encryption is react-native-aes which is not that flexible. I come from programming language where you deal with large files using streams so I think I will end up creating my own React Native package to do what I need. $\endgroup$
    – Titus
    Commented Dec 7, 2022 at 15:41
  • 1
    $\begingroup$ On comment #1: Those modes of operation are not particular to AES, they are cipher schemes that use any block cipher to create a secure cipher for any message size. The AES algorithm, as described by NIST doesn't contain any "modes". In other words, AES is a configuration option for the mode rather than the other way around (Java's AES/CBC/PKCS5Padding should have been named CBC/AES/PKCS7Padding). Yes, you got the padding correct. $\endgroup$
    – Maarten Bodewes
    Commented Dec 7, 2022 at 17:05
  • 1
    $\begingroup$ Many higher level API's have one of those disgusting "higher level" libraries. They are usually terrible pieces of shit and react-native-aes is no exception. Creating a better one could be a good idea, but please don't distribute it as generic library, make it specific to your use case instead. Post a comment here if you need an API review, because this is easy to get wrong. Note that the "native" Java code probably already uses intrinsics, so there may be no need to go - uh - more native than that. $\endgroup$
    – Maarten Bodewes
    Commented Dec 7, 2022 at 17:12

Your Answer

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

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