Cryptography and cryptanalysis of BYTOM

BYTOM, same as most other projects, uses Asymmetric cryptography schemes: Public keys, addresses, signatures can only be produced one-way, from a Private key, and not in reverse (hence, a-symmetrical).

Private key encryption: SHA-512 of a seed byte array or mnemonic (as per the already established Bitcoin BIP39 scheme). Contrary to popular belief, SHA-512 is SHA-2 equivalent — its exactly as secure as the SHA-2 family, just longer (produces 64 byte keys). As per BYTOM’s codebase:

xprv = hmac(sha512, seed, []byte{'R', 'o', 'o', 't'})

xprv[0] &= 248

xprv[31] &= 31

xprv[31] |= 64

The HMAC function is just for message authentication, to make sure the integrity of the data received is A-OK. It doesn’t provide any cryptographic resistance.

The bitwise operations on positions 0 and 32 of the key array are finally done for key prefixing and marking.

Public key encryption: EdDSA of the SHA-512 private key, so that makes it ed25519(sha-512). Because we’re working with sha-512 inputs, the relevant implementation of the EdDSA scheme is Edwards25519 (using a combination of SHA-512 input and Curve25519).

Indeed, looking at the BYTOM code:

xpub[:32] = edwards25519.GeScalarMultBase(xprv[:32])

xpub[32:] = xprv[32:]

There’s a trick here: Public keys are 64 bytes, but Edwards25519 produces 32 bytes. The right-half of the public key (bottom-half) is exactly the same as the right-half of the Private key (characters 33 to 64 in the array, if you’re counting from 1).

This does not compromise security, but helps with the signature procedure — remember, both of these keys are not useful by themselves only, but only when combined to perform a signature.

A small mention to children private and children public keys (derivatives), which are used to create children addresses so you don’t have to expose your public key and break your anonymity every time you want an asset received: children keys are mostly SHA-512 of the original key (private or public) plus a derivation path.

There’s more tricks to it, for example children private keys have carryover-bits during their first 32 digits, and children public keys implement Edwards curve points, but considering the cryptography aspect of it, we’re still at SHA-512 — No other editing steps aid or hinder security.

xpub = xprv.XPub()

#### Structuring of child (derived) private key:

child_xprv = hmac(sha512, []byte{'N'} + xpub[:32] + derive_path, xpub[32:])

child_xprv[0] &= 248

child_xprv[29] &= 1

child_xprv[30] = 0

child_xprv[31] = 0 carry = 0

for i := 0; i < 32; i++ {

sum := int(xprv[i]) + int(child_xprv[i]) + carry

child_xprv[i] = byte(sum & 0xff)

carry = (sum >> 8)

} #### And now, for a derived public key

child_xpub = hmac(sha512, []byte{'N'} + xpub[:32] + derivation_path, xpub[32:])

child_xpub[0] &= 248

child_xpub[29] &= 1

child_xpub[30] = 0

child_xpub[31] = 0

f = edwards25519.GeScalarMultBase(child_xpub[:32])

p = edwards25519.Point(xpub[:32])

child_xpub[:32] = edwards25519.AddPoint(p, f)

Cryptanalysis on BYTOM can therefore be abstracted to the cryptanalysis of SHA-512 and Edwards25519(SHA-512).

The security limitations and bounds of these two hash algorithms extend to BYTOM as well — and we can safely say that we’re nice and cozy in this department.

Regarding pre-imaging attacks,(attacks where, having the resulting hash, you’re trying to find the source string of characters, the ones that caused it) are the basic “risk” factor in assymetrical cryptography.

In the context of BYTOM, “how difficult is for someone that has my Public Key to calculate the Private Key which produced it?”

SHA-512 and generally the SHA-2 family of algorithms does extremely well in that.

Even in the most modern methods of attack, using biclique data structures in a splice-and-cut approach, as described by [KHOVRATOVICH, RECHBERGER, SAVELIEVA] in 2011, only break 57 out of 80 rounds (iterative steps) inside of SHA-512, in coordinated massive scale attacks.

The complexity here is of course exponential, meaning that for every round deeper that you attempt to break, your workload and problem becomes 256 times larger. The 23 remaining rounds cannot feasibly be broken.

SHA-512 has remained preimage-unbroken since its introduction in 2001.

Regarding collision resistance, (attacks where you’re trying to calculate a seed/Private key that results in the same Public key as someone else’s — therefore, having a collision in the hash function) is a derivative risk of the first concept, pre-image resistance. It is sometimes called second-pre-image-resistance because of this connection.

SHA-256 (and by equivalence, SHA-512) is even better at this due to its better-performing cascading effect in hash generation.

According to [LAMBERGER, MENDEL], modern cryptanalysis techniques on SHA-256 collision attacks using high-factor differentials, only managed to reliably break 46 out of 64 SHA-256 rounds.

Based on the above, you can safely disregard any rumours of “pre-mined/pre-calculated” addresses, any “fatal flaws” in the cryptographic functions of BYTOM, etcetera. The technologies used are mature and incredibly resilient.

In truth, even if the hashing algorithms of a protocol such as BYTOM began breaking, it is not an avalanche event. Collisions need enormous computational power to calculate, if possible.

Usually, when “cracks” appear in a hash-system, much like RIPEMD in 2002, developers can start migrating onto a new system.

In regards to BYTOM, even at a completely unlikely event of a SHA-256 failure, there is enough time (usually years) for a soft/hard fork of the BYTOM protocol onto one that uses the SHA-3 family.

Nothing in programming is set in stone, and any developer team wants to future proof itself.