philanc at gmail.com
Tue Mar 9 23:04:10 GMT 2021
On Tue, Mar 9, 2021 at 6:36 PM <nothien at uber.space> wrote:
> Do you mean "rounding up" (by adding padding) all sent data to 4,096
> bytes? I agree, that should do quite well to hide most Gemini data.
Yes. When record padding is configured to a value X, all sent data is
padded (of course before stream encryption) up to the next multiple of
X. So with record_padding = 4096,
a 1.5KB file is padded to exactly 4,096 bytes. A 5 KB file is padded
to 8,192 bytes.
A nice mechanism which is well suited to typical Gemini files
(according to Stephane Bortzmeyer's stats, 80% of pages are below
> > Just writing this, I am wondering... with TLS 1.3, can the _client_
> > request record padding for the server response?
> Reading the TLS 1.3 spec, it appears not. Oh well.
> : https://tools.ietf.org/html/rfc8446#section-5.4
Section 5.4 concludes with "Later documents may define padding
selection algorithms or define a padding policy request mechanism
through TLS extensions or some other means"
"Later documents..." So I guess, yes we are not there yet.
> P.S: I've been thinking about all the issues we've come across with TLS,
> and I've been collecting ideas for a new transport security protocol. I
> know ~spc's stance on crypto ("get it approved by the crypto community,
> make an implementation, then we'll talk"),
I think Sean Conner's statement is rhetoric or tongue-in-cheek :-)
Whether one likes it or not, Gemini IS built upon TLS. Period. That
ship has sailed. So I understand Sean (and others) want to limit
entropy in the mailing list
> (...) making a wishlist of sorts of all the things that we
> would want out of a "good" transport security protocol (if you have any
> such ideas, please share them with me). I'll put up my crypto wishlist
> sometime soon.
I will be happy to have a look at what you publish and share ideas -
but probably not about this topic in this mailing list... :-)
More information about the Gemini