Application Specific Integrated Circuit, so yes but no.
BTC ASIC chips are relatively simple sha-256 generators, whereas the chip from these MIT researchers is somewhat more complicated and can handle elliptic-curve public-key cryptography.
>Elliptic-curve cryptography relies on modular arithmetic, meaning that the values of the numbers that figure into the computation are assigned a limit. If the result of some calculation exceeds that limit, it’s divided by the limit, and only the remainder is preserved. The secrecy of the limit helps ensure cryptographic security.
I thought this was about a new kind of bignum acceleration, which has been a thing in some embedded systems for more than a decade. NXP had one on an el-cheapo SoC product already back in 2008-2009.
But no, this is apparently a generic ECC acceleration unit. It's still a bignum system but a somewhat more focused one. I would love to see some comparative benchmarks - not only on speed, but also on driver implementation complexity.
> “They move a certain amount of functionality that used to be in software into hardware,” says Xiaolin Lu, director of the internet of things (IOT) lab at Texas Instruments.
Hardware will always be king. It's the platform. Platforms should assume more responsibility, so that applications can assume less. It stands to reason that more applications would exist as we make it easier to build them.
Furthermore, less people can fuck up implementations if they are embedded in physical metals and rocks. Take more power away from the human, because the human cannot be trusted.
Maybe I'm just blind, but I can't find a link to the paper in the press release. Not that I would understand the hardware-specific parts, but I was just curious what software implementations they benchmarked against and how their elliptic curve algorithms were implemented.
I guess research chips like those end up serving as inspiration for the CPU designers of Intel/AMD/ARM etc. to evaluate which encryption instruction sets might be good to include in the future? Or are the fast vectorized multiplication operations and such already good enough to implement fast asymmetric crypto and no specialized instructions similar to AES-NI are needed? (Though of course this paper seems to imply that specialized hardware is useful)
About first part, I was very interested to read the original paper too but couldn’t find it in the article. This is so unprofessional of MIT Technology News.
The paper described in this article is not yet presented — it will likely be published in the proceedings of the cyber. But I found two relevant recent publications from the same lead author through Google Scholar:
Sounds interesting, I'd be curious to know the specs of the chip and any other features. I currently work with ATECC508A/ATECC608A, and they (finally) have excellent libs to use.
I'm curious if the price/power tradeoff here is worth it. They're making a bigger, more expensive chip that uses less power, but current solutions already use quite little.
I'm disappointed in the 1/400 power, 1/10 memory, 500x faster nonsense though...some actual specs would've been nice.
I can't even remotely see that energy efficiency of crypto is a real problem in IoT security and that adding another chip would solve anything.
Most problems in IoT security can be reduced to "nobody cares". If vendors can't be bothered to stop using default passwords, how are you gonna convince them that they add an extra chip to have more performant crypto? (Which almost certainly they'll use wrong anyway.)
That's no longer the problem. IoT manufacturers now worry about security, because they want exclusive ownership of your data and nobody turning their fridge cameras to a massive botnet (and PR hit). Encrypting all their traffic with device-specific and difficult to recover, hardware-based keys, will help them keep their devices safe. It's not a bad thing actually.
The one I'm intimately familiar with is in smart-metering with gas-meters. These things a battery powered and need to last for ~20 years on that battery. Simultaneously, they're dealing with financial data and communication, therefore all communications are encrypted & authenticated.
This device, although may be expensive tho... when you're dealing with 10's of millions of units, that cost really counts.
Hopefully someone (ARM) will snap start embedding this type of device within the Cortex-M range... (yes, I know, there already is crypto-acceleration, but more is better).
Doesn't ARM already have some crypto acceleration instructions on their chips? Aren't algorithms like AES done on smart cards? I've never heard of power requirements for cryptography being a real problem on modern processors. This seems like a solution in search of a problem.
> One of the computations to which the MIT chip devotes a special-purpose circuit is thus modular multiplication. But because elliptic-curve cryptography deals with large numbers, the chip’s modular multiplier is massive. [...] The MIT chip’s modular multiplier can handle 256-bits.
The advantage of ECC is that it's stronger for a given number of bits. Now if we have hardware acceleration, is that still valid?
16 comments
[ 3.1 ms ] story [ 43.3 ms ] threadBTC ASIC chips are relatively simple sha-256 generators, whereas the chip from these MIT researchers is somewhat more complicated and can handle elliptic-curve public-key cryptography.
I don't think the limit is secret.
But no, this is apparently a generic ECC acceleration unit. It's still a bignum system but a somewhat more focused one. I would love to see some comparative benchmarks - not only on speed, but also on driver implementation complexity.
Hardware will always be king. It's the platform. Platforms should assume more responsibility, so that applications can assume less. It stands to reason that more applications would exist as we make it easier to build them.
Furthermore, less people can fuck up implementations if they are embedded in physical metals and rocks. Take more power away from the human, because the human cannot be trusted.
I guess research chips like those end up serving as inspiration for the CPU designers of Intel/AMD/ARM etc. to evaluate which encryption instruction sets might be good to include in the future? Or are the fast vectorized multiplication operations and such already good enough to implement fast asymmetric crypto and no specialized instructions similar to AES-NI are needed? (Though of course this paper seems to imply that specialized hardware is useful)
Energy-efficient protocols and hardware architectures for transport layer security — https://dspace.mit.edu/handle/1721.1/111861
eeDTLS: Energy-Efficient Datagram Transport Layer Security for the Internet of Things — http://ieeexplore.ieee.org/abstract/document/8255053/
There are probably others. I look forward to seeing this paper when it's published though.
I'm curious if the price/power tradeoff here is worth it. They're making a bigger, more expensive chip that uses less power, but current solutions already use quite little.
I'm disappointed in the 1/400 power, 1/10 memory, 500x faster nonsense though...some actual specs would've been nice.
Most problems in IoT security can be reduced to "nobody cares". If vendors can't be bothered to stop using default passwords, how are you gonna convince them that they add an extra chip to have more performant crypto? (Which almost certainly they'll use wrong anyway.)
The one I'm intimately familiar with is in smart-metering with gas-meters. These things a battery powered and need to last for ~20 years on that battery. Simultaneously, they're dealing with financial data and communication, therefore all communications are encrypted & authenticated.
This device, although may be expensive tho... when you're dealing with 10's of millions of units, that cost really counts.
Hopefully someone (ARM) will snap start embedding this type of device within the Cortex-M range... (yes, I know, there already is crypto-acceleration, but more is better).
The advantage of ECC is that it's stronger for a given number of bits. Now if we have hardware acceleration, is that still valid?