From e73569b23d52fb033f8c458f6fc4a566eca31682 Mon Sep 17 00:00:00 2001 From: Jeff Burdges Date: Fri, 8 Feb 2019 18:19:01 +0100 Subject: [PATCH] Moved to w3f/research in e1786e50e9 --- keys/0-intro.md | 13 --------- keys/1-accounts-more.md | 60 ----------------------------------------- keys/1-accounts.md | 37 ------------------------- keys/2-nominator.md | 35 ------------------------ keys/3-session.md | 34 ----------------------- keys/4-secio.md | 34 ----------------------- keys/creation.md | 18 ------------- 7 files changed, 231 deletions(-) delete mode 100644 keys/0-intro.md delete mode 100644 keys/1-accounts-more.md delete mode 100644 keys/1-accounts.md delete mode 100644 keys/2-nominator.md delete mode 100644 keys/3-session.md delete mode 100644 keys/4-secio.md delete mode 100644 keys/creation.md diff --git a/keys/0-intro.md b/keys/0-intro.md deleted file mode 100644 index 1c0280f..0000000 --- a/keys/0-intro.md +++ /dev/null @@ -1,13 +0,0 @@ - -# Signing keys in Polkadot - -In this post, we shall first give a high level view of the various signing keys planned for use in Polkadot. We then turn the discussion towards the certificate chain that stretches between staked account keys and the session keys used for our proof-of-stake design. In other words, we aim to lay out the important questions on the "glue" between keys rolls here, but first this requires introducing the full spectrum of key rolls. - -We have roughly four cryptographic layers in Polkadot: - - - *Account keys* are owned by users and tied to one actual dot denominated account on Polkadot. Accounts could be staked/bonded, unstaked/unbonded, or unstaking/unbonding, but only an unstaked/unbonded account key can transfer dots from one account to another. - - *Nominator keys* provide a certificate chain between staked/bonded account keys and the session keys used by nodes in block production or validating. As nominator keys cannot transfer dots, they insulate account keys, which may remain air gapped, from nodes actually running on the internet. - - *Session keys* are actually several keys kept together that provide the various signing functions required by validators, including a couple types of verifiable random function (VRF) keys. - - [*Transport layer static keys*](https://forum.web3.foundation/t/transport-layer-authentication-libp2ps-secio/69) are used by libp2p to authenticate connections between nodes. We shall either certify these with the session key or perhaps include them directly in the session key. - - diff --git a/keys/1-accounts-more.md b/keys/1-accounts-more.md deleted file mode 100644 index 759be38..0000000 --- a/keys/1-accounts-more.md +++ /dev/null @@ -1,60 +0,0 @@ - -# Account signatures and keys in Polkadot - -We believe Polkadot accounts should primarily use Schnorr signatures with both public keys and the `R` point in the signature encoded using the [Ristretto](https://ristretto.group) point compression for the Ed25519 curve. We should collaborate with the [dalek ecosystem](https://github.com/dalek-cryptography) for which Ristretto was developed, but provide a simpler signature crate, for which [schnorr-dalek](https://github.com/w3f/schnorr-dalek) provides a first step. - - -## Schnorr signatures - -We prefer Schnorr signatures because they satisfy the [Bitcoin Schnoor wishlist](https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki) and work fine with extremely secure curves, like secp256k1 or the Ed25519 curve. You could do fancier tricks, including like aggregation, with a pairing based curve like BLS12-381 and the BLS signature scheme. These curves are slower for single verifications, and worse accounts should last decades while pairing friendly curves should be expected become less secure as number theory advances. - -There is one sacrifice we make by choosing Schnorr signatures over ECDSA signatures for account keys: Both require 64 bytes, but only [ECDSA signatures communicate their public key](https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work). There are obsolete Schnorr variants that [support recovering the public key from a signature](https://crypto.stackexchange.com/questions/60825/schnorr-pubkey-recovery), but -they break important functionality like [hierarchical deterministic key derivation](https://www.deadalnix.me/2017/02/17/schnorr-signatures-for-not-so-dummies/). In consequence, Schnorr signatures often take an extra 32 bytes for the public key. - -In exchange, we gain a slightly faster signature scheme with far simpler batch verification than [ECDSA batch verification](http://cse.iitkgp.ac.in/~abhij/publications/ECDSA-SP-ACNS2014.pdf) and more natural threshold and multi-signatures, as well as tricks used by payment channels. I also foresee the presence of this public key data may improve locality in block verification, possibly openning up larger optimisations. - -Yet most importantly, we can protect Schnorr signatures using both the derandomization tricks of EdDSA along with a random number generator, which gives us stronger side-channel protections than conventional ECDSA schemes provide. If we ever do want to support ECDSA as well, then we would first explore improvements in side-channel protections like [rfc6979](https://tools.ietf.org/html/rfc6979), along with concerns like batch verification, etc. - - -## Curves - -There are two normal curve choices for accounts on a blockchain system, either secp256k1 or the Ed25519 curve, so we confine our discussion to them. If you wanted slightly more speed, you might choose FourQ, but it sounds excessive for blockchains, implementations are rare, and it appears covered by older but not quite expired patents. Also, you might choose Zcash's JubJub if you wanted fast signature verification in zkSNARKs, but that's not on our roadmap for Polkadot, and Jubjub also lacks many implementations. - -### How much secp256k1 support? - -We need some minimal support for secp256k1 keys because token sale accounts are tied to secp256k1 keys on Ethereum, so some "account" type must necessarily use secp256k1 keys. At the same time, we should not encourage using the same private keys on Ethereum and Polkadot. We might pressure users into switching key types in numerous ways, like secp256k1 accounts need not support balance increases, or might not support anything but replacing themselves with an ed25519 key. There are conceivable reasons for fuller secp256k1 support though, like wanting ethereum smart contracts to verify some signatures on Polkadot. We might support secp256k1 accounts with limited functionality, but consider expanding that functionality if such use cases arise. - -### Is secp256k1 risky? - -There are two theoretical reasons for preferring an twisted Edwards curve over secp256k1: First, secp256k1 has a [small CM field discriminant](https://safecurves.cr.yp.to/disc.html), which might yield better attacks in the distant future. Second, secp256k1 has fairly rigid paramater choices but [not the absolute best](https://safecurves.cr.yp.to/rigid.html). I do not believe either to be serious cause for concern. Among more practical curve weaknesses, secp256k1 does have [twist security](https://safecurves.cr.yp.to/twist.html) which eliminates many attack classes. - -I foresee only one substancial reason for avoiding secp256k1: All short Weierstrass curves like secp256k1 have [incomplete addition formulas](https://safecurves.cr.yp.to/complete.html), meaning certain curve points cannot be added to other curve points. As a result, addition code must check for failures, but these checks make writing constant time code harder. We could examine any secp256k1 library we use in Polkadot to ensure it both does these checks and has constant-time code. We cannot however ensure that all implementations used by third party wallet software does so. - -I believe incomplete addition formulas looks relatively harmless when used for simple Schnorr signatures, although forgery attacks might exist. I'd worry more however if we began using secp256k1 for less well explored protocols, like multi-signaturtes and key derivation. We ware about such use cases however, especially those listed in the [Bitcoin Schnoor wishlist](https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki). - -### Is Ed25519 risky? Aka use Ristretto - -Any elliptic curve used in cryptography has order h*l where l is a big prime, normally close to a power of two, and h is some very small number called the cofactor. Almost all protocol implementations are complicated by these cofactors, so implementing complex protocols is safer on curves with cofactor h=1 like secp256k1. - -The Ed25519 curve has cofactor 8 but a simple convention called "clamping" that makes two particularly common protocols secure. We must restrict or drop "clamping" for more complex protocols, like multi-signaturtes and key derivation, or anything else in the [Bitcoin Schnoor wishlist](https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki). - -If we simple dropped "clamping" then we'd make implementing protocols harder, but luckily the [Ristretto](https://ristretto.group) encoding for the Ed25519 curve ensures we avoid any curve points with 2-torsion. I thus recommend: - - our secret key continue being Ed25519 "expanded" secret keys, while - - our on-chain encoding, aka "point compression" becomes Ristretto for both public keys and the `R` component of Schnoor signatures. - -In principle, we could use the usual Ed25519 "mini" secret keys for simple use cases, but not when doing key derivation. We could thus easily verify standrad Ed25519 signatures with Ristretto encoded public keys. We should ideally use Ristretto throughout instead of the standard Ed25519 point compression. - -In fact, we can import standard Ed25519 compressed points like I do [here](https://github.com/w3f/schnorr-dalek/blob/master/src/ristretto.rs#L877) but this requires the scalar exponentiation done in the [`is_torsion_free` method](https://doc.dalek.rs/curve25519_dalek/edwards/struct.EdwardsPoint.html#method.is_torsion_free), which runs slower than normal signature verification. We might ideally do this only for key migration between PoCs. - -Ristretto is far simpler than the Ed25519 curve itself, so Ristretto can be added to Ed25519 implementations, but the [curve25519-dalek](https://github.com/dalek-cryptography/curve25519-dalek) crate already provides a highly optimised rust implementation. - -### Zero-knowledge proofs in the dalek ecosystem - -In fact, the [dalek ecosystem](https://github.com/dalek-cryptography) has an remarkably well designed infrastructure for zero-knowledge proofs without pairings. See: - https://medium.com/interstellar/bulletproofs-pre-release-fcb1feb36d4b - https://medium.com/interstellar/programmable-constraint-systems-for-bulletproofs-365b9feb92f7 - -All these crates use Ristretto points so using Ristretto for account public keys ourselves gives us the most advanced tools for building protocols not based on pairings, meaning that use our account keys. In principle, these tools might be abstracted for twisted Edwards curves like FourQ and Zcash's Jubjub, but yu might loose some batching operations in abstracting them for short Weierstrass curves like secp256k1. - - - diff --git a/keys/1-accounts.md b/keys/1-accounts.md deleted file mode 100644 index 5bf3f9c..0000000 --- a/keys/1-accounts.md +++ /dev/null @@ -1,37 +0,0 @@ - - -## Account signatures and keys - -We believe Polkadot accounts should primarily use Schnorr signatures with both public keys and the `R` point in the signature encoded using the [Ristretto](https://ristretto.group) point compression for the Ed25519 curve. We should collaborate with the [dalek ecosystem](https://github.com/dalek-cryptography) for which Ristretto was developed, but provide a simpler signature crate, for which [schnorr-dalek](https://github.com/w3f/schnorr-dalek) provides a first step. - -I'll write a another comment giving more details behind this choice, but the high level summary goes: - - -Account keys must support the diverse functionality desired of account keys on other systems like Ethereum and Bitcoin. As such, our account keys shall use Schnorr signatures because these support fast batch verification and hierarchical deterministic key derivation ala [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Child_key_derivation_CKD_functions). All features from the [Bitcoin Schnoor wishlist](https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki) provides a case for Schnorr signatures matter too, like - - - interactive threshold and multi-signaturtes, as well as - - adaptor, and perhaps even blind, signatures for swaps and payment channels. - - -We make conservative curve choices here because account keys must live for decades. In particular, we avoid pairing-based cryptography and BLS signatures for accounts, at the cost of true aggregation of the signatures in a block when verifying blocks, and less interactive threshold and multi-signaturtes. [1]. - -In the past, there was a tricky choice between the more secure curves: - - - miss-implementation resistance is stronger with Edwards curves, including the Ed25519 curve, but - - miss-use resistance in stronger when curves have cofactor 1, like secp256k1. - -In fact, miss-use resistance was historically a major selling point for Ed25519, which itself is a Schnorr variant, but this miss-use resistance extends only so far as the rudimentary signature scheme properties it provided. Yet, any advanced signature scheme functions, beyond batch verification, break precisely due to Ed25519's miss-use resistance. In fact, there are tricks for doing at least hierarchical deterministic key derivation on Ed25519, as implemented in [hd-ed25519](https://github.com/w3f/hd-ed25519), but almost all previous efforts [produced insecure results](https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44). - -We observe that secp256k1 provides a good curve choice from among the curves of cofactor 1, which simplify make implementing fancier protocols. We do worry that such curves appear at least slightly weaker than Edwards curves. We worry much more than such curves tend to be harder to implement well, due to having incomplete addition formulas, and thus require more review (see [safecurves.cr.yp.to](https://safecurves.cr.yp.to)). We could select only solid implementations for Polkadot itself, but we cannot control the implementations selected elsewhere in our ecosystem, especially by wallet software. - -In short, we want an Edwards curve but without the cofactor, which do not exist, except.. - -In Edwards curve of with cofactor 4, [Mike Hamburg's Decaf point compression](https://www.shiftleft.org/papers/decaf/) only permits serialising and deserialising points on the subgroup of order $l$, which provides a perfect solution. [Ristretto](https://ristretto.group) pushes this point compression to cofactor 8, making it applicable to the Ed25519 curve. Implementations exist in both [Rust](https://doc.dalek.rs/curve25519_dalek/ristretto/index.html) and [C](https://github.com/Ristretto/libristretto255). If required in another language, the compression and decompression functions are reasonable to implement using an existing field implementation, and fairly easy to audit. - -In the author's words, "Rather than bit-twiddling, point mangling, or otherwise kludged-in ad-hoc fixes, Ristretto is a thin layer that provides protocol implementors with the correct abstraction: a prime-order group." - ---- - -[1] Aggregation can dramatically reduce signed message size when applying numerous signatures, but if performance is the only goal then batch verification techniques similar results, and exist for mny signature schemes, including Schnorr. There are clear advantages to reducing interactiveness in threshold and multi-signaturtes, but parachains can always provide these on Polkadot. Importantly, there are numerous weaknesses in all known curves that support pairings, but the single most damning weakness is the pairing $e : G_1 \times G_2 \to G_T$ itself. In essence, we use elliptic curves in the first palce because they insulate us somewhat from mathematicians ever advancing understanding of number theory. Yet, any known pairing maps into a group $G_T$ that re-exposes us, so attacks based on index-calculus, etc. improve more quickly. As a real world example, there were weaknesses found in BN curve of the sort used by ZCash during development, so after launch they needed to develop and migrate to a [new curve](https://z.cash/blog/new-snark-curve/). We expect this to happen again for roughly the same reasons that RSA key sizes increase slowly over time. - - diff --git a/keys/2-nominator.md b/keys/2-nominator.md deleted file mode 100644 index d08a65b..0000000 --- a/keys/2-nominator.md +++ /dev/null @@ -1,35 +0,0 @@ - -## Nominator keys - -In some sense, all public keys derive their authority from some combination of ceremonies and certificates, with certificate root keys deriving tehir authority entirely from ceremonies. As an example, trust-on-first-use schemes might be considered a pair of cerimonies, the key being associated to an identity first, and the threat of other comparing keys fingerprints. - -We apply this perspective to a consensus algorithm for a proof-of-stake blockchains like polkadot by regarding the chain itself as one large ceremony and treating the staked account as the root of trust. We then have certificates issued by these staked account keys that authenticate both the session keys used by Polkadot validators and block producers, as well as the long-term transport layer authentication keys required by TLS or Noise (see concerns about libp2p's secio). - -We must support, or may even require that, these session keys and TLS keys rotate periodically. At thesame time, we must support staked account keys being air gapped, which prevents them from signing anything regularly. In consequence, we require a layer layer called nominator keys that lies strictly between staked account keys and session keys. In this post, we shall discuss the certificate scheme for delegating from staked account keys to nominator keys and delegating from nominator keys to session keys, which includes several unanswered questions. - -In principle, any certificate format should work for nominator keys, but some certificate schemes provide more flexibility, while others save space. We do not require much flexibility per se, but at least some of these certificates should live inside the staked account, and have some associated data: - - - block hash and height when staked, - - unstaking block hash and height, if unstaking, and - - permissions, like only block production, validator nomination, and validator operator. - -### One vs two layer - -We can support nominated proof-of-stake with only one layer per se. We would have validator operator nominator keys point directly to their validator's current session keys, while nominator keys that only nominate would likely point to validator operator's nominator keys. We expect all nominator keys act as owners for a block production node's session key because we do not permit delegation for block production. - -We could require another layer, either by envisioning the session key itself as two layer, or by adding a second layer of nominator key. I think a two layer session key simplifies session key rollover, which improves forward security and thus reduces the benefits of compromising nodes. - -### Certificate location - -We could either store certificates with account data, or else provide certificates in protocol interactions, but almost surely the certificate delegating from the staked account to the nominator key belongs in the account data. - -We should take care with the certificates from the nominator key to the session key because the session key requires a proof-of-possesion. If we place them into the account, then there is a temptation to trust them and not check the proof-of-possesion ourselves. We cannot necessarily trust the chain for proofs-of-possesion because doing so might provides escalation for attackers who succeed in posting any invalid data. If we provide them in interactions then there is a temptation to check the proof-of-possesion repeatedly. We should evaluate either attaching a self-checked flag to the staked account database vs storing session keys in some self-checked account database separate from the account database for which nodes trust the chain. - -### Certificate size - -We could save some space by using implicit certificates to issue nominator keys, but we consider our initial implementation in [`schnorr-dalek/src/cert.rs`](https://github.com/w3f/schnorr-dalek/blob/master/src/cert.rs#L181) insufficient. In essence, an accounts nominator key could be defined by an additional 32 bytes attached to the account, along with any associated data. - -We need to hold a conversation about (a) what form this associated data should take, and (b) if the space savings are worth the complexity of an implicit certificates scheme, mostly [reviewing the literature](https://github.com/w3f/schnorr-dalek/issues/4). - -We clearly need non-implicit certificates for non-owning nominators. As a result, we might actually reduce the code complexity by not using implicit certificates in the nomination process. We might then achieve better code reuse by not using implicit certificates anywhere. - diff --git a/keys/3-session.md b/keys/3-session.md deleted file mode 100644 index 2daff55..0000000 --- a/keys/3-session.md +++ /dev/null @@ -1,34 +0,0 @@ - - - -## Session keys - -A session public key should consist of roughly four public keys types: - - - Ristretto Schnorr public key (32 bytes public keys, 64 byte signatures, 96 byte VRFs) - - We issue these from the nominator keys acting as validator operators. We might use an implicit certificate but doing so either restricts us to one validator operator, or else increases code complexity and forces a primary validator operator. Implicit certificates also make session key records impossible to authenticate without the nominator account, but this sounds desirable. - - We know signers can easily batch numerous VRF outputs into a single proof with these, ala CloudFlare's Privacy Pass. If we employ these VRFs for block production then signers could periodically publish a "sync digest" that consolidated thousands of their past block production VRFs into a single check, which improves syncing speed. There is also an avenue to batch verify these VRFs by multiply signers, but it requires enlarging the VRF output and proofs from from 96 to 128 bytes. - - - Small curve of BLS12-381 (48 byte public keys, 96 byte signatures) - - Aggregated signatures verify can faster when using this key if the signer set for a particular message is large but irregularly composed, as in GRANDPA. Actual signatures are slower than the opposite orientation, and non-constant time extension field arithmetic makes them even slower, or more risky. Aggregating signatures on the same message like this incurs malleability risks too. We also envision using this scheme in some fishermen schemes. - - We should consider [slothful reduction](https://eprint.iacr.org/2017/437) as discussed in https://github.com/zkcrypto/pairing/issues/98 for these eventually, but initially key splitting should provide solid protection against timing attacks, but with even slower signature speed. - - - Big curve of BLS12-381 (96 bytes public keys, 48 byte signatures) - - Aggregated signatures in which we verify many messages by the same signer verify considerably faster when using this key. We might use these for block production VRFs because they aggregating over the same signer sounds useful for syncing. Initially, we envisioned aggregation being useful for some VRF non-winner proofs designs, but our new non-winner proof design mostly avoids this requirement. Right now, we favor the Ristretto Schnorr VRF for block production because individual instances verify faster and it provides rather extreme batching over the same signer already. - - We also expect faster aggregate verification from these when signer sets get repeated frequently, so conceivably these make sense for some settings in which small curve keys initially sound optimal. We envision signature aggregation being "wild" in GRANDPA, so the small curve key still sounds best there. - - - Authentication key for the transport layer. - - We might ideally include node identity form libp2p, but secio handles authentication poorly ([see the secio discussion](https://forum.web3.foundation/t/transport-layer-authentication-libp2ps-secio/69)). - -A session public key record has a prefix consisting of the above three keys, along with a certificate from the validator operator on the Ristretto Schnorr public key and some previous block hash and height. We follow this prefix with a first signature block consisting two BLS signatures on the prefix, one by each the BLS keys. We close the session public key record with a second signature block consisting of a Ristretto Schnorr signature on both the prefix and first signature block. In this way, we may rotate our BLS12-381 keys without rotating our Ristretto Schnorr public key, possibly buying us some forward security. - -We include the recent block hash in the certificate, so that if the chain were trusted for proofs-of-possession then attackers cannot place rogue keys that attack honestly created session keys created after their fork. We recommend against trusting the chain for proofs-of-possession however because including some recent block hash like this only helps against longer range attacks. - -We still lack any wonderful aggregation strategy for block production VRFs, so they may default to Ristretto Schnorr VRFs. In this case, the Ristretto Schnorr session key component living longer also help minimize attacks on our random beacon. diff --git a/keys/4-secio.md b/keys/4-secio.md deleted file mode 100644 index 47bb5c4..0000000 --- a/keys/4-secio.md +++ /dev/null @@ -1,34 +0,0 @@ -https://forum.web3.foundation/t/transport-layer-authentication-libp2ps-secio/69 - - - -## Transport layer authentication - libp2p's SECIO - -We must authenticate connections as the transport layer from session keys, which could happen in several ways, like signing a hash provided by the transport layer. A priori, we could simplify everything if the session key simply included the static key used in authentication component of the transport layer's key exchange, which might help avoid some security mistakes elsewhere too. - -There are numerous transports for libp2p, but only QUIC was actually designed to be secure. Instead, one routes traffic through [libp2p's secio protocol](https://github.com/libp2p/specs/pull/106). We trust QUIC's cryptographic layer which is TLS 1.3, but secio itself is a home brew job with no serious security analysis, which usually [goes](https://github.com/tendermint/tendermint/issues/3010) [poorly](https://github.com/tendermint/kms/issues/111). - -There has been minimal discussion of secio's security but [Dominic Tarr](https://github.com/auditdrivencrypto/secure-channel/blob/master/prior-art.md#ipfss-secure-channel) raised some concerns in the [original pull request](https://github.com/ipfs/go-ipfs/pull/34). I'll reraise several concerns from that discussion: - -First, there is no effort made to hide secio node keys because "IPFS has no interest in [metadata privacy]" according to Brendan McMillion, so nodes leak their identities onto the raw internet. We think identifying nodes sounds easy anyways, but at minimum this invites attacks. There is an asymmetry to key exchanges that leaks less by first establishing a secure channel and only then authenticating. We might reasonably break this asymmetry by deciding that specific roles require more privacy. We might for example help protect validator operators or improve censorship resistance in some cases, like fishermen. - -Second, there is cipher suit agility in secio, at minimum in their use of multihash, but maybe even in the underlying key exchange itself. We've seen numerous attacks on TLS <= 1.2 due to cipher suit agility, especially the downgrade attacks. I therefore strongly recommend using TLS 1.3 *if* cipher suit agility is required. We could likely version the entire protocol though, thus avoiding any cipher suit agility. In any case, constructs like multihash should be considered hazardous in even basic key exchanges, but certainly in more advanced protocols involving signatures or associated data. - -Third, there are [no ACKs in secio](https://github.com/libp2p/go-libp2p-secio/issues/12) which might yield attacks when a higher level protocol actually depends upon the underlying insecure transport's own ACKs. I suppose UDP transport support already requires higher level protocol handle any required ACKs themselves anyways. ([related](https://github.com/OpenBazaar/openbazaar-go/issues/483)). - -As QUIC uses UDP only, we could add TCP based transport that uses TLS 1.3, perhaps by extending libp2p's existing transport with support for TLS 1.3, or perhaps adding a more flexible TLS 1.3 layer. We might prefer a flexible TLS 1.3 layer over conventional TLS integration into libp2p extending transports because our authentication privacy demands might work differently from TLS's server oriented model. - -We could identify some reasonable [Noise](https://noiseprotocol.org/noise.html) [variant](https://github.com/mcginty/snow), *if* avoiding the complexity of TLS sounds like a priority and ACKs are always handled by higher layers. I believe Noise XX fits the blockchain context well, due to Alice and Bob roles being easily reversible, improved modularity, and more asynchronous key certification from on-chain data. At the extreme, we could imagine identifying particular handshakes for particular interactions though, like GRANDPA using KK and fishermen using NK. - -In short, we should make a new years resolution to replace secio, with our two simplest routes being either TLS 1.3 or Noise XX. - ---- - -Aside from these authentication repairs, there are two additional directions for possible future work: - - - *Post-quantum key exchange.* We'd likely employ LWE scheme here. Right now, CSIDH remains young and slow, but the small key size and long-term keys claims indicate that [CSIDH](https://www.esat.kuleuven.be/cosic/csidh-post-quantum-key-exchange-using-isogeny-based-group-actions/) might integrate better with Noise and blockchains. I'd skip the [existing specification](https://github.com/noiseprotocol/noise_wiki/wiki/Post-Quantum-Noise-with-New-Hope) for integrating Noise with New Hope Simple. Adam Langely has good arguments for [selecting the NTRU variant NRSS+SXY for Google's CECPQ2 experiment](https://www.imperialviolet.org/2018/12/12/cecpq2.html). I the module-LWE [Kyber](https://pq-crystals.org/kyber/) - - *Forward-security.* There is some multi-hop message forwarding in libp2p, but it provides only another addressing technique, not a true connection abstraction layer like say GNUNet's CADET layer. CADET actually employs the Axolotl forward secure ratchet. - - I'm always a fan of both post-quantum and forward security for encryption, but the benefits might prove minimal in our context. - - diff --git a/keys/creation.md b/keys/creation.md deleted file mode 100644 index 29daa6e..0000000 --- a/keys/creation.md +++ /dev/null @@ -1,18 +0,0 @@ -https://forum.web3.foundation/t/account-key-creation-ideas-for-polkadot/68 - - -# Account key creation ideas for Polkadot - -We found a trick for using Ed25519 "mini" private keys in [schnorr-dalek](https://github.com/w3f/schnorr-dalek/blob/master/src/keys.rs), meaning users' "mini" private key consists of 32 bytes of unstructured entropy. - -There are no serious problems with [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) so we suggest a similar strategy for deriving secret keys in Polkadot. We could however modernize BIP39 in a couple small but straightforward ways: - - - *Argon2id should replace PBKDF2.* Adam Langely sugests [using time=2 and 64mb of memopry](https://github.com/golang/crypto/commit/d9133f5469342136e669e85192a26056b587f503) for interactive scenarios like this. In principle, one might question if this scenario should truly be considered interactive, but conversely one could imagine running this on relatively constrained devices. We might also improve the [argone2rs](https://github.com/bryant/argon2rs/issues) crate too, especially to [ensure we use at least v1.3 since v1.2.1 got weaker](https://crypto.stackexchange.com/a/40000). - - *Rejection sampling to support larger wordlists.* We could employ rejection sampling from the initial entropy stream to avoid tying ourselves to the list size being a power of two, as BIP39 seemingly requires. We can provide roughly the existing error correction from BIP32, even working in a ring of this order. - - *Actually provide a larger wordlist.* We're discussing enough entropy that users might benefit form using diceware-like word lists with 12.9 bits of entropy per word, as opposed to BIP32's 11 bits of entropy per word. It's possible some diceware word lists contained confusable words, but reviews exists at least for English. We might worry that larger wordlists might simply not exist for some languges. It's also easier to quickly curate shorter lists. - -There are also more speculative directions for possible improvements: - - - *Improve error correction.* Right now BIP39 has only a basic checksum for error correction. We could design schemes that corrected errors by choosing the words using Reed-Solomon, meaning non-systematic word list creation with code words, except naively this limits our word list sizes to finite field sizes, meaning prime powers. We would instead likely run Reed-Solomon separately on each prime power divisor of the word list's order. We should however evaluate alternatives like other [generalisations of Reed-Solomon codes to rings](https://hal.inria.fr/hal-00670004/file/article.pdf), or even working in a field of slightly larger order and reject choices that fall outside the wordlist. - - *Support multiple Argon2id configurations.* We might conceivably support multiple argon2id configurations, if small device constraints become a serious concern. We could select among a few argon2id configuration options using yet another output from the Reed-Solomon code. We'd simply use rejection sampling to choose the user's desired configuration. -