7

I'm working on a programming language that's intended to compile to retro hardware, and I want to add a PRNG to the specification. Ideally, this would be both standard (easy to find specifications for) and cryptographically secure. This won't be used for anything actually security-critical—including a Commodore 64 in any system that needs to be secure seems like a terrible idea—but being cryptographically secure means it automatically satisfies all statistical randomness tests, like the next-bit test.

The easiest solution (that I can see) would be a XOF, but even small ones like Ascon are infeasible to compute on retro hardware. But, Ascon is also designed to be secure by modern standards, which is a much higher threshold than I actually need.

Are there any (probably older/outdated) XOFs that are feasible to calculate on 16-bit hardware—or ideally, even 8-bit—that satisfy the next-bit test? Again, this will not actually be used for anything security-related, but if I'm building a specific PRNG into the language specification, I want it to be a good one that passes statistical tests.

EDIT: Some more details:

  • This is a language intended for writing games in, so security isn't a concern at all—I don't doubt that a dedicated attacker nowadays could break any security implemented on a C64 or Amiga!
  • But related languages have suffered from poor-quality PRNGs making games unbeatable, because e.g. looking at the lowest bits of the initial output makes a certain random event never occur or always occur. So passing statistical randomness tests is my biggest concern, and using a CSPRNG (even an outdated one) seems like the easiest way to do that.
  • Right now, I'm starting with a 16-bit system with 64 KiB of RAM. It would be nice to eventually get it working on 8-bit systems like the Commodore, but I'm starting with less constraints to make sure it can work at all. So the problem with Ascon is how long it takes to do the permutations, not storing the state in between.
Draconis
  • 261
  • 1
  • 9

3 Answers3

14

It sounds heretical on a cryptographic site, but you could just use RC4; that processes 8 bit 'words', and hence can be easily implemented on your hardware (which is not surprising - it dates back to when your hardware was state-of-the-art).

And, it is quite simple and efficient. While there are known distinguishers, those are fairly subtle (much subtler than any standard statistical test).

poncho
  • 154,064
  • 12
  • 239
  • 382
9

A lot of the AES candidates were specifically designed to maintain performance on smaller word architectures. In particular, Rijndael, the eventual winner went into a lot of detail about how it could be optimised for 8-bit architectures. There have been one or two papers looking at 16-bit implementations of AES for embedded applications, so I would consider just using AES-CTR.

Looking at the appendix of this paper comparing the efficiencies of cryptographic implementations on 8-bit architectures, you may also wish to consider the NSA SIMON and SPECK designs.

Daniel S
  • 29,316
  • 1
  • 33
  • 73
3

I would use Keccak-400 as it will use lanes of 16 bits. You should be able to find reference implementation (E.g. here), after that, you can easily build a XOF at the required security level. For example you can have a capacity of 256 bits and a rate of 400-256=144 bit and you will have 128 bit security.

Ruggero
  • 7,339
  • 33
  • 42