I am trying to understand the difference between a crypto algorithm run in hardware from that run in software. From a previous post (see here: Difference between Hardware implemented algorithm and software implemented one?), I have a partial answer to the question. The answer is that running a crypto algorithm in software typically means that it is run on CPU or GPU while running a crypto algorithm in hardware means that it is run on FPGA or ASIC.

Here is my confusion: In both cases the algorithm is still passed as a set of instructions to the CPU, GPU, FPGA or ASIC. For me this means that the algorithm is compiled into a set of instructions that are passed to the underlying hardware (where hardware means CPU, GPU, ASIC or FPGA). So this means all four cases operate in exactly the same way-- which makes me wonder why some are called hard-ware-based and others are called soft-ware-based.

Would someone please clarify?

**This question is not a duplicate of the earlier question because I am looking for the operational differences between the two. To put it differently, lets say I have some data to encrypt. Can some one give me the step-by-step process from start to end of encryption for (1) the hardware case, and (2) the software case? I am not looking for the advantages and disadvantages of either; I am only looking for the differences in how they work.

  • 1
    $\begingroup$ As Difference between Hardware implemented algorithm and software implemented one? already asks that, and the answer you got here says nothing else than the already existing answer to the linked question (talking about software implementations up to integrated circuits in hardware), it’s not clear to me why this wouldn’t be a ”duplicate” of the Q&A you’ve linked to yourself. Maybe you could edit your question to clarify the difference; and why you think this is not a dupe? That would be great… $\endgroup$ – e-sushi Aug 12 '16 at 9:52
  • $\begingroup$ Perhaps to clarify a little more; I am interested in the operational differences between the two. Would I be correct to assume that in the hardware approach I just get data and pass it to the encryption hardware? And that for the software approach I get the data and pass it to my encryption program? $\endgroup$ – Minaj Aug 12 '16 at 16:55
  • $\begingroup$ @Minaj, yep that's how they work. You pass the HW / SW the key (or select a pre-stored one) and then pass the data to it and receive the cipher text (and vice versa). $\endgroup$ – SEJPM Aug 12 '16 at 17:34
  • 1
    $\begingroup$ how exactly do you pass the data and key to the hardware? $\endgroup$ – Minaj Aug 12 '16 at 17:48

The difference between "software-based" and "hardware-based" lies in economics.

From a formal, mathematical point of view, there is no qualitative difference: the algorithm takes some inputs (including a source of random bits, for randomized algorithms), and produces some output which is fully determined from the inputs. How exactly the output is produced from the input has no consequence at that level.

In practical terms, though, a new factor must be introduced, and it is of paramount importance: money. Whenever some application (here I am talking generically, not only of cryptography) is to be incarnated as a tangible system, this is done at some cost, both in building (chips, wiring, casing...) and in operating (power consumption, weight, size...). The builder will try to minimize the costs for a given performance target. Among the structural choices that can be made, a very fundamental one is to go either "software" or "hardware":

  • The software path is about using some general purpose chips, usually known as "CPU", that can implement a variety of behaviours through programmability: the CPU is a fixed circuit, but it can interpret instructions obtained from some memory storage. The CPU includes circuitry to perform a number of elementary, general purpose operations such as "adding two 32-bit integers".

  • The hardware path means building dedicated circuits for the task at hand, directly from transistors or elementary logical gates. The dedicated circuit will become an ASIC or an FPGA (the FPGA is like an ASIC that can be wiped and drawn again, which is nifty but increases power consumption and chip cost, while lowering the maximum operating frequency).

What is good in the software path is that general purpose CPU are a commodity produced in huge series, which makes individual prices quite low; making millions of the CPU also justifies, economically speaking, the use of finer engraving technologies, which again promote performance (higher operating frequency, lower power consumption). Moreover, the inherent versatility of a CPU allows reduction of the number of hardware pieces needed in a system, since a single CPU can perform a high number of functions.

What is bad in software is that the CPU is basically an interpreter for the operations to perform, and that is expensive. Compared to an equivalent circuit, for the same algorithm to implement, a CPU will mobilize orders of magnitude more transistors and/or clock cycles. Using a dedicated circuit may save a lot in that respect, or allow a substantial performance boost, or both, but at the cost of a much lowered versatility. Dedicated hardware also forfeits the economical benefits of huge production series; FPGA try to regain some of these benefits, but lose a bit on performance compared to ASIC.

