On 1/11/12 10:55 AM, Peter Gutmann wrote:
Jeffrey Walton <[email protected]> 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.



iang


[1] Nod to Mosh. I tried to do something similar with SSH, a bow to those who succeeded.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to