I'm looking for a cryptographic algorithm that allows encrypting only 8 bits of data in a block. Is there any such algorithm that is considered secure?
The reason I'm asking is because I have to encrypt and decrypt the data contained in SPI Flash memory (the BIOS flash), and I need it to be really fast to get the cyphertext and give the plaintext to the CPU. The CPU can fetch 8 bits at a time, and can jump to a different address each time.
First of all, there's no such thing as a secure 8-bit block cipher, at least not as such things are conventionally used.
That's because there are only 256 possible values for an 8-bit byte, and a block cipher will map each of these values to a different fixed value. Thus, an attacker who can even occasionally guess the unencrypted value of some bytes (or, worse yet, can control the bytes to be encrypted) can easily learn which unencrypted byte corresponds to many, if not all, the encrypted bytes. In fact, even if the attacker only had access to the encrypted data, they could most likely still decrypt much of it simply by comparing the frequencies of different encrypted bytes, and the patterns in which the bytes occur, with known examples of typical BIOS contents.
If you had a fast, key-agile block cipher, you could in theory make this attack a lot harder by using a separate key (typically, generated "on the fly" from a master key and the byte address) to encrypt each byte. If the data never changed, and assuming that the keys were effectively independent (or at least independent enough to avoid related-key attacks), this could be secure; indeed, even if the data did sometimes change, all that observing multiple versions of the encrypted data would leak is whether the value of a particular byte matched an earlier value of the same byte.
Alas, I'm not aware of any fast, key-agile 8-bit block ciphers with a good track record of resisting cryptanalysis. (That doesn't prove that there aren't any, of course.)
However, you could instead go further, and encrypt each bit separately. Of course, there's only one possible 1-bit block cipher*, and it has only two possible keys: 0, which leaves the bit unchanged, and 1, which flips it. Thus, "1-bit block cipher" is really just a fancy name for XOR.
You still need to generate an independent key bit to XOR each of your data bits with, of course. For that, you need a stream cipher. In particular, since you say you need random access to the data, I'd suggest using a (conventional, wide-block) block cipher in CTR mode as your stream cipher.
As long as your data never changes, XORing it with a keystream generated by a conventional block cipher (e.g. AES) in CTR mode actually is semantically secure.
With CTR mode, you can generate any (e.g.) 128-bit block of the keystream any time you like, without having to generate all the preceding bits of the keystream first. As a simple performance optimization, consider caching the most recently computed keystream block in a register, just in case the next byte to be requested falls inside the same block. You could even optimistically start pre-calculating the next block before you actually need it, if you expect a lot of sequential reads in practice.
However, note that CTR mode (and stream ciphers in general) may be insecure if the data can change. In particular, as soon as an attacker learns both the encrypted and the unencrypted value of a given byte (or even a given bit), they'll learn the corresponding bits of the keystream. Further, even just observing two different encrypted values read from the same address will reveal the bitwise difference of the corresponding plaintext values.
Avoiding such attacks is the domain of disk encryption theory, and can get rather tricky in general, especially if you demand that no extra storage space be used.
However, if you can set aside a bunch of (say, 16 or 32) bits in each Flash memory block to store a write counter, and are fine with the value of this counter being leaked if someone inspects the encrypted data, there may be a simple solution: just use this write counter together with the byte address (truncated to cipher block boundaries, of course) as the counter value. That way, every time a Flash block is rewritten, the keystream for that block changes completely.
Of course, this means that you can't store data in the bits used for the counter, which, in particular, could complicate addressing, since the "logical block size" seen by the CPU will be slightly smaller than the physical block size of the Flash memory. There are various tricks you might be able to use to get around that, but they depend on the specs of the system you're working with.
Also note that CTR mode encryption (like stream ciphers in general) is particularly malleable, and therefore potentially culnerable if an attacker may modify the encrypted data in the Flash memory. To prevent such attacks, you may also want to store a (possibly per-block) MAC of the encrypted data, and verify it before allowing any data to be read. (Note that the MAC input should include the block number and the write counter / IV, to protect against attacks involving swapping blocks or resetting the counter. If you're using per-block MACs, you may also wish to compute a global "MAC of MACs" to prevent an attacker from mixing blocks from different versions of the data.)
*) Technically, there are two 1-bit block ciphers, but they differ only by a trivial rearrangement of the key space.
An 8-bit block cipher would be practically unusable.
A $b$-bit PRP can be used fewer than $2^{b/2}$ times before it's distinguishable from PRF and this limit carries over approximately as is to block ciphers. So you could use it (less than) 16 times per key, i.e. for 128 bits of data. If you had a 128-bit key you might as well use it as a one-time pad.
If you just need to be able to encrypt/decrypt data in 8-bit increments, some kind of stream cipher could work.
