FPGA Cryptosystem

[youngejoe]

Hello all

Proposed idea from my research to date:
Two FPGA encryption modules: Both will have an identical encryption algorithm; key management something I need to research further.
Bob has plain text message. He, perhaps through a GUI, sends the file to his FPGA 'cryptosystem' via USB which subsequently encrypts the data. Returns PC as cipher text, he sends data through unsecured network(leased lines, microwave etc).
Alice receives message, sends her module which then decrypts the message.

I have returned to college to up skill and as such have been given my final year project. I'm not looking for code, or to be spoon fed, merely looking to draw on peoples experience and opinion! I have completed embedded systems projects involving microcontrollers, microprocessors in the past but FPGAs are brand spanking new to me. I have agreed with my lecturer, who is happy to leave me 'at it' to stick to: FPGAs, cryptography & communications.
Again, I will not progress into looking for code etc etc, just honest opinions and suggestions, thank you for your time, jyoung Irl.

P.s I'm not in the NSA

 

[rickman]

On 11/21/2013 6:04 PM, youngejoe wrote:

Hello all

Proposed idea from my research to date:
Two FPGA encryption modules: Both will have an identical encryption algorithm; key management something I need to research further.
Bob has plain text message. He, perhaps through a GUI, sends the file to his FPGA 'cryptosystem' via USB which subsequently encrypts the data. Returns PC as cipher text, he sends data through unsecured network(leased lines, microwave etc).
Alice receives message, sends her module which then decrypts the message.

I have returned to college to up skill and as such have been given my final year project. I'm not looking for code, or to be spoon fed, merely looking to draw on peoples experience and opinion! I have completed embedded systems projects involving microcontrollers, microprocessors in the past but FPGAs are brand spanking new to me. I have agreed with my lecturer, who is happy to leave me 'at it' to stick to: FPGAs, cryptography& communications.
Again, I will not progress into looking for code etc etc, just honest opinions and suggestions, thank you for your time, jyoung Irl.

P.s I'm not in the NSA

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.

--

Rick

 

[Aleksandar Kuktin]

On Thu, 21 Nov 2013 18:18:36 -0500, rickman wrote:

On 11/21/2013 6:04 PM, youngejoe wrote:
Hello all

Proposed idea from my research to date:
Two FPGA encryption modules: Both will have an identical encryption
algorithm; key management something I need to research further.
Bob has plain text message. He, perhaps through a GUI, sends the file
to his FPGA 'cryptosystem' via USB which subsequently encrypts the
data. Returns PC as cipher text, he sends data through unsecured
network(leased lines, microwave etc).
Alice receives message, sends her module which then decrypts the
message.

[snip]

Again, I will not progress into looking for code etc etc, just honest
opinions and suggestions, thank you for your time, jyoung Irl.

P.s I'm not in the NSA

Interesting idea. That's my opinion.

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.

 

[hamilton]

On 11/21/2013 4:18 PM, rickman wrote:

On 11/21/2013 6:04 PM, youngejoe wrote:
Hello all

Proposed idea from my research to date:
Two FPGA encryption modules: Both will have an identical encryption
algorithm; key management something I need to research further.
Bob has plain text message. He, perhaps through a GUI, sends the file
to his FPGA 'cryptosystem' via USB which subsequently encrypts the
data. Returns PC as cipher text, he sends data through unsecured
network(leased lines, microwave etc).
Alice receives message, sends her module which then decrypts the message.

I have returned to college to up skill and as such have been given my
final year project. I'm not looking for code, or to be spoon fed,
merely looking to draw on peoples experience and opinion! I have
completed embedded systems projects involving microcontrollers,
microprocessors in the past but FPGAs are brand spanking new to me. I
have agreed with my lecturer, who is happy to leave me 'at it' to
stick to: FPGAs, cryptography& communications.
Again, I will not progress into looking for code etc etc, just honest
opinions and suggestions, thank you for your time, jyoung Irl.

P.s I'm not in the NSA

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.

http://en.wikipedia.org/wiki/Phil_Zimmermann

Just so you know all

the issues involved.

 

[youngejoe]

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.



--



Rick

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

For example, an microcontroller project. I design and build my circuit on breadboards. 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 'dataman 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 development boards connected to PC1 and PC2? My initial concept was to use 2 FPGAs resembling 2 flash drives.

PGP is very interesting - employing both asymmetric and symmetric encryption as well as digital signatures etc. I like the idea behind it. As its software 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. Thanks

 

[Theo Markettos]

youngejoe <cyounge28@gmail.com> wrote:
> The main guideline I'm trying to stick is an FPGA based cryptosystem.

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

 

[Jon Elson]

youngejoe wrote:

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

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.

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

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

 

[glen herrmannsfeldt]

alb <alessandro.basili@cern.ch> wrote:

Hi youngejoe,

On 11/22/2013 5:42 PM, youngejoe wrote:
[]
Thanks for your reply. The issue I'm having is FPGA knowledge tbh. In
research mode, still trying to develop a good, real concept.

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).

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.

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

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

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).

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.

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

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.

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

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

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.

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.

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.

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

 

[alb]

Hi youngejoe,

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

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

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.

[]

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

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).

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

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

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

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.

 

[Thomas Stanka]

Am Freitag, 22. November 2013 17:42:15 UTC+1 schrieb youngejoe:
> PGP is very interesting - employing both asymmetric and symmetric encryption as well as digital signatures etc. I like the idea behind it. As its software 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 transfer 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 what I remember RSA required a good bunch of math to bring an efficient implementation to HW even if you limit keys to 1024 bit.
Implementing just one encryption algorith might be a good bunch of work, but if you think of key management, efficient IO transfer etc you have several projects.

regards Thomas