💾 Archived View for gemi.dev › gemini-mailing-list › 000255.gmi captured on 2024-08-18 at 23:59:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
For those interested: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6806263/ A quick summary, focussing on stuff relevant for TLS 1.3 or TLS 1.2 limited to TLS 1.3 ciphersuites: on tested Samsung and Xioami phones, ChaCha20-Poly1305 is both faster and consumes less battery than AES in GCM mode - and it's not a small difference, either. This will not necessarily generalise to PCs with modern Intel CPUs in them, which can have dedicated hardware instructions for AES. But on phones, tablets, RaspberryPi's etc. it is very likely the case that prefering ChaCha20-Poly1305 over AES will make Gemini faster and greener. TLS allows both the server and client to express a preference for ciphersuites, and IIRC it's up to the server to decide whether its preferences or the client's have the final say. It seems to me that servers running on VPSes, or otherwise in scenarios where they have reliable and abundant power, ought to defer to the client's preferences (at least by default), that mobile clients ought to explicitly prefer ChaCha20-Poly1305 over AES, and that non-mobile clients ought to allow users to configure this preference for themselves. People using RPis, older PCs without hardware AES support, etc. can then configure a ChaCha20-Poly1305 preference and things will be faster for them. Maybe not noticably faster to the naked eye, but faster. Cheers, Solderpunk
On Friday 26 June 2020 15:33, solderpunk <solderpunk at SDF.ORG> wrote: > https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6806263/ Thanks! All modern smartphone have AES in hardware. >From the article: "The Xiaomi device, having an ARMv8-a architecture, has support for AES hardware acceleration. " Yesterday AES-128 was sufficient. Today AES-256 make states happy. Tomorrow we will have to use AES-384 or its successor. This is endless. Maybe one day a quantum-like way will definitely fix this. Maybe to solution to avoid latency for each request is to make first a encrypted tunnel to the gemini server and then use this tunnel to perform each single request? Like surfing using sftp:// :-) freD.
> On Jun 26, 2020, at 17:54, defdefred <defdefred at protonmail.com> wrote: > > Maybe to solution to avoid latency for each request is to make first a encrypted tunnel to the gemini server and then use this tunnel to perform each single request? Or have gemini support persistent connections, as the Gemini streaming talks are suggesting. In regards to mandating TLS, there was talk to move the TLS requirement into a separate Gemini TLS profile instead, allowing for a Gemini 'plain' profile, which could run over wireguard or such [1][2]. [1] gemini://gemi.dev/gemini-mailing-list/messages/001267.gmi [2] https://tailscale.com/blog/remembering-the-lan/
It was thus said that the Great Petite Abeille once stated: > > > On Jun 26, 2020, at 17:54, defdefred <defdefred at protonmail.com> wrote: > > > > Maybe to solution to avoid latency for each request is to make first a > > encrypted tunnel to the gemini server and then use this tunnel to > > perform each single request? > > Or have gemini support persistent connections, as the Gemini streaming > talks are suggesting. > > In regards to mandating TLS, there was talk to move the TLS requirement > into a separate Gemini TLS profile instead, allowing for a Gemini 'plain' > profile, which could run over wireguard or such [1][2]. I think "plain" Gemini would me Mercuri (Gemini sans TLS). Also, using wireguard would require a client to use a library/software program/kernel module, unlike TLS, which just requires a library. But hey, prove me wrong---get a working Gemini server and client using wiregard and tell us how easy it is. > [1] gemini://gemi.dev/gemini-mailing-list/messages/001267.gmi > [2] https://tailscale.com/blog/remembering-the-lan/ -spc
---