aes - Do I need multiple EVP_CIPHER_CTX structures? -

aes - Do I need multiple EVP_CIPHER_CTX structures? -

i have single-threaded client/server application needs both encryption , decryption of network communication. plan on using openssl's evp api , aes-256-cbc.

some sample pseudo-code found few examples:

// key 256 bits (32 bytes) when using evp_aes_256_*() // think iv same size block size, 128 bits (16 bytes)...is it? 1: evp_cipher_ctx *ctx = evp_cipher_ctx_new(); 2: evp_cipherinit_ex(ctx, evp_aes_256_cbc(), null, key, iv, 1); //0=decrypt, 1=encrypt 3: evp_cipherupdate(ctx, outbuf, &outlen, inbuf, inlen); 4: evp_cipherfinal_ex(ctx, outbuf + outlen, &tmplen)); 5: outlen += tmplen; 6: evp_cipher_ctx_cleanup(ctx); 7: evp_cipher_ctx_free(ctx);

the problem these examples, i'm not sure needs done @ every encryption/decryption, , should 1 time on startup.

specifically:

at line 1, create evp_cipher_ctx 1 time , maintain re-using until application ends? also @ line 1, can re-use same evp_cipher_ctx both encryption , decryption, or supposed create 2 of them? at line 2, should iv re-set @ every packet i'm encrypting? or set iv once, , allow go on forever? what if i'm encrypting udp packets, packet can go missing or received out-of-order: right in thinking cbc wont work, or need reset iv @ start of every packet send out?

i have single-threaded client/server application needs both encryption , decryption of network communication. plan on using openssl's evp api , aes-256-cbc.

if using ssl_* functions libssl, never touch evp_* apis.

at line 1, create evp_cipher_ctx 1 time , maintain re-using until application ends?

you create 1 time per use. is, need encrypt, utilize same context. if need encrypt sec stream, utilize sec context. if needed decrypt 3rd stream, utilize 3rd context.

also @ line 1, can re-use same evp_cipher_ctx both encryption , decryption, or supposed create 2 of them?

no, see above.

the ciphers have different states.

at line 2, should iv re-set @ every packet i'm encrypting? or set iv once, , allow go on forever?

no. set iv 1 time , forget it. that's part of state context object manages cipher.

what if i'm encrypting udp packets, packet can go missing or received out-of-order: right in thinking cbc wont work...

if using udp, observe these sorts of problems. you'll end reinventing tcp.

encryption lone not enough. need ensure authenticity , integrity. don't operate on info that's not authentic. that's keeps getting sst/tls , ssh in trouble.

for example, here's guy wrote seminal paper on authenticated encryption respect ipsec, ssl/tls , ssh weighing in on authenticate-then-encrypt (eta) scheme used ssl/tls: last call: (encrypt-then-mac tls , dtls) proposed standard:

the technical results in 2001 paper right conclusion regarding ssl/tls wrong. assumed tls using fresh ivs , mac computed on encoded plaintext, i.e. encode-mac-encrypt while tls doing mac-encode-encrypt theoretical illustration shows insecure.

for authenticity, should forgo cbc mode , switch gcm mode. gcm authenticated encryption mode, , combines confidentiality , authenticity 1 mode don't have combine primitives (like aes/cbc hmac).

or need reset iv @ start of every packet send out?

no, set iv 1 time , forget it.

the problem these examples, i'm not sure needs done @ every encryption/decryption, , should 1 time on startup.

create once: evp_cipher_ctx call 1 time setup: evp_cipherinit call many times you'd like: evp_cipherupdate call 1 time cleanup: evp_cipherfinal

the openssl wiki has quite few examples of using evp_* interfaces. see evp symmetric encryption , decryption, evp authenticated encryption , decryption , evp signing , verifying.

all examples utilize same pattern: init, update , final. not matter if encryption or hashing.

related: should of involvement you: evp authenticated encryption , decryption. sample code openssl wiki.

related: can find copies of viega, messier , chandra's network security openssl online. might consider hunting downwards re-create , getting familiar of concepts.

aes openssl