💾 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

View Raw

More Information

⬅️ Previous capture (2023-12-28)

-=-=-=-=-=-=-

Real world data on TLS power consumption on mobile devices

1. solderpunk (solderpunk (a) SDF.ORG)

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

Link to individual message.

2. defdefred (defdefred (a) protonmail.com)

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.

Link to individual message.

3. Petite Abeille (petite.abeille (a) gmail.com)



> 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/

Link to individual message.

4. Sean Conner (sean (a) conman.org)

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

Link to individual message.

---

Previous Thread: SVG Bob

Next Thread: TLS certificate sizes in Geminispace