Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #23028
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Efficient Implementation of Cryptographic Primitives on the GA144 Multi-core Architecture |
| Date | 2013-05-29 09:11 -0700 |
| Organization | Nightsong/Fort GNOX |
| Message-ID | <7xobbtlq9j.fsf@ruckus.brouhaha.com> (permalink) |
| References | <6576fefe-0315-4f88-a6d6-7db3b657caea@googlegroups.com> <6265faa3-a4fa-406b-b066-694389b5aba0@10g2000yqy.googlegroups.com> |
Mark Wills <markrobertwills@yahoo.co.uk> writes: > That was a really good paper. Probably the best paper yet that I've > read on the GA144. It does show that with patience and careful > planning some quite complex work is possible on the device, with good > power metrics to boot. I'd like to have seen comparisons with small and medium ARM MCU's (Cortex M0+ and M4) instead of 8-bitters. It felt almost like a rigged comparison, the way they did it. I did think it was cool that they did all the work of implementing those complex algorithms in the GA, but it mainly goes to show how near-impractical the GA is to actually program. On the other hand, the RSA benchmark made the GA look worse than it is, because real-world implementations use the Chinese Remainder Theorem (using the secret factors of the modulus) to speed up full-width exponentiation by 6x or so. They mention that as a future goal, which I guess means they found it too hard to finish in the effort available for the paper. RSA is done all the time on 8-bitters (smart cards) using auxiliary hardware on the chip, so the comparison is bogus in that regard too. If you want to compare RSA on an 8-bitter, it's more realistic to compare the type of 8-bitter that people actually use if they want to run RSA. > The document did kind of re-affirm my belief that the GA144 is lacking > in on-node memory. More communication paths between nodes would also help a lot. And for these crypto applications, some secure storage (eeprom) at some internal nodes. Then you could use an external program to drive the algorithm, while only the internal code could see the secret keys. > Also, I wonder if a 20-bit word size would be most appropriate; They are supposedly doing a 32-bit chip. > Very interesting. Thanks for posting the link. Yes, was the weird formatting on purpose?
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
Efficient Implementation of Cryptographic Primitives on the GA144 Multi-core Architecture John Rible <google@sandpipers.com> - 2013-05-29 00:56 -0700
Re: Efficient Implementation of Cryptographic Primitives on the GA144 Multi-core Architecture Mark Wills <markrobertwills@yahoo.co.uk> - 2013-05-29 07:39 -0700
Re: Efficient Implementation of Cryptographic Primitives on the GA144 Multi-core Architecture Paul Rubin <no.email@nospam.invalid> - 2013-05-29 09:11 -0700
Re: Efficient Implementation of Cryptographic Primitives on the GA144 Multi-core Architecture Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-29 12:41 -0500
Re: Efficient Implementation of Cryptographic Primitives on the GA144 Multi-core Architecture Paul Rubin <no.email@nospam.invalid> - 2013-06-01 12:40 -0700
Re: Efficient Implementation of Cryptographic Primitives on the GA144 Multi-core Architecture Jason Damisch <jasondamisch@yahoo.com> - 2013-05-31 18:57 -0700
csiph-web