Easter egg, well salted

Archive
1

It may be a week early, but as unveiled in
https://www.ghielectronics.com/community/forum/topic?id=15379
an easter egg is hidden in the [em]Mountaineer Firmware 4.3.1 Beta 3[/em].

[em]Oberon.NaCl[/em] is a light-weight cryptographic library for NETMF-based IoT devices. It is a small and easy-to-use tool box that you can use to build secure communication protocols, secure firmware update mechanisms, etc.

It is based on [em]NaCl[/em], pronounced “salt”, a highly regarded suite of cryptographic algorithms designed and implemented by D. Bernstein et. al. It can be implemented efficiently even on single-chip microcontrollers and supports both symmetric and asymmetric cryptography.

A great introduction is given by Marco Poponi here:

Links to examples and additional background are given here:
http://www.mountaineer.org/resources/tidbits/using-the-nacl-crypto-library/

We are considering to contribute our code, along with a test suite, as a new core component of NETMF. Under the Apache 2.0 open source license, like the rest of NETMF. This will depend on the community feedback. At the moment, we see [em]Oberon.NaCl[/em] as an experimental feature that may or may not find its way into the final release of the Mountaineer firmware.

Microsoft told us that they intend to set up a community process for contributions like this one. Until that process is in place, we use this forum here as a sounding board. Please let us know whether you feel that such a library would add value to NETMF, whether you see any issues with the API, and especially how you would like to [em]use[/em] the library.

I´d like to thank Dan Berstein and his team for their impressive work and for making it public domain, Marc for finding and choosing NaCl, Pascal for implementing, testing and documenting our adaptation, Beat for understanding the involved math in-depth and for seeing the optimization potential of an already [em]fast[/em] implementation, and Stephan, Etan and Thomas for multiple API and code reviews.

Cuno

10 Likes
2

To make it simpler to browse through the API, here this new link:

3

We also measured the run times for the most important NaCl primitives on a random byte array for different lengths on a Mountaineer board (see left image: https://www.ghielectronics.com/uploads/forum/img/9253_nacl_stm32f4_large.png )

Although CryptoBox uses two different operations to encrypt (CryptoBox.Box) and decrypt (CryptoBox.Open) data we plotted only one operation, as both operations require the same time.
Looking at the plots we can observe that for byte arrays smaller than about 1 KB, constant time is required to encrypt and sign a byte array. In CryptoBox, this constant part is due to basic overhead:
[ul]Computing shared key using Curve25519[/ul]
[ul]Interop calls from C# to the C library[/ul]
The rest of the time is used for computing the stream cipher XSalsa20 on the data and storing it into the output array.
In CryptoSign, the constant part is due to:
[ul]Computing a hash of the secret key[/ul]
[ul]Additional curve operations[/ul]
[ul]Interop calls from C# to the C library[/ul]
Beyond 1 KB, we observe that the rest of time is used for computing SHA 512 on the dataset. Compared to CryptoBox, CryptoSign uses far more curve operations.
The same thing can be observed when benchmarking the reference implementation of NaCl on a Windows PC (see right image: https://www.ghielectronics.com/uploads/forum/img/9254_nacl_i7_large.png ).

4

I believe my user id is smaller than 25519 ;).
I wanted to both humour the forum and have a hommage to NaCl ;D (you’ll most likely find me in the ScalarMult function Bitbucket | Git solution for teams using Jira )

5

Hey, that username doesn’t have anything to do with the NSA back-doored Dual Elliptical Curve does it?? :wink:

6

You mean the “Dual_EC_DRBG” random number generator? No. I’m just referencing the DJBs elliptic curve25519 and Ed25519 which are both used in NaCl.

For more information I would like to reference the individual websites since I don’t feel confident that I’m able to explain the individual curves correctly.
[ul]Curve25519-Diffie-Hellman function
Wikipedia: Curve25519 - Wikipedia
Website: Curve25519: high-speed elliptic-curve cryptography .
The curve is exposed in CryptoScalarMult: Bitbucket | Git solution for teams using Jira

[ul]Ed25519-signature function
Wikipedia: EdDSA - Wikipedia
Website: http://ed25519.cr.yp.to/
The function is used in CryptoSign but not directly exposed since NaCl doesn’t expose the function directly. I would also like to add that we use the SuperCop implementation of Ed25519 since the original crypto_sign support in NaCl is experimental.
Documentation: Bitbucket | Git solution for teams using Jira

Since I certainly managed to confuse you, here’s a primer on elliptic curve cryptography:
A (relatively easy to understand) primer on elliptic curve cryptography | Ars Technica (it’s probably best to start here).

Also here’s an interesting talk from the authors of NaCl from 30c3 (CCC Chaos Congress 2013): The Year in Crypto media.ccc.de - The Year in Crypto

And here’s a talk of the previous year about RSA key factorisation by the same people:
media.ccc.de - FactHacks (also contains a RSA crypto lecture).

7

Yes to Dual_EC_DRBG. I wasn’t confused. It was a joking reference to the NSA backdoor alleged to be in it. Big Brother IS watching here in the states.

8

Hi, with your library the .NET_MF got the long missing support of contemporary cryptography for very small controllers now - this is very impressive.

Now the Internet of the hacked things will maybe still the Internet of safe things :wink:

But how can I test the Oberon.NaCl library with my software in the MF emulator? Must I do this create a new emulator with the NaCL library with the Porting Kit?

How can I receive the packages encrypted with NaCL on my BeagleBone Black with mono/.NET? When I click on bitbucket.org/oberon-microsystems/oberon.nacl.samples only find x86/64 binaries for Windows?

Rather than the BBB, also a GHI FEZ Cobra II (ECO) as a Bridge to SSL would be possible, but the sources of NaCL are in the MF Porting Kit not integrated yet. Are the sources published in the near future there?

Thanks in advance :slight_smile:

9

You are right, Bernstein’s algorithms provide excellent security at the cost of relatively few processor cycles.

We don’t have the resources to support implementations for other platforms (Mono, also the NETMF emulator). Fortunately, this is not a problem: we use the standard NaCl API and standard set of algorithms, so you can use any existing implementation of NaCl on other platforms than NETMF, e.g. libsodium. If you try that, we’d be interested in learning how that went!

As for a possible integration into the Porting Kit, it will be a Microsoft decision whether they are interested. Currently, we consider the library an experimental feature. Can you say a bit more about your application, how you would use NaCl? We are very interested in getting feedback.

10

@ Cuno - Thank you for the detailed reply and the note on libsodium. Because there is nothing usable, I’ll take a look at MatrixSSL or CyaSSL. Maybe it is possible to integrate this into the Netduino firmware - that exists as source code. Is the source code for the FEZ Cerbuino firmware available too?

I try to show my students a simple development platform for the Internet of things. A necessary key Feature I look for, is an absolutely secure data transfer.