-2
$\begingroup$

While base64 encoding does not have the intent to encrypt, it is not far fetched to think that the encoding process could be tempered with in some way as to create an encryption. Surely, I am not the first person to think of such an encryption attempt making use of base64 encoding. Therefore, I'd like to ask what kinds of base64 encryption strategies are known?

$\endgroup$
  • 1
    $\begingroup$ Like a 6 bit stream cipher? $\endgroup$ – Paul Uszak Jul 21 '17 at 20:41
  • 1
    $\begingroup$ generally the encryption happens before the data is run through Base64 $\endgroup$ – Richie Frame Jul 22 '17 at 0:53
  • $\begingroup$ I've seen base64 encryption schemes used before, but all of them could be trivially broken. This question makes sense because people might be searching for algorithms like this. However, common sense probably means that we indicate that base64 is not meant as a cipher and is the result of confusing encoding with encryption. Note that many of us will assume that the premise of this question is wrong: that an encoding scheme can be used for encryption. This could result in downvotes, even if the question is at least interesting to many starting cryptographers. $\endgroup$ – Maarten Bodewes Apr 23 '19 at 9:48
0
$\begingroup$

This is taken from the Wiki entry for Base64:

base64 example

If you really intended to tamper Base64 encoding to provide encryption, it could be done at the Index level highlighted above. You would need a secret key, a key derivation function tailored to create a high entropy seed which then started off a pseudo random number generator. The generator's (6 bit) output would then be XORed with the Index to change the encoding for every character. And this technique can be reversed to decipher the encrypted message.

You see that it's all a bit of a bother. Traditionally you'd create the cipher text and then encode it. Other than cropping a typical 8 bit random sequence to 6 bits, the workload is identical though to the traditional stream cipher. Actually you need 33% extra computations, but that's neither here nor there.

You might be the first to have thought of this Base64 variant as no one seems to be aware of similar behaviour. This should work though.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks for this interesting suggestion! Actually, I had in mind simple stuff, like permuting the 6bit letter table association. Or introducing a key and have a bitwise xor operation on each letter cycling through the key, or similar. $\endgroup$ – Kagaratsch Jul 22 '17 at 16:20
  • 1
    $\begingroup$ @Kagaratsch Well I think we're thinking on similar lines. To permute you'll need PRNG functionality and to link a key to a PRNG you'll need some sort of key derivation function otherwise there'll be a mismatch between the key format and the format /state required to operate the PRNG. If you simply permute without a key, or use the your key character cycling, the scheme's not very secure and this is crypto.SE after all :-) $\endgroup$ – Paul Uszak Jul 22 '17 at 16:46
  • 1
    $\begingroup$ @PaulUszak That technical name is actually pretty obvious as soon as you know it… it's simply called "XOR cipher". ;) Yet, note that frequency analysis will trivially break it. Same goes for known plaintext attacks. Oh, and to be complete regarding the technical naming: when you throw in a prng, such a "XOR cipher" turns into a "stream cipher". But you probably knew that already, didn't you? $\endgroup$ – e-sushi Jul 23 '17 at 1:51
  • 1
    $\begingroup$ @PaulUszak Not sure why you say "no". Also, you can be confident I know what "cycling" means. A XOR cipher does cycle through the same key over and over again and in the same order, just like you describe. Check the "example" of that wiki link; it matches your descriptions 100%… a bitwise xor operation on each letter cycling through the key and Cycling round through the key means that the plain text will be XORed with the same sequence over and over, and in the same order. — that's called "XOR cipher". No mistake or language gap there. $\endgroup$ – e-sushi Jul 23 '17 at 2:25
  • 2
    $\begingroup$ Any way you tweak base64 like this can be factored into (a) defining a cipher on byte strings and then (b) applying standard base64 to its output, mapping ciphertext byte strings to plain text. There's no sense in merging (a) and (b)—it adds no security and needlessly complicates the description of both the underlying cipher and the implied standard base64. $\endgroup$ – Squeamish Ossifrage Jul 23 '17 at 16:43
8
$\begingroup$

This does not make sense. There is no secret key in base64: base64 encoding and decoding are public functions that anyone can evaluate.

The only way that base64 is related to cryptography is that it is convenient to encode ciphertext from some cryptosystem, which is uniformly distributed in 8-bit strings, in a limited set of US-ASCII that will not be munged or rejected in contexts that are limited to plain text, such as XML.

| improve this answer | |
$\endgroup$
  • 2
    $\begingroup$ +1 (… and base64 produces shorter outputs than hex encoding, which is why it was developed and why it tends to be frequently used in applications.) $\endgroup$ – e-sushi Jul 22 '17 at 5:16
  • 1
    $\begingroup$ It makes perfect sense :-) The question was posed as a hypothetical and the OP is looking for implementation possibilities. There's no natural law requiring that all encryption has to be super dooper efficient. It just has to encrypt /decrypt. Do you know that people still build steam engines and are very proud of them..? $\endgroup$ – Paul Uszak Jul 23 '17 at 16:52
  • 3
    $\begingroup$ @PaulUszak It doesn't make sense as base64, a public transformation between two equivalent representations of data, is a different type of object from an encryption scheme which involves secrets not known to an adversary. Any way you modify the interface and internals of base64 to put some kind of key and cipher in it can be factored into the standard base64 representation transformation and some underlying cipher whose security is irrelevant to the base64 part. If you made a steam-powered Enigma machine, would you say that you modified the concept of steam power into an encryption scheme? $\endgroup$ – Squeamish Ossifrage Jul 23 '17 at 17:27
  • $\begingroup$ @SqueamishOssifrage Yes. $\endgroup$ – Paul Uszak Apr 23 '19 at 21:45
3
$\begingroup$

The golden rule of cryptography should be : "It is not because you cannot read the text that this is encrypted". Base64 is not intended to be used in order to create ciphertext and it should not be used for that purpose.

Encryption methods always rely on a secret or artifacts that ensure that only the actors of the communication can reverse the ciphertext. If it does not, like with Base64, then it is not encryption.

Base64 is intended to encode binary as text with various advantages over other encoding schemes. Privacy is not among these advantages.

| improve this answer | |
$\endgroup$
-2
$\begingroup$

Yes, there is an interest in encrypting upstream base64: it's the economy in iterations. When we encrypt data and then encode it, we have to make at least two loops: one on the encryption of the data and the other on the encoding of the data generated. By encrypting upstream we can reduce to a loop and therefore gain significant performance.

@e-sushi: Indeed, there are not many examples except this one which uses only one loop: php_base64encrypted

There are probably other ways to do better but it proves that it is possible...

Edit: sorry, I am not very familiar with this site.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Can you provide an example (link to paper or something) of such ` interest in encrypting upstream base64`? I tried to find more info using my favorite search engine, but somehow I failed. A pointer would therefore be much appreciated. $\endgroup$ – e-sushi Nov 2 '18 at 1:06
  • $\begingroup$ Base64 encoding is a streamable process (i.e. it allows a stream of data to be incrementally encoded as it's generated, without having to first read all of it). Thus, it would be perfectly possible to have a conventional encryption scheme feed its output into an incremental base64 encoder, without having to "make at least two loops" over the data. The only reason why this isn't more commonly done is probably the fact that, for data streams long enough to make this useful, it's usually a lot more efficient to skip base64 encoding entirely and just transmit and/or store them as raw binary data. $\endgroup$ – Ilmari Karonen Apr 23 '19 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.