Return to Answer

In the context, one option would be AES in CTR mode with the XOR between ciphertext and keystream on the PC side (saving most of the bandwidth in the PC to Low-level processor direction). CTR mode allows direct access to any portion of the plaintext. AES is easy to implement on an 8-bit CPU, reasonably fast, and low on resources. As a bonus, protecting AES against side-channel attacks is well studied (although the weakest point likely will be different: obtaining the whole plaintext or keystream once, and storing that).

If AES is not fast enough, and about 260 bytes of RAM are available, and the plaintext can be divided into relatively large blocks (like 1024 bytes or more), and we replace recent by tried and tested, there is RC4 with an appropriate key setup (e.g. append 32-byte key to 8-byte block address, use that as the RC4 key, discard the first 256 bytes produced by RC4).

Update: beware that both methods allow the user to change bits of plaintext just by flipping the corresponding bits of ciphertext; see that other answer if the integrity of plaintext is required (this also requires assuming the program on the PC is not altered).

In the context, one option would be AES in CTR mode with the XOR between ciphertext and keystream on the PC side (saving most of the bandwidth in the PC to Low-level processor direction). CTR mode allows direct access to any portion of the plaintext. AES is easy to implement on an 8-bit CPU, reasonably fast, and low on resources. As a bonus, protecting AES against side-channel attacks is well studied (although the weakest point likely will be different: obtaining the whole plaintext or keystream once, and storing that).

If AES is not fast enough, and about 260 bytes of RAM are available, and the plaintext can be divided into relatively large blocks (like 1024 bytes or more), and we replace recent by tried and tested, there is RC4 with an appropriate key setup (e.g. append 32-byte key to 8-byte block address, use that as the RC4 key, discard the first 256 bytes produced by RC4).

Update: beware that both methods allow the user to change bits of plaintext just by flipping the corresponding bits of ciphertext; see that other answer if the integrity of plaintext is required (this also requires assuming the program on the PC is not altered).

In the context, one option would be AES in CTR mode with the XOR between ciphertext and keystream on the PC side (saving most of the bandwidth in the PC to Low-level processor direction). CTR mode allows direct access to any portion of the plaintext. AES is easy to implement on an 8-bit CPU, reasonably fast, and low on resources. As a bonus, protecting AES against side-channel attacks is well studied (although the weakest point likely will be different: obtaining the whole plaintext or keystream once, and storing that).

If AES is not fast enough, and about 260 bytes of RAM are available, and the plaintext can be divided into relatively large blocks (like 1024 bytes or more), and we replace recent by tried and tested, there is RC4 with an appropriate key setup (e.g. append 32-byte key to 8-byte block address, use that as the RC4 key, discard the first 256 bytes produced by RC4).

Update: beware that both methods allow the user to change bits of plaintext just by flipping the corresponding bits of ciphertext; see that other answer if the integrity of plaintext is required (this also reqires assuming the program on the PC is not altered).

In the context, one option would be AES in CTR mode with the XOR between ciphertext and keystream on the PC side (saving most of the bandwidth in the PC to Low-level processor direction). CTR mode allows direct access to any portion of the plaintext. AES is easy to implement on an 8-bit CPU, reasonably fast, and low on resources. As a bonus, protecting AES against side-channel attacks is well studied (although the weakest point likely will be different: obtaining the whole plaintext or keystream once, and storing that).

If AES is not fast enough, and about 260 bytes of RAM are available, and the plaintext can be divided into relatively large blocks (like 1024 bytes or more), and we replace recent by tried and tested, there is RC4 with an appropriate key setup (e.g. append 32-byte key to 8-byte block address, use that as the RC4 key, discard the first 256 bytes produced by RC4).

Update: beware that both methods allow the user to change bits of plaintext just by flipping the corresponding bits of ciphertext; see that other answer if the integrity of plaintext is required (this also requires assuming the program on the PC is not altered).

In the context, one option would be AES in CTR mode with the XOR between ciphertext and keystream on the PC side (saving most of the bandwidth in the PC to Low-level processor direction). CTR mode allows direct access to any portion of the plaintext. AES is easy to implement on an 8-bit CPU, reasonably fast, and low on resources. As a bonus, protecting AES against side-channel attacks is well studied (although the weakest point likely will be different: obtaining the whole plaintext or keystream once, and storing that).

If AES is not fast enough, and about 260 bytes of RAM are available, and the plaintext can be divided into relatively large blocks (like 1024 bytes or more), and we replace recent by tried and tested, there is RC4 with an appropriate key setup (e.g. append 32-byte key to 8-byte block address, use that as the RC4 key, discard the first 256 bytes produced by RC4).

In the context, one option would be AES in CTR mode with the XOR between ciphertext and keystream on the PC side (saving most of the bandwidth in the PC to Low-level processor direction). CTR mode allows direct access to any portion of the plaintext. AES is easy to implement on an 8-bit CPU, reasonably fast, and low on resources. As a bonus, protecting AES against side-channel attacks is well studied (although the weakest point likely will be different: obtaining the whole plaintext or keystream once, and storing that).

If AES is not fast enough, and about 260 bytes of RAM are available, and the plaintext can be divided into relatively large blocks (like 1024 bytes or more), and we replace recent by tried and tested, there is RC4 with an appropriate key setup (e.g. append 32-byte key to 8-byte block address, use that as the RC4 key, discard the first 256 bytes produced by RC4).

Update: beware that both methods allow the user to change bits of plaintext just by flipping the corresponding bits of ciphertext; see that other answer if the integrity of plaintext is required (this also reqires assuming the program on the PC is not altered).