EVP_ENCODEINIT(3SSL)

📦
version 4.0.3 · 13 versions
, in ubuntu stonking

💖 EVP_ENCODEINIT 💖

okay bestie, gather round, because this is the OpenSSL manual page for the EVP_ENCODEINIT family — like, the base64 era of your life? it's giving "encode me, decode me, pad me with =" and honestly? we're obsessed. it's the OpenSSL manual page, and no cap, it's a whole vibe. 🎀

✨ NAME ✨

EVP_ENCODE_CTX_new, EVP_ENCODE_CTX_free, EVP_ENCODE_CTX_copy, EVP_ENCODE_CTX_num, EVP_EncodeInit, EVP_EncodeUpdate, EVP_EncodeFinal, EVP_EncodeBlock, EVP_DecodeInit, EVP_DecodeUpdate, EVP_DecodeFinal, EVP_DecodeBlock — the EVP base64 encode/decode routines. that's the whole squad. 💅

✨ SYNOPSIS ✨

#include <openssl/evp.h>

EVP_ENCODE_CTX *EVP_ENCODE_CTX_new(void);
void EVP_ENCODE_CTX_free(EVP_ENCODE_CTX *ctx);
int EVP_ENCODE_CTX_copy(EVP_ENCODE_CTX *dctx, EVP_ENCODE_CTX *sctx);
int EVP_ENCODE_CTX_num(EVP_ENCODE_CTX *ctx);
void EVP_EncodeInit(EVP_ENCODE_CTX *ctx);
int EVP_EncodeUpdate(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl,
                     const unsigned char *in, int inl);
void EVP_EncodeFinal(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl);
int EVP_EncodeBlock(unsigned char *t, const unsigned char *f, int n);

void EVP_DecodeInit(EVP_ENCODE_CTX *ctx);
int EVP_DecodeUpdate(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl,
                     const unsigned char *in, int inl);
int EVP_DecodeFinal(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl);
int EVP_DecodeBlock(unsigned char *t, const unsigned char *f, int n);

🌸 DESCRIPTION 🌸

so basically, the EVP encode girlies give you a high-level interface to base64 encoding and decoding. base64 is that trick where you take binary data and glow it up into printable form using the characters A-Z, a-z, 0-9, "+" and "/". iconic alphabet, fr fr.

the math? every 3 bytes of binary data you hand over become 4 bytes of base64 encoded data, plus some occasional newlines (more on that below, bestie). and if your input length isn't a multiple of 3, the output gets padded at the end with the "=" character. cute little bow on the end. 🎀

🦋 the context girlies

  • EVP_ENCODE_CTX_new() — allocates, initializes and returns a context for you to use with the encode/decode functions. your blank canvas, your main character moment.
  • EVP_ENCODE_CTX_free() — cleans up an encode/decode context ctx and frees the space allocated to it. and if the argument is NULL? nothing happens. she simply does not engage. 🙈

🌈 encoding: the mechanics

encoding of binary data happens in blocks of 48 input bytes (or less for the final block, the little baby one). for each 48 byte input block you get 64 bytes of base64 data output plus an additional newline character — that's 65 bytes in total, no cap.

the final block (which may be less than 48 bytes) will output 4 bytes for every 3 bytes of input. if the data length isn't divisible by 3, a full 4 bytes is still output for the final 1 or 2 bytes of input. equally, a newline character will also be output. the math does not care about your feelings. 💀

🌟 the encode functions

  • EVP_EncodeInit() — initialises ctx for the start of a new encoding operation. fresh start, new era.
  • EVP_EncodeUpdate() — encodes inl bytes of data found in the buffer pointed to by in. the output is stored in the buffer out and the number of bytes output is stored in *outl. ⚠️ it is the caller's responsibility to make sure the buffer at out is big enough to hold the output data — don't come for her if you under-allocated, that's on you bestie.

only full blocks of data (48 bytes) get immediately processed and output by this function. any remainder is held in the ctx object and will be processed by a subsequent call to EVP_EncodeUpdate() or EVP_EncodeFinal().

to calculate the required size of the output buffer: add together the value of inl with the amount of unprocessed data held in ctx and divide the result by 48 (ignore any remainder). that gives you the number of blocks of data that will be processed. then ensure the output buffer contains 65 bytes of storage for each block, plus an additional byte for a NUL terminator. yes queen, do the math.

EVP_EncodeUpdate() may be called repeatedly to process large amounts of input data. in the event of an error it will set *outl to 0 and return 0. on success, 1 is returned. periodt.

  • EVP_EncodeFinal() — must be called at the end of an encoding operation. it will process any partial block of data remaining in the ctx object. the output data is stored in out and the length of the data written is stored in *outl. again, caller's responsibility to make out big enough — it will never be more than 65 bytes plus an additional NUL terminator, i.e. 66 bytes in total. that's the ceiling, babe. 🫶
  • EVP_ENCODE_CTX_copy() — copies a context sctx to a context dctx. ⚠️ dctx must be initialized before calling this function. don't skip the warm-up.
  • EVP_ENCODE_CTX_num() — returns the number of as yet unprocessed bytes still to be encoded or decoded that are pending in the ctx object. she's keeping receipts. 💅
  • EVP_EncodeBlock() — encodes a full block of input data in f of length n and stores it in t. for every 3 bytes of input provided, 4 bytes of output will be produced. if n is not divisible by 3 then the block is encoded as a final block of data and the output is padded so it's always divisible by 4. additionally a NUL terminator character will be added.

