The answer is, as always, it depends. I'll do my best to characterize the problem:
If we only care about minimizing logic gates we could use SERV, the world's smallest RV32 core, and run a bare metal ECDSA implementation on it. Let's use it without the M extension, so RV32I. I'm not sure what SERV's max clock frequency is, but assuming we configured it on the ice40 and it runs at 40 MHz I'm guessing a single ECDSA signature would take hours to comput.
Due to the math involved in ECC it is quite challenging to make a "hardware-only" ECC signer. The ones I've seen are effectively ECC accelerators with some kind of state machine or microcode to run the algorithm.
In the case of TKey we use picoRV32 configured as RV32ICZmmul (multiply without divide). We use the FPGA's DSPs to accelerate multiplication. On the TKey an Ed25519 signature takes less than a second, which we believe is acceptable for many use cases, and I'm willing to bet there is no Ed25519 signer that is more open source hardware and software than the TKey.
As GP points out using an FPGA is in fact an excellent way to mitigate various supply chain attacks. It's like hardware ASLR, to paraphrase bunnie in his CCC talk.
Thank you! BTW I assume you will support U2F, Crypto, etc in the future? or do you expect third parties to develop on it?
From a quick glance at the product it seems I should buy the unlocked to have full control of the device and in the future could be a device with a display and some more sensors and/or buttons to know what I am signing in?
I am currently in South America so waiting to travel to one of your shipping locations to buy several TKeys.
I believe we already have a U2F prototype for Linux. In general we are quite selective about which applications we take on development and maintenance responsibilities for.
Given that this is the most open source hardware USB authenticator we hope the communities that value this level of openness, design assurance and design verifiability will adopt the TKey and build whatever applications they need for it. Having said that we see lots of opportunities for us to make it easier for developers to build what they need.
If we only care about minimizing logic gates we could use SERV, the world's smallest RV32 core, and run a bare metal ECDSA implementation on it. Let's use it without the M extension, so RV32I. I'm not sure what SERV's max clock frequency is, but assuming we configured it on the ice40 and it runs at 40 MHz I'm guessing a single ECDSA signature would take hours to comput.
Due to the math involved in ECC it is quite challenging to make a "hardware-only" ECC signer. The ones I've seen are effectively ECC accelerators with some kind of state machine or microcode to run the algorithm.
In the case of TKey we use picoRV32 configured as RV32ICZmmul (multiply without divide). We use the FPGA's DSPs to accelerate multiplication. On the TKey an Ed25519 signature takes less than a second, which we believe is acceptable for many use cases, and I'm willing to bet there is no Ed25519 signer that is more open source hardware and software than the TKey.
As GP points out using an FPGA is in fact an excellent way to mitigate various supply chain attacks. It's like hardware ASLR, to paraphrase bunnie in his CCC talk.