Re: Implementing byte stream cipher

Joseph Ashwood wrote:
<hugonz@xxxxxxxxx> wrote in message news:1146088530.492367.72740@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi all,

I am proficient programming microcontrollers, and I want to implement
some form of stream cipher for encrypting serial communications.

What I would like to do is have two serial ports connected to one chip,
and then have plaintext on one port and ciphertext on the other. It
need not be 1bit encryption, an octet at a time will do. Another chip
would be doing decryption.

I can have a symmetrical key hidden in the chip and it would be
impossible to extract it.


Wanna bet? The history of extracting "impossible to extract" keys is substantial and proves time and time again that sooner or later if they really want your key they will get it.


I have considered using TEA, but how can I go
from block to stream?


I recommend against TEA, it's been broken, it's not the worst choice, but it's not the best. The general recommendation is to use AES, ther may be better solutions based on your particular environment but you haven't given enough detail..

As to converting from block to stream, use counter mode (http://csrc.nist.gov/CryptoToolkit/modes/workshop1/papers/lipmaa-ctr.pdf).

Since you're talking about a piece of hardware with a fixed key there are a number of things you need to be aware of:
1) Any cipher mode becomes weaker after 2^(blockSize/2) blocks, for a 64-bit cipher this is 32GB

No. Wrong.

, for a 128-bit cipher this is 256,000 PetaBytes
(295,147,905,179,352,825,856 bytes). Either way you need some mechanism to roll-over the key.
2) You need some way to synchronize IVs. This may sound simple but it can be difficult if your connection is only 1-way
3) You really should provide a Message Authentication Code as well, very often this is at least as critical as message authorization
4) If you use one of the secure microcontrollers already available your dev time will be shorter (Atmel in particular has several)


I understand this may be extremely basic, so
pointing to resources is appreciated, too.


Actually what you're attempting will be extremely difficult to get usable and secure. The packetized design (which you'll need for IV sync) is extremely simple, but making sure the implementation is accurate, includes no bugs (of omission or comission) is virtually impossible.
Joe


.

Relevant Pages

  • Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
    ... the original KEY so both parties can generate the stream. ... If you are expanding the key without "any extra entropy" it must ... I do not know any cipher there it would make sense for this not to be ...
    (sci.crypt)
  • Re: An Encryption Method
    ... > that PRBG will be the part of the scheme to be attacked. ... Wouldn't a cipher ... > that can deal with any arbitrary bit stream as a plaintext be more ... etc. has NO relationship to the original message. ...
    (sci.crypt)
  • Re: Stream or Block cypher ? need your help to clarify ...
    ... different implementations of one cryptosystem ... A cryptosystem encrypting one bit at a time is clearly a stream ... When you stop calling the cryptosystem a stream cipher is ...
    (sci.crypt)
  • Re: A basic cryptanalysis question
    ... Take two general cipher that use independent ... > All encryption schemes are bijective, less you wouldn't be able to decrypt. ... You can also generate key stream in advance ... Where as BICOM mode is a block oriented transform where you cannot seek, ...
    (sci.crypt)
  • Re: Terminology question
    ... >> mean XORing the plaintext with the output of a PRG, ... >> a stream", in which case a block cipher in CBC mode is a stream ... RC4 is the only byte-oriented stream cipher I know of. ... Is this the same WAKE you speak of? ...
    (sci.crypt)