NEM 1.0 / NEM 2.0 cryptographic algorithm (for hardware-signing)

Dear @gevs, @BloodyRookie (and other NEM tech wizards),
cc. @jtey1 (LuxTag) and @musdom (LuxTag)

We at LuxTag are working on un-copyable tags using NFC embedded Hardware Security Modules which do the cryptographic signing. They keep the randomly generated private key inside the chip and do the signing, similar to common crypto hardware wallets.

Recently, we spoke to a manufacturer to check on compatibility with NEM cryptography, so that the signing could happen on-chip.

  1. They said their chips are compatible with the common cryptography and as such with the main blockchain projects. They call NEM an “exotic blockchain”.
  2. They said that NEM 1.0 would be able to work with minor tweaks, as it uses ED25519 SHA2-512.
  3. NEM 2.0 (Codenames Catapult, Symbol) would not work as it deviates from industry standard. To my understanding, this relates to the use of SHA3-512.
  4. The chip manufacturer seems to advise us to change from the “exotic and incompatible blockchain NEM1 / NEM2” towards a more mainstream platform. :woozy_face: (Allegedly, even Hyperledger Fabric and others are out-of-the box compatible)

Can I ask for opinions and recommendations regarding the hardware module signing (hashing/signing) for NEM 2.0?

Thank you and happy 4th advent sunday :christmas_tree:.
( )

1 Like

Hello there @r3n3 and thanks for reaching out.

  1. NIS uses Keccak-SHA3-512, it is indeed deviating from “standard” sha3 blockchain projects.
  2. Good - they probably are saying that standard SHA3 would be better.
  3. Catapult uses standard SHA3-512 in private mode, but Keccak-SHA3-512 for public mode. This means that it should also make Catapult compatible as of point 2).

Hope to answer your question :+1:

  1. I guess the guys didn’t closely look at NIS1? It is not using sha2.
1 Like

Thanks guys.
It was sad how NEM is being called “exotic, non mainstream”. I guess that’s what we’re all working on to change!

I found useful, too. It talks about SHA3-256 and the KECCAK SHA3-256 for (the blockchain platform formerly known as) Catapult.

@gevs You say

whereby the document at above explains the -256 version.

What is right? Sorry for asking these questions. Am not a cryptography expert.
I want to avoid confusions when I go back to the hardware security module chip manufacturer.

Is this helpful?
This is a nem2-sdk original implementation.


1 Like

Very good write-up in Japanese!
I read the translation. Still, am a bit confused on the “why” and “256 / 512” question because Greg and NEMtech give different information.

@dgarcia360 there is an inconsistency in docs i believe. We use 64 bytes keys and hashes, and therefor should be keccak-sha512, correct me if wrong please :ok_hand:

1 Like

The docs seem correct, but we are probably talking about different things. The info was taken from the catapult-server code PublicKeyToAddress function:

From what I have understood, the values CatapultHash can take are Keccak_256 or Sha3_256, depending on the config value SIGNATURE_SCHEME_KECCAK:

To sign entities, Catapult uses SHA3-512 or Keccack-512.

Indeed, this part is not fully defined in the docs yet. We can add an example as we are doing with the public key -> address derivation.


Guys, can you please explain the differences between SHA-3 and Keccak-SHA-3 that Private and Public catapult networks use? Because as I am reading SHA-3 standard by NIST it seems that it was submitted by Keccak team and it is the same algorithm.

1 Like

I’d like to be enlightened, too.
Layman websites like say “Keccak (pronounced as “ketchak”) also known as SHA-3 (Secure Hash Algorithm 3). It is the latest generation secure hashing algorithm released by NIST (National Institutes of Standards and Technology) in 2012.”

1 Like

They are different. Keccak was originally drafted and proposed in NIST standard but then some padding changes were introduced which did not make it into the standard.

Therefor they are slightly different and there is also a lot of confusion in some packages on the net… cryptoJs for example had only a small one line comment about “this is using KECCAK, not sha3”, yet naming the function sha3…



Ok, but why to stick with Keccak-SHA3 instead of standartised version of SHA3 on Public network then. It will bring lots of compatibility and support problems with HW vendors like HSM, SIM and etc that will be using standartised cryptography. By sticking with nin standard cryptography you limiting the possibility to use HW solutions for signing transactions on a public network. This seems not rational at all, because security wise you are not gaining anyting there.


to maintain backward compatibility with nem1 addresses. (to be able to actually make symbol nemesis transfers)