Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 6, 2020 11:34 PM, Zenaan Harkness <z...@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.
