RANDOM encryption

[Bryan]

I'm not sure what the application would be, but it occurred to me that Pokey's RANDOM feature would make a pretty good encryption device. Since you can reset the poly counter and start it at will, you can get RANDOM to return a deterministic sequence provided you control what interrupts are happening. This means you can encrypt data with a number sequence that's a combination of the poly function and the number of cycles between fetches of the RANDOM value. Although straight code to decrypt the data would be somewhat complicated to write on other systems, it would be dead simple on an Atari. It would also probably break on most emulators.

 

Anyway, just a thought.

[drac030]

Do you count in the DMA cycles and the differences in the main system clock between PAL, NTSC. SECAM Ataris?

[Bryan]

As far as I know, the DMA timing is exactly the same as long as you control the DLIST and don't let VBLANK happen. If there's differences, then they'd have to be compensated for (like resetting Pokey on every field and inserting a different start delay per field). The main system clock shouldn't matter since everything is synced to it.

[drac030]

True

[Bryan]

So, maybe the way to thwart Big Brother is passing around Atari documents on 5.25" floppies.

[phaeron]

You can indeed use the output of RANDOM for encryption, but it's exceptionally weak by modern standards: it is a linear function on the number of machine cycles passed. Specifically, it is the result of x^N mod P in GF(2) arithmetic, where N is the number of cycles passed and P is the characteristic polynomial for the 9-bit or 17-bit generator in use. When I took a cryptography class, one of the exercises was to break an LFSR-based stream cypher using only a handful of bits. Not that this would have mattered much in the olden days -- the solution to such a decryption scheme would be the same for most other, either spoof the inputs or capture the output.

 

Replicating it in pure software is not hard; the 9 bit generator can be simulated in the 6502 with only a handful of instructions:

    lda #0
    sta xrandom
    lda #1
    clc
loop:
    ror
    php
    ror xrandom
    plp
    bcc loop
    eor #$08
    bcs loop

I believe this is common practice for random number generation on the 2600, which lacks a CPU-visible PRNG. Of course, back then the polynomials for RANDOM were probably not widely known and would have been difficult to determine. Nowadays, you could just brute force it given some samples, much less use a fancy algorithm or look at the schematic.

 

Altirra implements the exact LFSR generators, by the way. I don't remember seeing code rely on this as a protection trick, though it would be hard to see this when everything is working. I have seen protection code use VCOUNT for encryption to stop software-based debuggers.

 

[pirx]

"computer says no"

[Rybags]

The random sequence doesn't take the extra or one less cycle to initate with a warm vs cold Pokey does it?

 

I suppose the lack of protection schemes using it probably comes down to lack of knowledge at the time, and possibly the chance that decryption could fail if a future revision changed Pokey.

It would have been a nifty way to hide bits of code - firstly setup the screen DMA to something that wouldn't be normally encountered via use of width, PMG DMA and HSCROL. Then decrypt the incoming blocks of code. To make things even harder, have something like a duplicate sector read which gives one or another pattern of DMA waits, have the decryption create valid code either way but only properly working code if the correct sector data has come down.

[phaeron]

The random sequence doesn't take the extra or one less cycle to initate with a warm vs cold Pokey does it?

 

No, I have never seen or heard of the pattern or the timing of the initial sequence changing between machines. The only program visible chip/temperature sensitive timings that I know of with just the stock computer are POKEY IRQs, GTIA mode switches, and floating pins on PIA port B.