PolarSSL is now a part of ARM | Hacker News Reader

PolarSSL is now a part of ARM

polarssl.org

86 pointsfcambus28 comments

Open articleView on HN

Congratulations!

Who knows, maybe a part of the "exciting plans for 2015" is to release PolarSSL under a liberal open source license...

It's GPL 2 - https://polarssl.org/how-to-get#open-source

I'm not saying that's the nadir of licenses - but it's pretty good, no?

GPLv2 crypto will never dethrone OpenSSL

GnuTLS is LGPL and can be used alongside commercial applications. There's also Botan (BSD, C++), Bouncy Castle (MIT, Java).

Who should care if GPL is bad for a SSL library? First of all it needs to be correct and PolarSSL is the only one in this field. It is trusted, and it is fast enough.

I would never trust GnuTLS, NSS or OpenSSL over PolarSSL.

> Who should care if GPL is bad for a SSL library?

An entity which actually ships software?

> I'm not saying [GPLv2 is] the nadir of licenses - but it's pretty good, no?

It's certainly "pretty good" compared to having no source code available at all. But when people talk about "liberal" licenses (aka permissive licensing), the GPL is not what usually comes to mind.

The only advantage of doing so would be to allow small closed-source, proprietary shops, who can't currently afford the €99/month subscription, to use the library. I struggle to sympathise in this category, it's not like this group is locked out of SSL/TLS entirely.

Ah, most noticably, it'd be an interesting alternative for BSD/MIT (and Apache?) proyects including the *BSD family of OSs.

This is ARM we're talking about. They're not known for being open-source friendly.

ARM fund CodeSourcery to get ARM compiler support into the gcc toolchain. Plenty of people there like open source.

The worry, internally, is a holdover from the days of the SCO-Linux disputes - that if an employee works on an open-source compiler, sees a great idea, then remembers it and implements it in the closed-source compiler later on (even subconsciously) that it could mean a bunch of legal hassle.

I would have expected Facebook or Google to do this ages ago. Particularly Google, rather than pursuing 'BoringSSL'. Still, it's nice to see new and different flows of investment in to TLS. I hope this is a sign that at least one British company is taking our privacy and security seriously.

Why exactly would Google want to buy someone else's SSL library?

Clearly ARM sees an opportunity for synergy with PolarSSL. I've built a few services on top of ARM based SOC and being able to fully utilize on onboard cryptographic coprocessor for file serving applications can be a performance challenge.

There are some options [http://www.altechnative.net/2011/05/22/hardware-accelerated-...] for getting openssl hardware accelerated on common arm boards, but it could be made much easier to get a performant configuration if PolarSSL and ARM worked together.

I hope that this acquisition will pave the way to an encrypted internet of things.

Exactly! A common SSL that works on all ARM SOCs that you can get for 'free' from ARM is critical to the security of distributed smart devices. If done well, this can be a huge win.

What exactly it means that PolarSSL (a crypto library) is now part of ARM (a CPU architecture) ???

It means that PolarSSL was acquired by ARM (the company that develops the ARM architecture).

It probably means ARM will create ASIC type encryption on their chips. May be helpful saving battery life.

It might, but I wouldn't say probably. It might also mean more resources devoted to ensuring that PolarSSL runs well on the ARM architectures/chips that are (or will be) out there anyway. That's probably more interesting to most people, except for those making dedicated network hardware.

I don't see the problem, PolarSSL runs on ARM very well!

Who said there was a problem? I'm sure PolarSSL runs very well on ARM already. However, it's also extremely likely that it could run even better if the PolarSSL developers were more fully plugged into what the people who work on the ARM crypto hardware know. It's amazing what one can do if one knows exact details of what's going on within each functional unit, between them on the internal coherency bus, etc. ARM probably saw an opportunity, not a problem.

I don't think it is that. ARM doesn't make the crypto. The SoC makers put their own crypto cores so it wouldn't help ARM that way.

I think just like they bought Keil (a dev tools maker) this is a strategy play to make it easier for end devs to add SSL or other crypto to their products. One shop solution.

Actually ARM does make crypto. It's part of ARMv8, licensable as an option for at least the Cortex-A53.

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500e/DD... (section 2.1.4)

There are undoubtedly other bits as well, as part of their "trusted computing" blahblah. Even if that weren't the case, knowing more about the internals of current and upcoming ARM IP could help optimize even an all-software implementation of PolarSSL. You could be right that it's mostly about "one stop shopping" but that doesn't mean there won't be other benefits.

You are correct.

However, Trusted Computing crypto is different than the crypto accelerators you find as peripherals in an SoC.

I should have been more clear that I meant crypto peripherals. There are crypto instruction extensions but don't require a separate library implementation -- just asm code optimization in something like openSSL.

PolarSSL is also targeted (mainly) towards much lower power than A53 or Cortex-A. It is targeted towards Cortex-M where you are dealing with KB of data and often don't have an MMU. You can't just port OpenSSL to those platforms and run it at will, hence their optimized libraries.

ARM Holdings plc (ARM) is also the company behind the CPU architecture, so it's rather likely that ARM they refer to.

See http://en.wikipedia.org/wiki/ARM_Holdings, of course.

They are going to integrate it into their mbed-os(their IOT lightweight event based os, especially designed for real-time low-power devices).Some parts of this would be closed, so it's hard to tell if PolarSSL will be too.

I guess this is part of ARM's IoT push.

It's funny how in issue #1 users are asking for DTLS. I'm pretty sure this is what's finally going to get implemented and probably will appear in mbed OS soon too.

https://github.com/polarssl/polarssl/issues/1 http://mbed.org/technology/os/

Reply on news.ycombinator.com