Re: TEA for real-life embedded project?

David Wagner wrote:
Given such circumstances, would using the TEA cipher be unwise?
Unfortunately the project requires decryption speed which is hard to obtain
using AES.

TEA should be fine. It's unlikely that weaknesses in the TEA block cipher
itself are going to cause problems. It's much more likely that you will
use TEA incorrectly, or that your system will be insecure in other ways
(e.g., holes elsewhere in the system allowing the attacker to bypass the
crypto).

Despite your best intentions (and I can see where you're coming from)
it's probably not best to recommend people use non-standard crypto.
Even though TEA in [say] CFB mode would address privacy concerns just
fine AES in CTR mode is just as doable and actually a standard.

Aside from the ability to avoid rolling their own crypto (which
invariably they get wrong) they also introduce interoperability which
has more than just AESthetic (hehehe I'm punny) merits.

Sometimes a problem isn't properly spec'ed out. I mean if the thing
calls for 1Mbit/sec from an 8051 in all software, memcpy at best is the
only thing that can address that. I'm certain you wouldn't recommend
memcpy enhancing technology (TM) over AES or another standard cipher,
would you? If the project calls for a certain data rate then the
processor has to match it or have a coprocessor. Making up for it with
random crypto decisions is not the way to go.

.... recently had this fight with an embedded device manufacturer. I
think they've now moved to ARM cores [from an 8-bit core] to do their
PK crypto in realistic times instead of just using really small
security parameters.

Besides, Skipjack is pretty fast on most small processors and is at
least a standard [sort of]. :-)

Tom

.

Relevant Pages

  • Re: Quadruple Algorithms
    ... occurring" (a fatal flaw being found in AES, ... If you really want secure crypto use various layers of encryption ... with the output of one cipher feeding ...
    (sci.crypt)
  • Re: FUD about CGD and GBDE
    ... at the crypto layer. ... > yield its secrets only one sector at a time and CGD will spill all ... cheaper than cracking AES-256 assuming AES is good. ... You've added substantial complexity behind the scenes, ...
    (freebsd-hackers)
  • Re: DMSII Encryption - does it exist?
    ... encryption and is easy to implement. ... I was unaware of TEA, so thanks for pointing it out. ... Isn't there an implementation of DES that is used for the ... There are several public domain implementations of AES (the DES ...
    (comp.sys.unisys)
  • Re: Security Engineering vs. Crypto Academics... (was strengthening /dev/urandom)
    ... and weaknesses discovered in the crypto primitives. ... > (it's basically the sum of all of the reseeds plus the number of AES ... > blocks extracted from a particular Fortuna pool). ... I coneeded this is a problem and the proposed change from CTR mode to ...
    (sci.crypt)
  • Re: Current state of affairs in cryptanalysis: an observation
    ... cryptanalysis is at a standstill is TOTALLY WRONG. ... "The design and strength of all key lengths of the AES algorithm ... bode well if you're trying to make a name for yourself as a crypto ...
    (sci.crypt)