So, for any given application, whether software or hardware is to be used depends on what the system is supposed to do. Normally, CPU are cheaper, except for very specialized applications where versatility is not really needed, and raw performance must be achieved (e.g. detectors in high-energy particle accelerators, that must process gigazillions of data each second; bitcoin miners, that need to compute SHA-256 all day long, and only SHA-256; pacemakers, that must reliably regulate the heart beat of a patient with as small energy consumption as possible).

This is the landscape. What does it mean for cryptographic algorithms? Cryptographers, when they design algorithms, do so generically, that is, without a specific application in mind. Well, really, they do have applications in mind, but they try to make their algorithms good for many applications. They recognize that the computing industry at large operates over the two main models, so they try to define algorithms that will be "performant" (fast, light, economical...) in either or both.

For a software-based algorithm, this means using the operations that are natively offered by CPU. An example of a software-based algorithm is the hash function SHA-256, which uses a lot of 32-bit integer additions.

An hardware-based algorithm will rather concentrate on operations that yield better dedicated circuits. The new SHA-3 function (aka "Keccak") is of that kind: it is built around bitwise logical combinations. For a CPU, a 32-bit ADD and a 32-bit XOR have the same cost: both are elementary operations that will be executed in the same time, with the same CPU resources. But when you go hardware, the two operations are quite different: the ADD requires many more transistors (because of the carry propagation) with a deeper circuit (again because of the carry propagation), so the XOR is cheaper (less transistors, so less silicon area), lighter in energy consumption, and faster (because of the shallower circuit). The consequence is that Keccak tends to be a hog in software but a screamer in hardware.

Of course, the full situation is complicated. There are many types of CPU, some of them (the GPU) being optimized for tasks that general-purpose CPU are traditionally bad at (in particular heavy parallelism). Some modern CPU now include circuits dedicated to some specific cryptographic algorithms (e.g. for AES encryption). Also, FPGA have some, let's say, inclinations toward CPU, in that they are reprogrammable, and some include CPU-like features (RAM blocks, or even embedded DSP/microcontrollers). This blurs the limits.

In fact, the notion of an algorithm being "for software" or "for hardware" must be understood as a broad design categorisation that describes more the initial intent of the cryptographer who produced the algorithm, than a cleanly defined, mathematical property. There are extreme cases, e.g. the former AES candidate RC6, which is purely software (it uses an integer multiplication, a very expensive operation in hardware, that just happens to be part of the panoply of most CPU because it is a very useful operation in many cases), and the old GSM phone encryption algorithm A5/1, which is extraordinarily efficient in hardware (can be done in less than 500 gates) and remarkably slow and cumbersome in software.

Most modern cryptographic designs try to be versatile, and while they are usually meant to be more software-friendly or more hardware-friendly, it is considered a good thing if they do not yield abysmal performance in either case. This is one of the reasons, maybe perhaps the main one, that made Rijndael the winner of the AES competition: while not extraordinarily performant on, say, a big PC, it was still decent on all envisioned software platforms and in dedicated hardware; ultimately, this allowed the inclusion of such dedicated hardware in modern lines of CPU.

An exception is password hashing functions, that purposely aim at being most efficient on the defender's platform (supposed to be a general-purpose PC, i.e. the epitome of software), and as slow and expensive as possible on dedicated hardware. The recent Password Hashing Competition revealed a number of candidates that try to achieve this goal either with extensive usage of RAM (a traditionally sore point in FPGA), or with heavy usage of multiplication (as in Makwa).


There are two reasons to have explicit hardware blocks: speed and power. The speed factor is more of an issue for data flow, and the power issue is more for embedded systems. If you have infinite power access, and are not IO constrained, there's not a reason to spend time and money putting an AES block into your CPU.

On the speed point, although this depends on implementation, you can get an answer out of an AES block in 8 cycles in some implementations. The software implementation of AES takes about 10k cycles (you can get this faster, but this is from a snapshot that I took).

