On 4/11/12 10:17 AM, Jeffrey Walton wrote:
On Sat, Nov 3, 2012 at 6:25 PM, ianG <[email protected]> wrote:
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).
My observation after self-reflection: TCP/IP is so ingrained, I was
subconsciously depending upon the "connection oriented, reliableness"
it offered - it was a session management crutch (albeit an "untrusted
session" management crutch).
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!
I'm not convinced either. In the past, I used to feel that way, but
I'm reconciling it now.
I recently had the epiphany: the crypto layer must have some
rudimentary session management stuff. Session management is clearly
outside the realm of crypto. Session management is usually handled
higher in the stack.
Yes, exactly. The crypto provides the basis for the session management.
(I'm not sure why you say it is outside realm of crypto, I'm wondering
if this might just be another customary assumption that has to be
unlearned.)
Rudimentary session management is required for fast recovery in the
cellular environment. Previously, the implied session was the tuple
{Client IP, Client Port, Server IP, Sever Port}. Because of TCP/IP
tricks being played by handset manufacturers, carriers, and OS
provided connection managers, it is no longer reliable. My apologies
if I incorrectly fingered someone here.
I think the on-wire and over-the-air message format needs to be changed to:
{Session ID, IV, Encrypted Data, Auth Tag}
I clearly need an authenticated encryption mode with AAD. I'm
researching the implications of a plain text Session ID.
Heuristically, its no worse then the previous plain text {Client IP,
Client Port, Server IP, Sever Port}.
Yep, that's pretty much what we did [1]:
{Session ID, Encrypted Data, Auth Tag}
That which was traditionally an IV became split between some additional
secret session data and a unique header as first block of plaintext packet.
Then, to initiate the session, one needs at the application layer
something like a public/private key pair [2] which CodesInChaos also
hinted at. A single signed-encrypted-request-response sets up a shared
secret for the session:
{client-encrypt-key, client-IV, client-HMAC-tag,
server-encrypt-key, server-IV, server-HMAC-tag}
[3].
By having an explicit Session ID, it does not matter what UDP socket
sends the message. I believe it allows for the fast recovery I am
seeking.
Yep! Or, it makes the system agnostic to sender-IP-address. If that's
what you call recovery, that's fine, I'd say it is just casting off a
troublesome and unneeded assumption.
iang
[1] We being Zooko and I, it being SDP1. Documented to some extent at
http://webfunds.org/guide/sdp/
but apparently offline atm. Google caches at
http://webcache.googleusercontent.com/search?q=cache:http://webfunds.org/guide/sdp/
[2] C.f. John Day's 'slate' slides: the public key can be seen as the
identifier of the application, or 'application name.' The private key
can perform the crypto task of the authentication, for the IPC
Authentication Protocol (IAP).
[3] Notes: On the plus side, the session can be set up with only 2
messages, one there, one back. Consequently it is a lot faster and more
reliable than that old SSL-over-TCP thing, which seems to revel in setup
costs.
This approach also assumes multiple & easy sessions, being lightweight
and promiscuous. Which contrasts with your "only one session"
requirement. I'm not sure why you would want that, tho, as
single-sessions seems to be a bandaid put over a broken model, not a
high level requirement, with value in and of itself.
On the negative side, this entire approach will cause so much change in
your code & application you'll likely be looking at a complete re-write.
At least, that's what happened to me.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
