We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Please tell me how to achieve 1024 bit and above Arithmetic operation using 8, 16, 32 bit microcontroller. The Arithmetic operation consist of Addition, Subtraction, Multiplication, Division, Modulo.
Not just any "higher"-bit arithmetic on any "lower"-bit microcontroller - but why specifically 1024-bit aithmetic on an 8-bit micrcontroller?
A single 1024-bit value is 128 bytes - that is the entire DATA space of an 8051!
It really doesn't sound like a sensible thing to be doing on an 8-bit processor!
I want 1024 bit algorithm for diffrent controller like 32 bit ARM controller, 16 bit c166 controller, 8 bit higher end controller like renesas, etc where RAM size is of 2 KB.
i need to write a flexible code which will support RSA encryption technique with variable key length. ( 32 bit to 1024 bit)
"i need to write a flexible code which will support RSA encryption technique with variable key length. ( 32 bit to 1024 bit)" There are no such thing as any 32-bit RSA. You need ridiculously large keys to get any security. A 32-bit or 64-bit key would be cracked in almost no time. 1024 is already questionably small and the recommendation is 2048 bits or more.
Anyway - as long as the processor has RAM enough, the algorithms will just contain loops to perform the calculations with an arbitrary number of bits. There are many big number libraries available, and it is also quite easy to implement your own code for the few operators you need.
Note that you should also pad the data, to reduce the probability of some specific attacks being able to quickly crack even quite large key sizes.
Another important point: when designing your own cryprographic system, you have to know exactly what you are doing. It is too easy to leave a hole which will compromise the overall security, and no amount of bits in the keys used will help that.
"It really doesn't sound like a sensible thing to be doing on an 8-bit processor!"
it really doesn't sound like a sensible thing to be saying for any "computer programmer".
"It is too easy to leave a hole which will compromise the overall security, and no amount of bits in the keys used will help that."
Such errors happens regularly even when the people involved do know what they are doing.
And as Andy notes, I would stay away from 8-bit or 16-bit processors if there is a need for decent cryptographic security.
I don't think I would go for any processor that can't run the OpenSSL code. Note that OpenSSL can be configured, so there is no need to include all algorithms.
There may be security holes in the OpenSSL package, but no home developer or "normal" company can hope to match OpenSSL when it comes to code quality or amount of security reviews.
Flexible means i will keep provision in the design to generate variable length of RSA encryption. To end customer, i will give fix bit (which is from 32 to 1024) encryption which practicle feasible depending on the complete hardware of the system.
i came across one white paper for 1024 RSA on 8 bit Microcontroller as below mentioned address. www.research.sun.com/.../crypto
As mentioned in the paper the author implemented various method like row wise multiplication, column wise multiplication, hybrid multiplication.
If some able to through more light on those technique , then it will be more helpfull.
I don't know about any encryption algorithm that is safe at only 32 bits.
And if you did mean RSA, the page en.wikipedia.org/.../RSA notes that 300-bit RSA can be cracked within a couple of hours with a single PC.
Anything less than 1024 bits is a joke, and you would like to use 2048 bits to have a bit of safety margin.
If you let your customers select a RSA size between 32 and 1024 bits, then the customers will look at you and then they will turn their back and walk away.
The trick here is that RSA is too slow for encrypting real data. So you only use RSA for negotiating and transmitting a crypto key for a symmetric chiffer. Then you switch to something more efficient. But it doesn't matter how efficient or safe that second chiffer is, if you do the key negotiation with so weak encryption that people can break it with standard software you can download from the net.
If the hardware can't handle secure key sizes for RSA, then you only have two options. Find another processor or find another algorithm. Stepping down to ridiculous key sizes is not an option. You will only fool yourself and the customer into believing that you have a safe system. Customers don't like to be fooled! Customers may even decide to sue you if they feel that you have intentionally misinformed them, or shown grave unprofessionalism. If you can't do 1024-bit RSA - don't bother.
http://www.keil.com/forum/docs/thread15287.asp
If a "computer programmer" is someone concerned only with the beauty of the source code, and not the implications on the underlying architecture, then I suppose they would not be talking about such trifling details...