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@xxxxxxxxxxxxxxx> 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.
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
