5
$\begingroup$

I see a lot of papers about FPGA implementations. For what kind of "concrete" application should we implement cryptographic algorithms on FPGA ? Which secured application require such a huge data processing performance ?

$\endgroup$
3
  • $\begingroup$ We have used FPGA for HDCP (This is cryptographic content protection protocol), where it is required to encrypt / decrypt 8Gbps in real time. This cannot be done in this data rate by regular software means. $\endgroup$ – Evgeni Vaknin Aug 27 '15 at 10:27
  • $\begingroup$ 8 Gbps = 1GB/s can be done by a modern CPU, if the algorithm is AES and the CPU supports AES-NI. For any other algorithm (except maybe an implementation of those really fast ARX ciphers) FPGA will always outperform in terms of price / speed and power efficiency. $\endgroup$ – SEJPM Aug 27 '15 at 10:34
  • $\begingroup$ Is an FPGA a 'Field Programmable Gateway Array'? $\endgroup$ – BanksySan Mar 25 '17 at 16:59
4
$\begingroup$

For what kind of "concrete" application should we implement cryptographic algorithms on FPGA? Which secured application require such a huge data processing performance ?

Well, FPGAs are ideal for a wide variety of applications, from high-volume applications to state-of-the-art products.

Imagine you are…

  • a bank, or
  • a Big Data service provider, or
  • a governmental institution, or
  • a military force, or

and you need to encrypt terrabytes of data in the shortest amount of time possible, because…

  • time is money, or
  • your clients want their Big Data to be stored safely on your servers via a double-encryption, or
  • a huge stream of intercepted metadata needs to be protected from the public eye, or
  • the enemy is near your last line of defense and you need to secure some data immediately, or

Whatever valid reason you might have to need cryptography “now” instead of “later”, you will want to choose the fastest option possible. In that case, it makes sense to use the (immensely) faster FPGA (and/or ASIC) solutions instead of hoping your CPU(s) will manage to handle the job in such a short amount of time.

From a civilian point of view, I guess the most understandable motivation as to why cryptographic algorithms are implemented on FPGA would be the economic factor. It should be noted that you burn less energy when using an optimized FPGA or ASIC implementation. This practically means you can “produce more work” while investing the same (or less) amount power as you would have invested when using your CPU(s).

Now, related to your comment:

Are there non cryptanalytical examples ?

Thinking about it, here’s a first, nice, practical, non-cryptanalytical example: cryptocurrencies. Just take a short look at the history of those folks… who evolved from “mining their coins” (read: creating their proof of work via cryptographically secure hashing algorithms) with CPUs, then switched over to GPUs because they were faster and more energy efficient, and ended up using specialized ASICs.

Besides that, there are – of course – other non-cryptanalytical examples. As a matter a fact, “An FPGA Implementation and Performance Evaluation of the. AES Block Cipher Candidate Algorithm Finalists” already hints at that, and a short search engine quest would have provided you with ample commercial product examples.

For your convenience, here are two randomly picked, non-cryptanalytical product ranges:

I’m sure you’ll be able to find more examples using your favorite search engine…


EDIT (Lazy-Friday Bonus):

For the fun of it (and because I had a lazy friday afternoon), I whipped up two non-optimized C proggies just to show you something practical…

comparing a brute-force birthday attack on SHA256 with 3 CPU contra 1 GPU

See that speed (and hash-count) difference?

Now imagine the increase that could be gained when using a field programmable gate array (FPGA). What might take years for one person, might just be a matter of hours for another.

Such speed differences are like a coin with two sides: benign users can enhance security in many areas, while malign users can attack faster (making some attacks feasable in the first place.)

That’s one of the reasons cryptographical FPGA solutions are of interest… no matter which side of the coin one prefers or chooses.

$\endgroup$
0
1
$\begingroup$

Here is one example:

COPACOBANA

A Codebreaker for DES and other Ciphers

COPACOBANA, the Cost-Optimized Parallel COde Breaker, is an FPGA-based machine which is optimized for running cryptanalytical algorithms. COPACOBANA is suitable for parallel computation problems which have low communication requirements. DES cracking is such a parallelizable problem: an exhaustive key search of the Data Encryption Standard (DES) takes no longer than a week on average with COPACOBANA…

source: opacobana.org

$\endgroup$
1
  • 1
    $\begingroup$ Thanks very much for this example. Are there non cryptanalytical examples ? $\endgroup$ – Dingo13 Aug 19 '15 at 8:21
0
$\begingroup$

FPGA implementations give you a cryptographic coprocessor in a small/embedded device without its own CPU. They would be ideal in applications such as smart meters or other "internet of things" devices. Among other things they can function as hardware security modules, where keys are generated in the device and never leave it.

Encrypted USB sticks and hard drives with an AES FPGA processor exist, this may even be required for FIPS certification.

People still make stupid mistakes, though…

Screwing up security – USB stick with hardware AES encryption

Whether you are talking about certification or 256-bit AES, even the best encryption provides no protection if an additional function accidentally renders the password vulnerable.

The MXI Security Stealth MXP USB memory stick tested by Objectif Sécurité, is not a USB stick with just run-of-the-mill security features. Rather, it is FIPS-140-2 certified, which means that after thorough testing, the US National Institute of Standards and Technology (NIST) declared it safe for use by federal US authorities …

source: h-online.com

$\endgroup$
2
  • 2
    $\begingroup$ In my experience, Smart meters or other "internet of things" devices are power and cost critical, and thus typically do NOT use FPGAs, which are often power-hungry and more expensive than CPUs. $\endgroup$ – fgrieu Aug 19 '15 at 10:45
  • $\begingroup$ Correct - perhaps "embedded devices" would have been a better description. Though, looking at the "security" of some of today's IoT devices and protocols, you wish they did spend the money for a decent crypto chip ... $\endgroup$ – user2552 Aug 20 '15 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.