AES encryption algorithms FPGA - free "working versions"  - Page 1
Forum section: electronics / general

author: rakeshm55
author_rank: Regular Contributor
timestamp: July 18, 2014, 11:30:42 am
content: Hi,i am evaluating AES algorithm implementation to choose a functional with low resources and fair enough good throughput.I tried one available on open cores. I could to some extend evaluate the key expand module(verified the key expand table for Cipher key) but failed at the cipher encoder module I get the wrong outputs . While probing i could observe a mismatch in first xor sequence itself.Input = 32 43 f6 a8 88 5a 30 8d 31 31 98 a2 e0 37 07 34Cipher Key = 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c as in the AES doc.Implementation from Jerzy Gbur. In the site it is tagged as stable design though.http://opencores.org/project,aes_128_192_256,downloadsHas any one tried out this design??Is there any free versions of working AES core implementations available?? ... preferably VHDL.....

author: legacy
author_rank: Super Contributor
timestamp: July 18, 2014, 12:35:25 pm
content: although people are claiming OpenCores as the cool of the day, i haven't found anything useful from them yet, just bullshit(1)(1) people supporting the good thesis "OpenCores is good and useful for everything that they will not put into anything of real usage"

author: dfmischler
author_rank: Frequent Contributor
timestamp: July 18, 2014, 12:42:58 pm
content: Beware to keep timing key-neutral. It is too easy to build an implementation (in software, at least) that can leak key bits by atiming side-channel attack. I think this means you have to do a thorough analysis for any implementation you might choose. Regardless of whether you build it, buy it, or steal it.

author: amyk
author_rank: Super Contributor
timestamp: July 18, 2014, 01:07:45 pm
content: All the operations in AES are constant-time, and the number of them don't change depending on bits of the key, so the only timing attacks known are due to implementations that do more "clever" things to try to improve speed, like caching. A dumb hardware implementation will naturally be constant-time. It's the power/EMI-based attacks that are more difficult to prevent.

author: rakeshm55
author_rank: Regular Contributor
timestamp: August 13, 2014, 12:53:05 pm
content: Hi ,After some effort i could get an AES core functioning.....Now my plan is to use it for a wireless application.....I have read some articles on block to stream cipher and now want to check the OFB cipher.... other suggestions are also welcome....i presume stream cipher like OFB would avoid restriction on data block size of each packetNow1. how to sync the IV (initial vector) between the transmitter and receiver.....2. For every packed do I need to send the IV too...3. How frequent do i need to sync IV....Please help

author: legacy
author_rank: Super Contributor
timestamp: August 13, 2014, 01:55:37 pm
content: i'd like to help but i am not skilled enough about this topic, in my case i have bought a cheap SoC which comes with a built in WIFI engine (with also the RF electronic part), that is a linux SoC and …. to be honest i had a lot of troubles to make the kernel's device driver (MADwifi compliant, 802.11) working, so i assume WIFI is a very very complex things. BTW it is the cheapest and simplest solution i found to embed WIFI in my application: it costs only 10 euro, and it could also do ssh-tunneling.Sorry, but i can only say go go, rakeshm55

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 13, 2014, 02:18:08 pm
content: Quote from: rakeshm55 on August 13, 2014, 12:53:05 pmI suggest that if you actually need security you do not try to design your own crypto protocol. There are many traps for the unwary.OFB is not generally considered the way to go.IVs are normally sent with each "packet". The receiver really doesn't care what it is. You generally want to be sure you do not repeat an IV before changing keys (especially if the plaintext at the start of each "packet" is knowable).You said "wireless". If this is based on standard technology (e.g. 802.11) then I recommend you be standard (perhaps leave some of the fall-back stuff out of your implementation). Use the standard crypto approaches that have been designed by professional cryptanalysts, and other knowledgeable people, and extensively studied for weaknesses. Amateur crypto does not have a good track record.

author: dannyf
author_rank: Super Contributor
timestamp: August 13, 2014, 03:29:00 pm
content: Not exactly for FPGA but ARM publishes a set of encryption routines, AES included, in CMSIS. Those routines are written in C and I assume it is not that difficult to port it to your FPGA.

author: bwat
author_rank: Frequent Contributor
timestamp: August 13, 2014, 03:47:55 pm
content: Quote from: dfmischler on August 13, 2014, 02:18:08 pmSorry but this is typical garbage advice from psuedo-experts. There are as many good books written about cryptology as there are about any other topic of a typical maths/CS curriculum topic. In fact, I've found cryptology books to be of a higher standard than most other CS books. There is no excuse for it to be seen as ablack artonly to be practiced by high priests. Anybody can learn about it if they put in the effort.Quote from: dfmischler on August 13, 2014, 02:18:08 pmAs opposed to professional cryptography?http://money.cnn.com/2011/06/08/technology/securid_hack/http://cryptome.org/jya/nsa-sun.htm

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 13, 2014, 04:23:47 pm
content: Quote from: bwat on August 13, 2014, 03:47:55 pmI agree that someone who really wants to learn it and do a good job can do so. But most people only do it once, and stop iterating on the design before they should, and declare themselves finished long before they have adequately tested their implementation. If the OP is doing this as a learning experience, or as a long-term career project, then he should dive in and make the most of it, and try to get his work reviewed by real experts. But if he has real world data that needs to be secured in a short time frame then he should probably use a proven protocol design, and maybe even an existing implementation.I have not done an implementation of my own since an early AH/ESP implementation based on RFC 1826/7/8/9 (1995). IIRC this was the very beginning of IPSEC, but didn't try to solve key management/distribution problems, etc. And that was very simple compared to what is being done now.QuoteYes. The track record for amateur crypto is significantly worse.

author: miguelvp
author_rank: Super Contributor
timestamp: August 13, 2014, 05:33:04 pm
content: I see nothing wrong in doing your own implementation if you follow the RFCs to the letter and deal with any conceivable edge cases.But that's not to say that an engineer should attempt developing their own algorithms, for good crypto you need a pretty high understanding of math, so it's more science than engineering.That said, I wouldn't trust a PhD in applied math to actually do the engineering part of it, even if they minor in computer science as they should to develop their own cryptology formulas.