Post: Base64

When delving into PKI, one will often come across the widespread use of base64. Hence, while browsing through this post, there might be references to Base64. From interactions in reality, I’ve noted a significant number of people either misunderstanding or having misconceptions about it, prompting a lengthier explanation that merited its own post.

Base64?

While ‘Base’ could imply different meanings, in the realm of computer science, it predominantly denotes a numeral system, akin to how Base2 refers to binary. Thus, literally, Base64 means utilizing a 64-based numeral system. It’s particularly designed for representing binary data in a 64-based system. The reason for choosing 64 stems from it being the maximum number of ASCII characters that can be comfortably recognized and utilized by humans. Though the basic ASCII character set comprises 128 characters, it includes less visually distinguishable characters like carriage returns or tabs, thus making 64 the largest number that can be visually represented on screens.

Representation

Initially, data is segmented into 6-bit units, taking an extra unit if there’s an overflow. These segments are then converted using 64 distinct numbers and their corresponding 64 characters. The choice of 6-bit units arises because 2^6 equals 64. This leads to three possible scenarios:

1. The data size perfectly aligns.
2. After full representation, 2 bits remain.
3. After full representation, 4 bits remain. (Since we’re working with increments of 6, a leftover of 6 bits is impossible.)

While scenario 1 poses no issue, scenarios 2 and 3 do. In such cases, for the remaining 2 bits, ‘=’ signs are appended as needed. Thus, the ‘=’ at the end serves solely as padding, and its absence does not negate the Base64 encoding scheme.

Is Base64 Encryption?

One of the main reasons for writing this post was to address a common misconception: since Base64 alters the appearance making content not immediately human-readable, could it be considered a form of encryption? In my view, encryption can be categorized based on whether it hides the algorithm, the key, or both. The strategy of concealing the algorithm is deemed obsolete post the breaking of the Enigma code. In modern contexts, encryption implies publicly known algorithms where, without the key, decryption within a realistic timeframe is impossible. Hiding an algorithm renders the encryption futile upon discovery, but with key length dependence, extending the accepted key length suffices.

Base64 does not require a key; it simply relies on converting data using a known algorithm. Asserting that the binary representation of data equates to encryption is on par with claiming HTML is a programming language¹. Such a definition is not something I can accept…

Why Base64?

Upon reflection, Base64 appears highly inefficient in terms of data transmission efficiency. This is because, whereas 8 bits can typically represent a byte, here only 6 bits are utilized, thus reducing efficiency by a minimum of 25%. Moreover, the incorporation of padding exacerbates this inefficiency. Nonetheless, there are compelling reasons for its usage. The genesis of Base64 is tied to web or email communications, inherently based on string data, which necessitates the incorporation of binary data. While binary could be transmitted as a separate extension, incorporating binary within basic protocol frameworks necessitated a suitable binary encoding technique unaffected by encoding, thus begetting Base64. Essentially, any system ultimately supports the ASCII character set.

PKI and Base64

In the realm of authentication, Base64 is commonly utilized, particularly due to the PEM (Privacy Enhanced Mail) protocol. Anyone configuring SSL/TLS might have encountered files with the ‘.pem’ extension. Originating as a secure email transmission protocol, the basic MIME (Multipurpose Internet Mail Extensions) format for SMTP-transmitted emails supported only 7-bit ASCII, necessitating the representation in base64. Opening a PEM file would reveal readable text formatted as follows:

-----BEGIN CERTIFICATE----- 
MIIF... 
-----END CERTIFICATE-----

The delineation using ‘–’ is a vestige of MIME, which typically utilizes ‘–’ for boundary differentiation. The prevalence of this format in authentication contexts is primarily due to PKI standards initially standardizing upon binary formats like BER/DER, which imposed significant inconveniences in various environments (in my opinion). Most PKI-related tools can decode data represented in base64. Anyone opening a PEM file and decoding it in binary will confirm its representation in BER, for instance. Though, to my knowledge, the PEM protocol has largely fallen out of frequent use, the convenience offered by PEM’s key representation format continues to secure its widespread adoption. Hence, in PKI discussions about Base64, it generally pertains to ASN.1 structures, especially DER or BER. Be mindful, however, not to confuse this with SSH keys, which have a different appearance. Base64 representations of BER or DER start with MIIF or MIIE, respectively.

ssh-rsa ... user@host

SSH keys display as above. RFC4253 details SSH-specific key objects, essentially summarizing that, unlike most PKI data, these are raw data.

1. HTML, as its name suggests, is a markup language designed for structuring content, not for creating programs. Programs execute predefined sequences of actions. ↩