Tiny block ciphers for embedded systems

Look under the ciphers button on the top

In message , Uncle Noah writes

Why a block cipher? What's wrong with stream ciphers?

Nothing is fundamentally wrong ^_^

I am currently evaluating TEA, XTEA and raiden (focusing on the later two since they are not that weal as TEA). I encoding bitmaps, either 256-level greyscale ones, or 256-color (paletted color) ones. The visualization of the images is interesting in order to get a feeling on the quality of the algorithm. Of course serious testing is needed.

If you have any suggestions on stream ciphers (that are very small) i will be glad to hear.

Kind regards Nikolaos Kavvadias

Hi

thanks for the link. The A3A8 cipher is interesting and hadn't heard of (part of GSM?). What puzzles me are the modulo operations. Are these necessary (I mean can they be avoided)? These operations will affect performance, i wasn't thinking of using an actual divider even an integer only one.

Kind regards Nikolaos Kavvadias

What is the goal?

May be a XOR with 0xAA55 will do?

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

The primary goal is to search for ingenious techniques for encryption when performance (speed/area) is an issue. I have three tiny ciphers that qualify (for competing): TEA, XTEA, and raiden.

A secondary goal is to dedicate a few hundred machine instructions (on a typical RISC) for (embedded) security, and no more.

That's not very funny. Actually XTEA, raiden are so-so on visual appearance of encrypted images. Yet, LEX (a eSTREAM candidate) would produce an encrypted image, that resembles pure noise. So i'm looking for something close (but of course somewhat inferior, to the quality of LEX, Serpent etc).

Nikolaos Kavvadias

Hi all

does anybody have links to implementations of the SEA (Scalable Encryption Algorithm) cipher?

It seems that the authors' work covers my requirements.

Nikolaos Kavvadias

Conventional choices include Skipjack, 3DES, RC5. I wouldn't use COMP128 (A3A8); it's got problems. Be aware that security requires a heckuva lot more than just the choice of a decent cipher; you've got to get the mode of operation, key distribution, key management, protocol, and implementation right, too. The choice of cipher is the easy part. If you're in a situation where security is important, hire a crypto expert. If you're in a situation where security isn't all that important, I'd use an existing standard (e.g., 802.15.4's link-layer crypto, TinySEC, or one of the other standard schemes in this area).

Try CTR mode. Be sure to use a MAC (as with any mode of operation). Are you sure this is really necessary? My sense is that in most embedded systems, power is the critical resource, and the power to transmit a packet so vastly outweighs the cost of encryption that I would not have expected this parallelism concern to make any practical difference.

Why? That seems like a nutty requirement to me.

SNIP

Sounds dangerously! Even if it lookt visually random, it can be cryptographicall trivial

Self shrinking generators? The A5 (GSM) family is also seriously under attack. (see Barkan's work), but may be still economically (if the attack is more expensive than the value of the information or it is possible to obtain the key cheaper, like reverese-engineering, side-channel of rubber-hose attacks)

Wim

OK, this is exactly what I thought: the childish fascination about the secrecy :)

seed(key);

u16 VeryTopSecretStreamCypher(void) { u16 foo = rand(); while(foo--) rand(); return rand(); }

What is not funny is that you don't have a clue. Block cyphers are almost never used in ECB mode. Use CBC, CTR or CFB mode.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

For the OP - this is a joke. Iterating a pseudo-random sequence generator like this is much more likely to reduce the sequence length, and almost certainly won't increase it.

I'm sure VV knew that though.

Clifford Heath.

Ha ha (having a few laughs, farts included).

What i don't need is to pay some expert.

Then, if these ciphers are useless, why some many people or using them? They are OK for real-time (online) computations. Maybe you are focused on your field of work and don't know anything beyond your little planet world. I work extensively with more/less anything that falls under the title "Computer Science" (compilers, simulators, FPGA implementations of processors, theoretical models etc). Cryptography is anew thing to me but very easy to get grasp on the technicalities. What you are baffling about are the economics of this field.

E.g. XTEA has never been fully broken (26/32 cycles of 2-rounds have been but not all 32 rounds). So what are you baffling about "toy" ciphers?

Nikolaos Kavvadias

After all if you want REAL security, and not the crappy stuff you advocate for:

the only solution is steganography.

Even the writers of the "The Core" movie had this right. (There is a scene where a computer hacker -- in both ways this term is treated -- uses image-based steganography to hide messages).

Have you got any answer to that? Steganography is perfect for trusted recipients, and cryptography will never be since it can always be broken by "BRUTE FORCE". It is only a matter of computational power.

But this keeps your world spinning round, isn't it?

Nikolaos Kavvadias

Any cipher that failed to pass the above test would have been rejected by the crypto community long ago. This is not something you should be testing yourself. Pick a cipher that many experts have tested and spend your effort in assuring yourself that your implementation isn't buggy.

FYI I did a quick read on block modes of encryption.

All of them (including those you have mentioned) are easy to implement on my system, with very low overhead. Very easy to implement. Will do with evening coffee as i did all my encryption work to date so far in a single evening yesterday (I have an IQ of 133-138; when i was 8 years old it was measured to 180 but these days are gone :). That involves targeting my processor with all three algorithms in pure assembly. Writing all shell scripts, updating some other image manipulation tools i have written etc. All in a single evening. Before yesterday morning i didn't know about specifics on encryption only a few things about steganography.

I am a hardware engineer. I deliver designs.

And for the record, even on ECB the resulting image had no artifacts (it looked quite random). So the wikipedia page used some sort of wildly inefficient bozzo algorithm for encrypting the penguin. The used algorithm is probably TEA or some combination of the plaintext with LFSR/CA (quite worse than XTEA, but i can't be sure).

But looking random doesn't mean anything, this is at least something you will agree. Do you suggest any tests for battery (to prove randomness) or will you keep on attacking me for your own reasons? The diehard tests maybe?

I don't want to keep on quarreling.

NK

A lot depends on what kind of attack you are trying to guard against. A solution that would work just fine agains a casual snooper with some crypto skills may not work so well if your name is Osama Bin Laden and you are trying to hide information from the NSA.

Assuming that either stream or block ciphers are Ok...

If you really need security against an attacker with significant resources, AES (block cipher) is the logical choice. Don't have room? Make room.

If speed and small code size are all-important but you still want a reasonable level of security, look at GRAIN or maybe RC4

If you want something between the two, consider Trivium, Rabbit, XTEA or XXTEA.

AES

GRAIN

RC4

TRIVIUM

RABBIT

XTEA

XXTEA

In message , Uncle Noah writes

Why?

If you are looking at crypto you need to get it right. So you need informed expert advice.

Experts are not usually free.

-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ snipped-for-privacy@phaedsys.org

I appreciate your fair comment. It adds significantly to this thread.

Thanks again.

And thanks for the information!