[CSDb] - User Forums - 8-bit homebrew ghetto cryptography

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > 8-bit homebrew ghetto cryptography

2021-08-23 13:14

Krill

Registered: Apr 2002
Posts: 2982

8-bit homebrew ghetto cryptography

After the Transwarp crypto challenge was so swiftly and thoroughly beaten, i decided to put in some effort and make it as hard as i can (while still not considerably slowing down loading nor sacrificing checksumming) for the next release.

Request for comments: I'm posting this here because i might have missed some weaknesses (or more devious encryption ideas), and because the secret is supposed to lie entirely with the key, not the algorithm.
Both the encryption and decryption routines will be released in source.

The key is now ~229.32 bits (~28.67 bytes, rounded to 29 bytes) large instead of a puny 40 bits (5 bytes).

To make a key this large somewhat practical to use, encrypted files are now loaded with a pass-phrase, like so

LOAD"SECRET",8,1,"THE REAL PARTY IS OUTSIDE"

The pass-phrase isn't the key. Instead, the key is generated from the pass-phrase using some kind of cryptographic hash function derived from this answer to a very similar problem.
The idea is to make reconstructing the pass-phrase from discovered parts of the key as hard as possible (while still limiting complexity to sensible 8-bit/1 MHz constraints). Note that longer pass-phrases are more secure, as usual, but more than 29 characters are ignored.

The key is then split up into smaller parts and applied like this:

1. 11 bytes (88 bits)

8 bytes are used as a simple EOR mask on the 8-byte Transwarp file metadata in the directory (load and end addresses, start track, number of blocks, checksums).
3 bytes are used as initial values for various decoding/transfer loops.

2. ~11.62 bytes (~92.99 bits)

File data bytes are transferred in bitpairs. Individual bit positions and bitpair values (0..3) are scrambled with this part of the key. As one of the 4 bitpairs in a byte is fixed both in position and values, there remain 6 arbitrary bit positions, with 4 different values for each of those 3 bitpairs, in 4 "types" of transferred bytes. This yields ((6!)*(4!^3))^4 (a little less than 10^28) different permutations for the data scrambling.

3. ~6.04 bytes (~48.3 bits)

A track consists of 17 to 21 sectors depending on density zone. The order of the first 17 sectors on all (but the last) file tracks (where those blocks go to in C-64 memory) is scrambled. This yields 17! (more than 355 million million) different permutations for the block position scrambling.

Quoting Quiss

Huh. I'll be curious to see what kind of 4k effect you need these kinds of cryptographic shenanigans for. :)

from Long division/modulo with byte-size divisor

There. =) (8K, though. =D)

... 10 posts hidden. Click here to view all posts....

2021-08-24 14:01

Krill

Registered: Apr 2002
Posts: 2982

Quoting JackAsser

You might wanna scramble the top eight bits also by:

for (int i = 0; i < TRANSWARPKEYSIZE; ++i) { key[i] ^= key[(i + 1) % TRANSWARPKEYSIZE]; }

This mixes in the result of the operation on the first byte, which is why i proposed that temp thingy. =)

2021-08-24 14:15

JackAsser

Registered: Jun 2002
Posts: 2014

Quote: Quoting JackAsser
You might wanna scramble the top eight bits also by:

for (int i = 0; i < TRANSWARPKEYSIZE; ++i) { key[i] ^= key[(i + 1) % TRANSWARPKEYSIZE]; }
This mixes in the result of the operation on the first byte, which is why i proposed that temp thingy. =)

Right, I see that now!

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: