ANd I should have remembered that when I started going down the F21arm rabbit hole, I saw the reference the the arm64 development. Just too much going around in my head. And all of this is just precursors to what I really want to do.
On 08/07/2014 04:28 AM, Peter Robinson wrote:
On Thu, Aug 7, 2014 at 3:50 AM, Robert Moskowitz rgm@htt-consult.com wrote:
There is extensive discussion on the IRTF's crypto list on choosing the next Elliptic Curve algorithm EC25419 may be leading in the discussions.
But the interest here is dealing with lots of ECC calculations on a server that is running an SMTP MTA using STARTTLS and DANE a lot. In such a case, being able to do lots of EC calcs is important. This gets us to comparing the armv7 to the armv8. I have been told that the armv8 is 64bits, so...
Is that really what the IRTF considers a useful standard representative usecase?
It is one of the cases brought to the IRTF by the IETF. There is a fair amount of traffic back and forth, and honestly I have fallen behind by quite a few days worth of mails.
Is there support for armv8 systems with F21 and of course are there affordable armv8 cards? Or am I getting too ahead of the curve? ;)
Define "ARMv8"? There's aarch64 support for the ARMv8 architecture as a secondary architecture (see the daily rawhide reports to this list) but you can run an ARM 32 bit userspace on those chips.
Yes. Just too much going on and random bits popping out at times. I DID see that over a week ago. Definitely a senior moment.
There's also hardware available but define "affordable"... at the moment the first gen widely available hardware will set you back about USD$ 3K
I am going to have to have some fun with my colleagues at these standards meetings that show ARM as their employer. "Oh we have handled that item in our v101 chip which you will be seeing in products soon." ;)
Ultimately ARMv7 / 32 bit isn't going away quickly, ARMv8 is 64 bit, both have NEON SIMD which provides 128bit SIMD instructions and there's the ability to use those units to optimise offload of crypto functions so I suspect NEON is likely the best means of achieving speed and optimisation use case that will work across both platforms. ARMv8 has HW optimised crypto extensions but they'll be for existing cyphers and I've no idea how useful they will be for future standards.
No. Never said it would. In fact I work with sensor vendors that are still doing 8 bit chip designs. They can't afford 32bit. For them I design security stuff that will work within their 30KB limits on those 8 bit chips. This is for other things.
Thanks for all your help, Peter.