On the power side of things, AES in hardware takes about 80x the power of a non-encrypted storage on a per-bit basis. This is an estimate, but you actually only get worse as features get smaller because a transistor's gain only decreases.

  • $\begingroup$ my question is not on the advantages of either approach. I just want an explanation of the operational differences between the two approaches. Does the hardware option not require me to write source code? How different is it from the software approach at the operational level? $\endgroup$ – Minaj Aug 12 '16 at 16:52
  • $\begingroup$ No, no code. You just set the key, set the data, and say "go". en.wikipedia.org/wiki/AES_instruction_set You then get the result. The structural architecture are identical (it's math), but the details are in the implementation. $\endgroup$ – b degnan Aug 12 '16 at 17:01
  • $\begingroup$ so the operating system gives me some API that takes data as input? $\endgroup$ – Minaj Aug 12 '16 at 17:33
  • $\begingroup$ @Minaj I cannot speak for a specific OS, but if the hardware supports it, you can use inline code to leverage the hardware if it exists. Usually when I use these sorts of things they are via "inline" statements in ASM that is wrapped with C. $\endgroup$ – b degnan Aug 12 '16 at 19:04

Software vs. Hardware. In software you'll have an API to a chosen library. With Hardware you also have an API specific to a chosen hardware implementation.

I.e., you will pass data to a crypo API and receive data back from it. Your choice of crypto provider will impact how much work you have to do outside of the crypto.

So, if the APIs are similar, operationally, they are the same. Differences come down to feature an performance.


All of these are some sort of PU (processing unit).

Most cryptography ASICs offer a wider range of combinations. For example, AES-NI or ARM Crypto Extension offer an AES encryption primitive for AES, but it does not offer a CBC(AES) or CTR(AES). You have to do those parts in multiple steps. For hashing algorithms like SHA1, they don't offer the HMAC primitive. Not only that, but the hashing primitive itself is split between 3-4 instructions.

There are other concerns. CPUs and GPUs are meant to do more general calculus, rather than an ASIC who has to do just the cryptographic ones. Because of cost you are kinda restricted on how fast you can implement that algorithm because it may mean a wider area on that chip and you have other things you must stick in that chip as well. Look at it from another perspective as well: CPUs nowadays run somewhere at 1.5GHz and above. Cryptographic ASIC do not usually go above 300-400MHz.

Cryptography on CPUs and GPUs are kinda of a cheap way implementation. A regular user who just browses the internet, or might have some encrypted storage, just needs some 100dollars processing unit that can do any task, and maybe a little accelerated crypto (instruction set), but he/she does not need another 200-300dollars chip just for cryptography.

If on the other hand you want to make a networking equipment (like a router, firewall) that embodies some form of cryptographic security and must run tens of GBs or hundreds of GBs you may want to spend those 300$ on that cryptography chip instead of buying a 2000dollars CPU with some crypto acceleration. That goes as well if you have a web service, such as web hosting, where you would like to leave the CPU to serve clients, no to do cryptography.

  • $\begingroup$ As an example the iOS Secure Enclave Processor has hardware accelerators for AES, EC, SHA. $\endgroup$ – zaph Aug 12 '16 at 16:58

There are hardware solutions such as Hardware Security Modules (HSMs) that perform the encryption with a key that is not available outside the HSM. The key may be created in the HSM and then referenced by an id from the outside. Thus the key is never available to be compromised.

With software encryption and even hardware assisted encryption the key is available to the CPU and can be compromised.


All previous answers forgot to mention one very important thing.

Software implementations work storing temporary data in memory of the device. When that device is for example a PC then security of that memory falls strictly on the operating system, and as we all know they can be broken pretty badly. It's possible that due to a bug inside the OS one process can read stack and heap of your decryption software making it much easier to break the key remotely.

Hardware implementation do not use memory. All intermediate states are stored as voltages on transistors inside the processing unit, and are not visible to the OS. Pretty much all side channel attack vectors on hardware implementations of cryptosystems require physical access to the encrypting device.

  • 1
    $\begingroup$ Yes but, if there's an OS breach, the data on the way to and from the hardware can be intercepted as well. I would be careful not to rely so heavily on the hardware's security that I forget there is still an OS handling the data in the clear at some point. $\endgroup$ – Les Aug 14 '16 at 18:29
  • $\begingroup$ Some hardware implementations of encryption algorithms have the key hardcoded into it's design. It's not visible to the OS, exactly for that reason. $\endgroup$ – Filip Franik Aug 14 '16 at 18:39
  • $\begingroup$ Additionally, software implementations might be more vulnerable to side-channel attacks, e.g. timing or cache-based attacks. Also, performance optimizations like lookup tables can lead to additional differences between the pure mathematical algorithm and actual implementations, which might add more weaknesses. Implementing crypto correctly is difficult. $\endgroup$ – tylo Aug 15 '16 at 11:55

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.