Diving deeper into Cellframe: Key generation performance

This article was originally written by Mika Hyttinen. Medium link: https://medium.com/@mika.hyttinen

Time for another article!

I decided to do a performance comparison in key generating and Base64 decoding between a “modern” CPU and a Raspberry Pi 3B+ on a Cellframe node.

The Python SDK in Cellframe uses direct calls to C functions for generating the keys and for the Base64 decoding operations so it should be relatively fast on any CPU, But how does Raspberry Pi handle such a task?

Well, let’s try this and find out!

This article is meant for testing purposes only and it doesn’t give you any “true” data about the real world performance of Cellframe node.

Let’s go!

. . .

About Cellframe

Cellframe is an ambitious third generation blockchain project and few people (me included) have already started to talk about it as the next Polkadot or Kusama.

This project is, however, more service oriented and has some advantages compared to Polkadot/Kusama (eg. post-quantum cryptography, 2-level sharding, P2P cross-chain operations).

Cellframe is written in C (which will make it FAST and portable), and it has an SDK for C and Python at the moment. More supported languages are coming in the future.

I really recommend visiting their website (https://cellframe.net) and read their whitepaper!

. . .

Key generator plugin

So first of all, we obviously want to do a plugin for Cellframe which generates the keys and does the Base64 decoding operations automatically. Let’s just make a plugin which would be called generatekeys .

Next I decided to check Cellframe Wiki and see what methods are available for tasks like this.

DAP.Crypto module looks like a sophisticated choice for that. It has a methods Algo.generateNewKey() and Algo.decodeBase64() That’s what I’m looking for!

generateNewKey()method allows us to select which key type I want to create with numbers from 0–16:

0 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_IAES()
1 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_OAES()
2 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_RLWE_NEWHOPE()
3 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_SIDH_CLN16()
4 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_DEFEO()
5 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_MSRLN()
6 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_MSRLN16()
7 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_RLWE_BCNS15()
8 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_LWE_FRODO()
9 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_SIDH_IQC_REF()
10 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_CODE_MCBITS()
11 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_NTRU()
12 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_MLWE_KYBER()
13 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_SIG_PICNIC()
14 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_SIG_BLISS()
15 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_SIG_TESLA()
16 -> DAP.Crypto.CryptoKeyType.DAP_ENC_KEY_TYPE_SIG_DILITHIUM()

From this list, I decided to use DAP_ENC_KEY_TYPE_BLISS .

For Base64 operations, Algo.decodeBase64() method accepts a simple string as an input so we’ll use that for this testing.

So a bit of fiddling around and I came up with this:

Now I just launched Cellframe node on my laptop and checked how many milliseconds it took to generate 500 new BLISS key objects and to do 500 Base64 decoding operations:

It took 0.01 seconds to generate 500 keys and to do 500 of decodeBase64 operations

Umm, ok. That's too small amount then. Let’s generate slightly more. 10000 keys should be enough:

It took 0.30 seconds to generate 10000 keys and to do 10000 of decodeBase64 operations

Now it looks slightly better. 0.30 seconds to generate 10000 new keys on my laptop.

Now I decided to test how long this same plugin would run on a Raspberry Pi 3B+. Running this plugin gave me the following results:

It took 2.88 seconds to generate 10000 keys and to do 10000 of decodeBase64 operations

So the results for generating 10000 key objects on Raspberry Pi 3B+ is around ~2,9 seconds. That’s about 10 times slower than my old laptop 😆.

I’m actually surprised that it’s “only” 10 times slower. I would have expected far lower performance from an old Raspberry Pi.

How about threading then?

I also decided to test if I add a separate thread for doing the job would improve the result on Raspberry Pi:

First test on my laptop gave the following result:

It took 0.24 seconds to generate 10000 keys and to do 10000 of decodeBase64 operations

That’s a 0.06 seconds faster than without threading. Let’s see what Raspberry Pi says about this:

It took 2.63 seconds to generate 10000 keys and to do 10000 of decodeBase64 operations

0.25 seconds faster. Not really worth it I guess.

Conclusion

Like I mentioned, this article was just for testing purposes and allows me to study the powerful Cellframe Python SDK.

There are probably multiple better ways to make these tests but I showed you a one way to do that 😉.

Like I mentioned in my earlier benchmark article: When we get the Cellframe node running on modern mobile phone which is more than 4 times faster than a Raspberry Pi, it will be a game changer in the whole blockchain industry!

And by the way, I tried to generate 1 million keys and do 1 million Base64 decode operations also. As I’m writing this while running the tests at the same time, my Raspberry Pi is still frozen (been for 15 minutes now).

Interested building on Cellframe?

Join their development Telegram channel: https://t.me/cellframe_dev_en

You can also contact me if you have some questions or if you’re interested building something on the future of blockchains:

Telegram: @CELLgainz
Twitter: @CELLgainz