FPGA Cryptosystem

Interesting idea. That's my opinion.

Was there something more specific you had in mind? Maybe an actual question?

Oh, before you go too far with your idea, you might want to look up someone named Ralph Zimmermann and his idea, PGP. Just so you know all the issues involved.

Just so you know all

The only proper way to do cryptography, in mine. Keeping the keys on the same machine as the rest of your software is just asking for trouble.

I have a plan to eventually produce a device with a similar concept as the above, just in a RFID package and implantable. So that stealing your crypto keys becomes a tad bit more complicated. :)

Also, I am not sure about full-blown encryption on the crypto-device, but signing, verifying, and small time encryption (like asimetrically encrypting/decrypting simetrical keys and similar) are certainly viable.

Thanks for your reply. The issue I'm having is FPGA knowledge tbh. In resea rch mode, still trying to develop a good, real concept.

For example, an microcontroller project. I design and build my circuit on b readboards. Write (eg) embedded c and compile this into machine code using Keil uVision. I then insert my MCU in an in system programmer such as 'data man programmer' which will send the compiled machine code to the MCU which I can then insert my breadboard and see if the project works as planned!

With FPGAs, for the above mentioned project, would I would require two deve lopment boards connected to PC1 and PC2? My initial concept was to use 2 FP GAs resembling 2 flash drives.

PGP is very interesting - employing both asymmetric and symmetric encryptio n as well as digital signatures etc. I like the idea behind it. As its soft ware based, would it be difficult resembling it in hardware, say on FPGAs?

The main guideline I'm trying to stick is an FPGA based cryptosystem. Thank s

No, I don't think so. Since your proposed scheme is carried out at two locations at different times, no reason you can't do that for testing. Load the encryption config into the FPGA, and encrypt a message, store on the computer. Then, load the decryption config into the same FPGA, and decrypt the stored secret message.

I'm not enough of an expert to know. But, most encryption algorithms are based on XORs and simple integer arithmetic, so most likely it would not be hard at all to implement in an FPGA.

Jon

IMO there things to think about, in descending order of importance:

1. How you're going to get the data in and out of the cryptosystem
2. What are the constraints on performance
3. What crypto you're going to do

Don't get distracted about 3, that's the easy bit.

If you aren't too fussed on speed, I'd try and get a soft processor system up on the FPGA, for example NIOS II or Microblaze. If you already have an FPGA board, maybe there's a demo project. This will give you a familiar means of taking to something on the board and pushing data in and out, using something like C. There will be lots of what seems to be voodoo in getting there, but hopefully someone else has done the voodoo for you. You might learn something along the way too.

Then you can make peripherals that do crypto, and plug them into the system.

If you're doing it bare metal, you need to push data in and out yourself. The simplest way might be a parallel port connected to some pins on the FPGA, and maybe another parallel port to collect the answer. But you'd probably have to do some soldering for this - FPGAs don't come with handy parallel ports as standard (even ones routed over USB).

If you were making, say, a secure telephone then it would be easier because your board might have an ADC that would deliver regular audio samples that you could drive through your crypto and send down a wire to the other end. Then you can do everything in the FPGA without needing much help from a processor (key management is the tricky bit).

Once you have something that delivers a pile of bits in and collects a pile of bits at the output, then you can start thinking about crypto.

If you want to make something useful to other people, then you need to pick an application where FPGA is well suited. PCIe crypto accelerator for SSL, for example. But that's more complex and not good as a starter project.

Theo

Hi youngejoe,

On 11/22/2013 5:42 PM, youngejoe wrote: []

I would recommend in focusing on the real concept. Your friend Google has lots of hits for 'cryptography on fpga' (look at the scholarly articles section for state-of-the-art research in the field).

While your motivation can be anything, your research goal should be meaningful, but I believe your advisor can guide you here.

I would not even consider hardware for the time being. One thing is doing cryptography on a message, one thing would be doing cryptography 'on the fly', so performances may matter. So stick to the functionality first and get what you want, you will immediately see if your code fits or not into a specific target and then is just a matter of buying a demo board (typically research institutes have large discounts).

An algorithm sits on a piece of paper, the way it is implemented may vary a great deal.

If the aim of the project is to learn a bit of FPGA than I would go for something simpler, if the aim is to learn a little bit of cryptography than I would rather do it on software.

If the aim is to push cryptography further with the help of some hardware support than I would really invest time in knowing what other people/group are focusing on, what are the current challenges and which among them intrigues you the most.

HTH,

Al

p.s.: as a matter of fact, there are lots of 'crypto cores' on opencores.org, so you may also look at those.

The main advantage of the FPGA is speed. There are some algorithms that are slow in software, but can be be very fast in appropriate hardware, which can be implemented on an FPGA.

Some of my favorite FPGA problems involve generating configuration data specific to instance at hand. In cryptographic words, including the key in the hardware.

Many encryption algorithms are based on bit manipulation that is hard to do in software. With an FPGA, you can program the specific bit operations into the hardware.

Well, the other thing that is done with FPGAs is to do brute force attacks on systems designed to be too slow to attack in software.

I haven't followed it so closely, but I believe that DES is easy to break now with an FPGA, but one fix is triple-DES. The window between an FPGA break and people moving onto better encryption algorithms is fairly small, but sometimes worth doing.

Hard to say. I believe PGP was designed to be implemented in software. In some cases, a hardware (FPGA) implementation of an algorithm is very different from the software one. My favorite FPGA architechture is the linear systolic array. You might look that up and start thinking about algorithms that it makes sense for.

Sounds about right. You could implement an existing algorithm that is too slow for a given application now in software. That would be mostly learning about hardware and FPGA, and not so much about cryptography.

That is generally true in research, and especially in this case.

Many encryption algorithms now require some deep math to understand.

You could just implement and existing algorithm with a larger key, that is, larger than anyone thought about doing in software. (But as processors get faster, software key size also increases.)

As noted above, that mostly teaches you about FPGA and not so much about encryption. (Well, it might teach you about encryption, but won't advance the field much.)

-- glen

Am Freitag, 22. November 2013 17:42:15 UTC+1 schrieb youngejoe:

ion as well as digital signatures etc. I like the idea behind it. As its so ftware based, would it be difficult resembling it in hardware, say on FPGAs ?

PGP is a software that required a lot of effort to be completed. HW transfe r will be a compareable large task.

RSA is one of the algorithm implemented in PGP. Its an example of an not so trivial task to bring to HW.

Nevertheless I was part of a students group doing this task ~15 years ago ( chip for symetric and asymetric encryption, digital signature etc..) From w hat I remember RSA required a good bunch of math to bring an efficient impl ementation to HW even if you limit keys to 1024 bit. Implementing just one encryption algorith might be a good bunch of work, bu t if you think of key management, efficient IO transfer etc you have severa l projects.

regards Thomas