for example: if 16 bytes of input data is provided then 24 bytes of encoded data is created plus 1 byte for a NUL terminator — that's 25 bytes in total. the length of the data generated without the NUL terminator is what gets returned from the function. iykyk. ✨

🧚 decoding: the mechanics

  • EVP_DecodeInit() — initialises ctx for the start of a new decoding operation. reverse era, activated.
  • EVP_DecodeUpdate() — decodes inl characters of data found in the buffer pointed to by in. the output is stored in the buffer out and the number of bytes output is stored in *outl. yeah, caller's responsibility to ensure the buffer at out is big enough to accommodate the output data — say it with me now.

this function will attempt to decode as much data as possible in chunks of up to 80 base64 characters at a time. residual input shorter than the internal chunk size will be buffered in ctx if its length is not a multiple of 4 (including any padding), to be processed in future calls to EVP_DecodeUpdate() or EVP_DecodeFinal(). but if the final chunk length is a multiple of 4, it's decoded immediately and not buffered. she's decisive like that. 💅

any whitespace, newline or carriage return characters are ignored. for compatibility with PEM, the - (hyphen) character is treated as a soft end-of-input, subsequent bytes are not buffered, and the return value will be 0 to indicate that the end of the base64 input has been detected. ⚠️ the soft end-of-input, if present, MUST occur after a multiple of 4 valid base64 input bytes. and heads up: the soft end-of-input condition is not remembered in ctx — it is up to the caller to avoid further calls to EVP_DecodeUpdate() after a 0 or negative (error) return. you've been warned. 😭

if any invalid base64 characters are encountered, or if the base64 padding character (=) is encountered in the middle of the data, then EVP_DecodeUpdate() returns -1 to indicate an error. a return value of 0 or 1 indicates successful processing of the data. a return value of 0 additionally indicates that the last 4 bytes processed ended with base64 padding (=), or that the next 4 byte group starts with the soft end-of-input (-) character — and therefore no more input data is expected to be processed.

for every 4 valid base64 bytes processed (ignoring whitespace, carriage returns and line feeds), 3 bytes of binary output data will be produced — except at the end of data terminated with one or two padding characters. the glow-down is real. 🦋

  • EVP_DecodeFinal() — should be called at the end of a decoding operation, but it will never decode additional data. if there's no residual data it returns 1 to indicate success. if there is residual data and its length is not a multiple of 4 — i.e. it was not properly padded — -1 is returned to indicate an error. no notes.
  • EVP_DecodeBlock() — will decode the block of n characters of base64 data contained in f and store the result in t. any leading whitespace will be trimmed, as will any trailing whitespace, newlines, carriage returns or EOF characters. ⚠️ internal whitespace MUST NOT be present.

after trimming, the data in f MUST consist entirely of valid base64 characters or padding (only at the tail of the input) and its length MUST be divisible by 4. for every 4 input bytes exactly 3 output bytes will be produced.

now this part is important, bestie: padding bytes (=) — even if internal — are decoded to 6 zero bits, and the caller is responsible for taking trailing padding into account by ignoring as many bytes at the tail of the returned output. EVP_DecodeBlock() will return the length of the data decoded, or -1 on error. slay 🫶

👑 RETURN VALUES 👑

  • EVP_ENCODE_CTX_new() returns a pointer to the newly allocated EVP_ENCODE_CTX object or NULL on error.
  • EVP_ENCODE_CTX_num() returns the number of bytes pending encoding or decoding in ctx.
  • EVP_EncodeUpdate() returns 0 on error or 1 on success.
  • EVP_EncodeBlock() returns the number of bytes encoded excluding the NUL terminator.
  • EVP_DecodeUpdate() returns -1 on error and 0 or 1 on success. if 0 is returned then no more non-padding base64 characters are expected.
  • EVP_DecodeFinal() returns -1 on error or 1 on success.
  • EVP_DecodeBlock() returns the length of the data decoded or -1 on error.

🔥 SEE ALSO 🔥

  • evp(7) — go read her too, she's iconic.

💀 HISTORY 💀

the EVP_DecodeUpdate() function was fixed in OpenSSL 3.5, so now it produces the number of bytes specified in outl* and does not decode padding bytes (=) to 6 zero bits. glow-up confirmed. ✨

Copyright 2016-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

and that's the whole page, bestie!! 💖 this was OpenSSL manual version 4.0.3, dated 2026-09-29, and honestly? she ate and left no crumbs. now go pad something and stay hydrated. 🍓💅

📦 where this page comes from