[cryptography] Application Layer Encryption Protocols Tuned for Cellular?

ianG iang at iang.org
Sat Nov 3 18:25:37 EDT 2012

On 1/11/12 10:55 AM, Peter Gutmann wrote:
> Jeffrey Walton <noloader at gmail.com> writes:
>> Is anyone aware of of application layer encryption protocols with session
>> management tuned for use on cellular networks?
>> [...]
>  From that description your problem isn't at the encryption-protocol level at
> all, you need a reliable transport mechanism for cellular networks,

Sounds like.  The short answer is:  use UDP datagrams [1].

This is a good answer because in doing so you will be forced to 
construct your own reliable transport mechanisms over UDP, as and when 
you discover the various failure cases.  (e.g., a lesson of discovery, fun!)

It's not such a good answer if your team is used to ignoring all those 
problems by using TCP and thinking they're done 'n dusted.  It's not a 
good answer if you are thinking you can do some quick tweaks to an 
existing app - as in practice it probably relies on TCP in which case 
the entire design is poisoned with the assumptions therein (more below).

> something
> that's totally independent of what crypto you're using.  Then you run your
> favourite crypto over that.

I'm not convinced of that.  This whole concept of 'layering' as a useful 
simplification kind of took a wrong turn around the late 1980s with 
ISO's 7 layer model.  Although a useful abstraction, it led people into 
thinking that if they built protocols for each layer then they could 
plug them in together and everything would be fine!  Science has 
triumphed again!  Let's mandate a set of protocols in each layer!

In practice, the 7 layer model was not an implementation recipe - TCP/IP 
in the broader Internet sense showed that engineering required working 
with the tech of the time, not the abstractions from some CS class or 
government contract sales team.  TCP in the narrow sense shows it again 
- sticking TCP in layer 4 and stopping there doesn't work - it claims 
everything is a stream, when 'everything is a datagram' is closer to the 
truth, and a more useful assumption.  TCP further assumes it can 
reliably deliver data, when actually it's only reliable enough if you 
care only enough to do the demo.

Also, crypto tends to solve things that apply broadly across the layers, 
so if a design incorporates crypto right from the start, and uses those 
results broadly, benefits ensue.  E.g., if the top level negotiates a 
secret key for a hmac-encrypted packet delivery, the rest of the 
'layers' don't need to worry about conventional session management and 
authentication;  which leads to the agility required in OP's use case - 
taking packets in from multiple IP#s and carrying on, knowing they came 
from the same secret key.


[1] Nod to Mosh.  I tried to do something similar with SSH, a bow to 
those who succeeded.

More information about the cryptography mailing list