Dear friends, Request For Criticism about what I've written: Current blockchains are all genesis-block based, which means they are ever-growing structures. Aside of being under the effects of an elastic-gum force that complicates their scalability in size, there exist problems scaling on addresses or scaling on bandwith. What touches to cryptography comes straight when dealing of ever-growing structures. Such a buried pile of layers of information requires consideration because it contains cryptography of past times. There are two problems with that. 1.- can expire secrets. 2.- The runtime software must be equiped with all cypher-suites used in the past, including those too old to rely on who were already cracked, broken. A challenge is the to design a platform that does not depend on cypher-suites that were needed in the past. Once a new encryption technology deprecates another, the platform must be able to replace the cypher-suite and forget about the previous one. Thanks, Regards : ) -- OA
On Thu, Feb 06, 2020 at 08:55:20PM +0000, other.arkitech wrote:
Dear friends,
Request For Criticism about what I've written:
Current blockchains are all genesis-block based, which means they are ever-growing structures. Aside of being under the effects of an elastic-gum force that complicates their scalability in size, there exist problems scaling on addresses or scaling on bandwith. What touches to cryptography comes straight when dealing of ever-growing structures. Such a buried pile of layers of information requires consideration because it contains cryptography of past times. There are two problems with that. 1.- can expire secrets. 2.- The runtime software must be equiped with all cypher-suites used in the past, including those too old to rely on who were already cracked, broken.
A challenge is the to design a platform that does not depend on cypher-suites that were needed in the past. Once a new encryption technology deprecates another, the platform must be able to replace the cypher-suite and forget about the previous one.
After the Git (ongoing) fiasco around the SHA hash transition, for anyone who missed the memo a base requirement to any sane solution is a protocol version number at the very beginning of your comms. If that version number increases, future versions can decide what to do, regardless of $TODAYS assumptions being right or wrong. But (as with Git), when even a version # does not exist, you have the mess of deep protocol diving to determine some arcane corner case which implies the old vs some new, version, or perhaps a massive global flag day to simply drop the old (i.e. current) protocol altogether. In other words, don't build in such pain - begin all communications with a version number. <don't take it personally but> You are not smart enough to know all the future proto/crypto/etc-o changes that might be required, should your software - or even just your protocol - prove to become popular one day.
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 6, 2020 11:34 PM, Zenaan Harkness <zen@freedbms.net> wrote:
On Thu, Feb 06, 2020 at 08:55:20PM +0000, other.arkitech wrote:
Dear friends, Request For Criticism about what I've written: Current blockchains are all genesis-block based, which means they are ever-growing structures. Aside of being under the effects of an elastic-gum force that complicates their scalability in size, there exist problems scaling on addresses or scaling on bandwith. What touches to cryptography comes straight when dealing of ever-growing structures. Such a buried pile of layers of information requires consideration because it contains cryptography of past times. There are two problems with that. 1.- can expire secrets. 2.- The runtime software must be equiped with all cypher-suites used in the past, including those too old to rely on who were already cracked, broken. A challenge is the to design a platform that does not depend on cypher-suites that were needed in the past. Once a new encryption technology deprecates another, the platform must be able to replace the cypher-suite and forget about the previous one.
After the Git (ongoing) fiasco around the SHA hash transition, for anyone who missed the memo a base requirement to any sane solution is a protocol version number at the very beginning of your comms.
If that version number increases, future versions can decide what to do, regardless of $TODAYS assumptions being right or wrong.
But (as with Git), when even a version # does not exist, you have the mess of deep protocol diving to determine some arcane corner case which implies the old vs some new, version, or perhaps a massive global flag day to simply drop the old (i.e. current) protocol altogether.
In other words, don't build in such pain - begin all communications with a version number.
A minimal solution is to mechanize protocol versioning is to have only 2 version implementations of the protocol, same concept of double-buffer applied to algorithms instead of data. Having only to maintain the 'current version' and the 'previous version'. This scheme only works in systems that are automatically updated because nodes that require human intervention will easily lose sync with the network.
<don't take it personally but> You are not smart enough to know all the future proto/crypto/etc-o changes that might be required, should your software - or even just your protocol - prove to become popular one day.
I don't know the future of crypto all I bet is they will provide hasing, signing, verifying and encryption capabilities using public key infrastructure. With this abstraction, and a systematic way of evolving the version of the protocol that can discard previously-used cyber-suites is what a platform needs from cryptography to enforce privacy.
participants (2)
-
other.arkitech -
Zenaan Harkness