[cryptography] Application Layer Encryption Protocols Tuned for Cellular?
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 .
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).
> 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.
 Nod to Mosh. I tried to do something similar with SSH, a bow to
those who succeeded.
More information about the cryptography