Genuine Crypto!

[Ian G Batten]

On 18 May 2006, at 19:23, John Brazier wrote:

> Ian stated:
>
>> If you had 1024 or so bits available to store `something' that  
>> would be
> useful for a rainy day, what would you store?
>
>> But if I've only got 1024 bits, is that enough?   And is RSA viable
>> using a small PowerPC embedded processor?
>
>> Any suggestions?  In the absence of anything better, I'm going to put
>> 1024 bit RSA keys on the boards and record the public keys locally.
>
> 1024 bits would usually be regarded as short for RSA now, though I  
> believe
> it would be appropriate for an elliptic curve system (which should  
> also be
> more appropriate for a light processor). Of course - it depends on  
> what the
> value is of the information you're protecting!
>


Minimal.  And remember, these keys would only be used to bootstrap  
other keys, and the `public' keys would only be public in the sense  
that they'd be stored in my ERP system.  My thinking was that the  
only meaningful attack would be one that could perform a man-in-the- 
middle attack within the timescales of a comms protocol, which is  
about 30s timeouts.  I think that given no access to the public key,  
no access to the private key, a few hundred bytes of cyphertext and  
30 seconds, 1024 bits is enough for the lifespan of the product.  But  
the issue of processor performance is a good one, so I'll look at  
Elliptic Curve.


> If it's ID you are worried about, how about using 160 or 256 bits  
> for a hash
> of the serial number (plus a salt, and perhaps other parameters  
> such as a
> second hash of the memory contents)? You could then use the rest  
> for, say,
> an AES key and a base/modulus for Diffie-Hellman (giving yourself  
> all sorts
> of possibilities!).

It occured to me that another possibility would be to generate a  
distinct base/modulus for each card and record those.  Then when we  
come to establish a secure channel in umpty years' time, the ability  
to establish it is proof of the far end's authenticity.

ian