Is "6 bit packed ASCII" an effective encoding to obscure text data?

I wrote a routine for a former employer that took the low six bits of ASCII text and "compressed" by cramming the bits together, so that 4 bytes reduced to 3. This had the advantage of automatically folding lowercase to uppercase (not reversibly) with no computational effort. (Our text data was supposed to be just upper case letters, digits and punctuation. Can you say COBOL? I knew you could.) Note that I also ignored the first 32 ASCII characters as well. (They did not appear in the input data.)

Would this encoding method obfuscate text (where SHOUTING was acceptable) in a way that does not yield readily to simple analysis? The data would be encoded from 4 bytes down to 3 like this - (assume that we are only looking at the low 6 bits of every byte, the high 2 bits are just clipped off):

B1 = all 6 bits of first byte + low 2 bits of 2nd byte
B2 = "upper" 4 bits of 2nd byte + lower 4 bits of 3rd byte
B3 = last 2 bits of 3rd byte + all 6 bits of 4th byte


(Is there a prettier picture to illustrate this?)

• Short answer, no. This is similar to performing Base64 decode on plaintext data. You may have noticed that ASCII letters are actually 7 bits... Jun 29, 2016 at 23:17
• @RichieFrame Yes, but if you can sacrifice lower case, ignoring the two high bits leads to lowercase and uppercase being indistinguishable. Example: Uppercase A is hex 41, lowercase a is hex 61. "It's like, one bit different, you know?" I had an alternative algorithm which only ignored the top bit and compressed 8 bytes to 7... Oh, right, I ignored the whole first 32 ASCII characters as well. Gotta cut corners somehow.
– user36481
Jun 29, 2016 at 23:21
• as @A.Toumantsev says below, there isn't a good way to answer "is this effective" in the absence of real keyed encryption. What is the threat model? What resources does the attacker have? If I'm the attacker, you've already told me everything I need to know to decode the data. Jun 30, 2016 at 23:59
• If you're comparing it with putting a lock on a diary, then yes this method of obfuscation will keep your little sister from reading your data. Jul 1, 2016 at 15:18
• And I shouldn't have said that the type of question is unanswerable, it just needs to be more specific, like: How does this transformation affect the byte distribution. Jul 1, 2016 at 15:19

1 Answer

No. I actually new how to do such coding on my MSX machine in the mid-eighties (when I was 12). I'm pretty sure I could have decoded it back then. Note that binary code was much more used at that time; you had to code in assembler to get any kind of performance. It was also pretty common to compress things in such a way because you did not have much memory either.

What you're describing is an encoding scheme. Encoding is something different from encryption. Obviously it can obfuscate text, but that obfuscation is just skin deep. This is especially the case if somebody starts to look for strings.

You could however encode to base64 with a different alphabet. That kind of obfuscate things enough that you have to revert the encoding to read it. You could also XOR your scheme with a (multi-)byte pattern to make things less readable for humans.

• I completely agree with all you wrote, except for the initial 'No'. If we re-read the question: is this an obfuscation? Yes. Is it effective? No idea what is meant by effectiveness here. A bit weird that the packing algorithm is lossy but if the input data is guaranteed to always fit within 6 bits - it's OK. Ah, there's a 2nd question in the body about "simple analysis" - to this the answer is, indeed, No. Or, more, precisely - it depends on who is going to analyse. :)
– tum_
Jun 30, 2016 at 5:34
• @A.Toumantsev The problem is that 1) it depends on the audience if this is any good as obfuscation; I tried to argue that there are plenty people out there that think in bits and will find this an amusing puzzle at best and 2) that there are plenty schemes that are about as simple as this, but do a much better job at obfuscation. Jun 30, 2016 at 7:40
• yep, agreed. And I'll repeat myself - if someone asks "is this effective" I demand the definition of "effectiveness" in the context of the question. Being what I am and doing what I do, I first read 'effective' as 'fast', in which sense the suggested algo is pretty much 'effective' but that's definitely not what OP means :)
– tum_
Jun 30, 2016 at 8:04
• I see. Well, as others pointed out already, "that obfuscation is just skin deep. This is especially the case if somebody starts to look for strings." but if this suits your puposes, no problem...
– tum_
Jul 1, 2016 at 15:07
• @nocomprende We'll be banned for chat and offtopic, there are rules here. Your questions, as far as I can see, have been answered. The rest is offtopic. I wouldn't mind a chat but rules are rules.
– tum_
Jul 1, 2016 at 17:23