Gemini privacy

Phil Leblanc philanc at
Tue Mar 9 23:04:10 GMT 2021

On Tue, Mar 9, 2021 at 6:36 PM <nothien at> 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[1], it appears not.  Oh well.
> [1]:

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 mailing list