20142019 Ericsson AB. All Rights Reserved. The contents of this file are subject to the Erlang Public License, Version 1.1, (the "License"); you may not use this file except in compliance with the License. You should have received a copy of the Erlang Public License along with this software. If not, it can be retrieved online at http://www.erlang.org/. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. New and Old API Hans Nilsson 2019-08-22 A new_api.xml

This chapter describes the new api to encryption and decryption.

Background

The CRYPTO app has evolved during its lifetime. Since also the OpenSSL cryptolib has changed the API several times, there are parts of the CRYPTO app that uses a very old one internally and other parts that uses the latest one. The internal definitions of e.g cipher names was a bit hard to maintain.

It turned out that using the old api in the new way (more about that later), and still keep it backwards compatible was not possible. Specially as more precision in the error messages was wanted it could not be combined with the old standard.

Therefore the old api (see next section) is kept for now but internally implemented with new primitives.

The old API

The old functions - not recommended for new programs - are:

block_encrypt/3 block_encrypt/4 block_decrypt/3 block_decrypt/4 stream_init/2 stream_init/3 stream_encrypt/2 stream_decrypt/2

They are not deprecated for now, but may be in a future.

The new API

The new functions for encrypting or decrypting one single text in one binary are:

crypto_one_time/4 crypto_one_time/5 crypto_aead/6 crypto_aead/7

The crypto_aead functions are for the ciphers of mode ccm or gcm, and for the cipher chacha20-poly1305.

For repeated encryption or decryption of a text divided in parts, where the parts are handled one by one but in sequence, the functions are:

crypto_init/4 crypto_init/3 crypto_update/2

The crypto_init initialies a cipher operation and one or more calls of crypto_update does the acual encryption or decryption. Note that AEAD ciphers can't be handled this way due to their nature.

Finally, for repeated encryption or decryption of a text divided in parts where the same cipher and same key is used, but a new initialization vector (nounce) should be applied for each part, the functions are:

crypto_init_dyn_iv/3 crypto_update_dyn_iv/3

An example of where those functions are needed, is when handling the TLS protocol.

Examples of crypto_init/4 and crypto_update/2

Encrypting two blocks:

1> crypto:start(). ok 2> Key = <<1:128>>, 2> IV = <<0:128>>, 2> StateEnc = crypto:crypto_init(aes_128_ctr, Key, IV, true). % encrypt -> true #Ref<0.3768901617.1128660993.124047> 3> crypto:crypto_update(StateEnc, <<"First bytes">>). <<67,44,216,166,25,130,203,5,66,6,162>> 4> crypto:crypto_update(StateEnc, <<"Second bytes">>). <<16,79,94,115,234,197,94,253,16,144,151,41>> 5> 5> StateDec = crypto:crypto_init(aes_128_ctr, Key, IV, false). % decrypt -> false #Ref<0.3768901617.1128660994.124255> 6> crypto:crypto_update(StateDec, <<67,44,216,166,25,130,203>>). <<"First b">> 7> crypto:crypto_update(StateDec, <<5,66,6,162,16,79,94,115,234,197, 94,253,16,144,151>>). <<"ytesSecond byte">> 8> crypto:crypto_update(StateDec, <<41>>). <<"s">> 9>

Note that the data that the StateEnc and StateDec references are destructivly updated by the calls to crypto_update/2. This is to gain time in the calls of the nifs interfacing the cryptolib. In a loop where the state is saved in the loop's state, it also saves one update of the loop state per crypto operation.

For example, a simple server receiving text parts to encrypt and send the result back to the one who sent them (the Requester):

encode(Crypto, Key, IV) -> crypto_loop(crypto:crypto_init(Crypto, Key, IV, true)). crypto_loop(State) -> receive {Text, Requester} -> Requester ! crypto:crypto_update(State, Text), loop(State) end.

Note that the State is not updated. Such updates could be costly if the loop state is a tuple or record with many elements.

Example of crypto_one_time/5

The same eample as in the previous section, but now with one call to crypto_one_time/5:

2> Key = <<1:128>>, 2> IV = <<0:128>>, 2> Txt = [<<"First bytes">>,<<"Second bytes">>], 2> crypto:crypto_one_time(aes_128_ctr, Key, IV, Txt, true). <<67,44,216,166,25,130,203,5,66,6,162,16,79,94,115,234, 197,94,253,16,144,151,41>> 3>

The [<<"First bytes">>,<<"Second bytes">>] could of course have been one single binary: <<"First bytesSecond bytes">>.

Retired cipher names

This table lists the retired cipher names in the first column and suggests names to replace them with in the second column.

The new names follows the OpenSSL libcrypto names. The format is ALGORITM_KEYSIZE_MODE.

Examples of algorithms are aes, chacha20 and des. The keysize is the number of bits and examples of the mode are cbc, ctr and gcm. The mode may be followed by a number depending on the mode. An example is the ccm mode which has a variant called ccm8 where the so called tag has a length of eight bits.

The old names had by time lost any common naming which the new names now introduces. The new names include the key length which improves the error checking in the lower levels of the crypto application.

Instead of: Use: aes_cbc128 aes_128_cbc aes_cbc256 aes_256_cbc aes_cbc aes_128_cbc, aes_192_cbc, aes_256_cbcaes_ccm aes_128_ccm, aes_192_ccm, aes_256_ccmaes_cfb128 aes_128_cfb128, aes_192_cfb128, aes_256_cfb128aes_cfb8 aes_128_cfb8, aes_192_cfb8, aes_256_cfb8aes_ctr aes_128_ctr, aes_192_ctr, aes_256_ctraes_gcm aes_128_gcm, aes_192_gcm, aes_256_gcmdes3_cbc des_ede3_cbcdes3_cbf des_ede3_cfbdes3_cfb des_ede3_cfbdes_ede3 des_ede3_cbcdes_ede3_cbf des_ede3_cfb