Sortix volatile manual
This manual documents Sortix volatile, a development build that has not been officially released. You can instead view this document in the latest official manual.
| PEM_READ(3) | Library Functions Manual | PEM_READ(3) | 
NAME
PEM_write,
    PEM_write_bio, PEM_read,
    PEM_read_bio,
    PEM_get_EVP_CIPHER_INFO,
    PEM_do_header,
    PEM_def_callback,
    pem_password_cb — PEM
    encoding routines
SYNOPSIS
#include
    <openssl/pem.h>
int
  
  PEM_write(FILE *fp,
    const char *name, const char
    *header, const unsigned char *data,
    long len);
int
  
  PEM_write_bio(BIO *bp,
    const char *name, const char
    *header, const unsigned char *data,
    long len);
int
  
  PEM_read(FILE *fp,
    char **name, char **header,
    unsigned char **data, long
    *len);
int
  
  PEM_read_bio(BIO *bp,
    char **name, char **header,
    unsigned char **data, long
    *len);
int
  
  PEM_get_EVP_CIPHER_INFO(char
    *header, EVP_CIPHER_INFO *cinfo);
int
  
  PEM_do_header(EVP_CIPHER_INFO
    *cinfo, unsigned char *data,
    long *len, pem_password_cb *cb,
    void *userdata);
int
  
  PEM_def_callback(char *password,
    int size, int verify,
    void *userdata);
typedef int
  
  pem_password_cb(char *password,
    int size, int verify,
    void *userdata);
DESCRIPTION
These functions read and write PEM-encoded objects, using the PEM type name, any additional header information, and the raw data of length len.
PEM is the binary content encoding first defined in IETF RFC 1421. The content is a series of base64-encoded lines, surrounded by begin/end markers each on their own line. For example:
-----BEGIN PRIVATE KEY----- MIICdg.... ... bhTQ== -----END PRIVATE KEY-----
Optional header line(s) may appear after the begin line, and their existence depends on the type of object being written or read.
PEM_write()
    writes to the file fp, while
    PEM_write_bio()
    writes to the BIO bp. The name
    is the name to use in the marker, the header is the
    header value or NULL, and data
    and len specify the data and its length.
The final data buffer is
    typically an ASN.1 object which can be decoded with the
    d2i_*()
    function appropriate to the type name; see
    d2i_X509(3) for
  examples.
PEM_read()
    reads from the file fp, while
    PEM_read_bio()
    reads from the BIO bp. Both skip any non-PEM data that
    precedes the start of the next PEM object. When an object is successfully
    retrieved, the type name from the "----BEGIN <type>-----" is
    returned via the name argument, any encapsulation
    headers are returned in header, and the base64-decoded
    content and its length are returned via data and
    len, respectively. The name,
    header, and data pointers should
    be freed by the caller when no longer needed.
The remaining functions are deprecated because the underlying PEM encryption format is obsolete and should be avoided. It uses an encryption format with an OpenSSL-specific key-derivation function, which employs MD5 with an iteration count of 1. Instead, private keys should be stored in PKCS#8 form, with a strong PKCS#5 v2.0 PBE; see PEM_write_PrivateKey(3) and d2i_PKCS8PrivateKey_bio(3).
PEM_get_EVP_CIPHER_INFO()
    can be used to determine the data returned by
    PEM_read() or PEM_read_bio()
    is encrypted and to retrieve the associated cipher and IV. The caller passes
    a pointer to a structure of type EVP_CIPHER_INFO via
    the cinfo argument and the
    header returned via PEM_read()
    or PEM_read_bio(). If the call is successful, 1 is
    returned and the cipher and IV are stored at the address pointed to by
    cinfo. When the header is malformed or not supported
    or when the cipher is unknown or some internal error happens, 0 is
  returned.
PEM_do_header()
    can then be used to decrypt the data if the header indicates encryption. The
    cinfo argument is a pointer to the structure
    initialized by a preceding call to
    PEM_get_EVP_CIPHER_INFO(). If that structure
    indicates the absence of encryption, PEM_do_header()
    returns successfully without taking any action. The
    data and len arguments are used
    both to pass in the encrypted data that was returned in the same arguments
    from the preceding call to PEM_read() or
    PEM_read_bio() and to pass out the decrypted
  data.
The callback function
    cb is used to obtain the encryption
    password; if cb is
    NULL,
    PEM_def_callback()
    is used instead. The password buffer needs to be at
    least size bytes long. Unless
    userdata is NULL,
    PEM_def_callback() ignores the
    verify argument and copies the NUL-terminated byte
    string userdata to password
    without a terminating NUL byte, silently truncating the copy to at most
    size bytes. If userdata is
    NULL, PEM_def_callback()
    instead prompts the user for the password with echoing turned off by calling
    EVP_read_pw_string_min(3)
    internally. In this case, the size is silently reduced
    to at most BUFSIZ and at most
    size - 1 bytes are accepted
    from the user and copied into the byte string buffer
    password. A callback function cb
    supplied by the application may use userdata for a
    different purpose than PEM_def_callback() does,
    e.g., as auxiliary data to use while acquiring the password. For example, a
    GUI application might pass a window handle. If the
    verify flag is non-zero, the user is prompted twice
    for the password to make typos less likely and it is checked that both
    inputs agree. This flag is not set by
    PEM_do_header() nor by other read functions, but it
    is typically set by write functions.
If the data is a priori known to
    not be encrypted, then neither
    PEM_get_EVP_CIPHER_INFO()
    nor PEM_do_header() need to be called.
RETURN VALUES
PEM_read() and
    PEM_read_bio() return 1 on success or 0 on failure.
    The latter includes the case when no more PEM objects remain in the input
    file. To distinguish end of file from more serious errors, the caller must
    peek at the error stack and check for
    PEM_R_NO_START_LINE, which indicates that no more
    PEM objects were found. See
    ERR_peek_last_error(3)
    and
    ERR_GET_REASON(3).
PEM_get_EVP_CIPHER_INFO() and
    PEM_do_header() return 1 on success or 0 on failure.
    The data is likely meaningless if these functions
    fail.
PEM_def_callback() returns the number of
    bytes stored into buf or a negative value on failure,
    and cb is expected to behave in the same way. If
    userdata is NULL,
    PEM_def_callback() fails if
    num is less than 5 or if an error occurs trying to
    prompt the user for the password. Otherwise, it fails when
    num is negative. The details of the circumstances that
    cause cb to fail may differ.
SEE ALSO
crypto(3), d2i_PKCS8PrivateKey_bio(3), PEM_ASN1_read(3), PEM_bytes_read_bio(3), PEM_read_bio_PrivateKey(3), PEM_read_SSL_SESSION(3), PEM_write_bio_CMS_stream(3), PEM_write_bio_PKCS7_stream(3), PEM_X509_INFO_read(3)
HISTORY
PEM_write(),
    PEM_read(), and
    PEM_do_header() appeared in SSLeay 0.4 or earlier.
    PEM_get_EVP_CIPHER_INFO() first appeared in SSLeay
    0.5.1. PEM_write_bio() and
    PEM_read_bio() first appeared in SSLeay 0.6.0. These
    functions have been available since OpenBSD 2.4.
PEM_def_callback() first appeared in
    OpenSSL 0.9.7 and has been available since OpenBSD
    3.2.
| Sepember 18, 2023 | Sortix 1.1.0-dev | 
