Regarding `gemini://` over NaCL (replacing TLS)

[Sean Conner]

  I think I'm going to bow out of the encryption talk.  It's clear to me
that I feel TLS is good enougn, and Ciprian doesn't (or would rather have
alternatives).  I'm not the creator of the Gemini protocol, so I don't have
the authority to make drastic changes to the protocol.

  I've heard the admonintion to not roll your own crypto, and I believe that
it extends to protocols as well.  And as bad and complex as TLS might be,
it's a standard, there are real cryptographers trying to break it, and there
are multiple implementations of it available: OpenSSL and LibreSSL are two,
but off the top of my head, there are also bearSSL, PolarSSL, boringSSL. and
GNUTLS.  And in a sense, that makes it easier to use, since these
implementations *exit*.  This new protocol Ciprian is designing hasn't been
vetted, and I'm unaware of anyone on this list that is expert enough in
crypto to fully examine it.

  And Ciprian wants to design a new secure protocol ... 

  Anyway, a few comments about this message.

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Mon, Mar 2, 2020 at 2:18 AM Sean Conner <sean at conman.org> wrote:
> > 1) I assume the 32-bit length is sent bigendian (if I understand the
> > argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> > programmer).  Why big endian?  99% of all computers on the Internet today is
> > little endian (x86) so it seems to me that sending it little endian would be
> > better.  [1][2]
> >
> > [1]     Okay, I happen to agree with the big endian choice, but that's
> >         because I'm biased---binary based Internet protocols are all big
> >         endian, and I have a soft spot for the Motorola CPUs of past.  I've
> >         never been a fan of little endian personally.
> >
> > [2]     I'm also asking to reflect back to you the same argument you
> >         presented with using CRLF.  Your big endian choice seems to be
> >         "because that's how all Internet protocols do it".
> 
> There are a couple of reasons I like big endian for protocols:
> 
> * it is logical;  for example although all integers are stored in
> little endian on x86, when we write numbers in code we use "big
> endian";

  We use the Arabic numerals these days.  It's interesting to note that the
value three hundred and twenty-one is written in the order of 321 in Arabic
(much like in Western countries) but Arabic itself is written right-to-left,
so one could say they write their numbers in little endian format.  You're
just expressing a western bias---logic has nothing to do with it 8-P

> * (and most importantly) when dumping a protocol capture there are no
> "surprises", I read the number left to right, and if I just take the
> bytes in hex and concatenate them I can get the constant, i.e. `[01 02
> 03 04]` is just `0x01020304`;

  And it'd be backwards for Arabic programmers.

  -spc