,
9 tweets,
5 min read
Read on Twitter
1/ We decided to waste no time in heading directly to the documentation of Hedera Hashgraph - found here: docs.hedera.com/docs/
Specifically, we're going to look at 'key generation'
Ed25519 > secp256k1 (ECDSA) [what Bitcoin uses]
Specifically, we're going to look at 'key generation'
Ed25519 > secp256k1 (ECDSA) [what Bitcoin uses]
2/ Providing an eclectic range of signatures is somewhat worrisome because the biggest source of compromise among users as it pertains to key generation using these signatures is user error / incorrect implementation.
3/ More important is implementation; visiting the GitHub = github.com/hashgraph/hede…
4/ So a few light issues - starting with a top to bottom assessment of the code itself.
Below are some annotations that were made to explain the packages (SDKs) imported {Bouncy Castle used; reliable - this works}
Below are some annotations that were made to explain the packages (SDKs) imported {Bouncy Castle used; reliable - this works}
5/ Using 'public static' vs. 'private static', could be argued - generally similar applications of these packages will use 'private static' for some parts.
More importantly, however, is evaluating the cryptographic sigs/standartds used by Hedera (next tweet)
More importantly, however, is evaluating the cryptographic sigs/standartds used by Hedera (next tweet)
6/ We know already that SHA256 is vulnerable to length-extension + pre-image attacks (same w SHA-512); this, compounded with the means by which the seed is created (via password??) , creates a *very insecure* setup.
7/ Attached to this tweet is an implementation of SHA256 using the same Bouncy Castle API, but also with the inclusion of HMAC for the PRN (random-number generator), ensuring a more secure seed is derived.
Ultimately, this is the type of code that we'd want to see.
Ultimately, this is the type of code that we'd want to see.
8/ Going back to the code leveraged by Hedera Hashgraph...insecure seed/key generation = compromised structure.
