[ale] Documentation of SSH exchange (including math)

[derek at ihtfp.com (Derek Atkins)]

Why not SSL with client certificate authentication? That has the same crypto flow. The real question in all cases is how to trust the other's cert 

-derek

Sent from my HTC smartphone

----- Reply message -----
From: "Alex Carver" <agcarver+ale at acarver.net>
To: <ale at ale.org>
Subject: [ale] Documentation of SSH exchange (including math)
Date: Tue, Sep 4, 2012 5:59 PM


On 9/4/2012 15:50, David Tomaschik wrote:
> On Sun, Sep 2, 2012 at 10:58 PM, Alex Carver <agcarver+ale at acarver.net> wrote:
>> Looks like that's what I'm going to have to do.  I read through the RFCs
>> but they are overly complicated when I'm really looking for the basic
>> flow of data without the protocol negotiation overhead.  I'm trying to
>> figure out how the host keys are first used followed by the user's keys
>> to authenticate the host (well, identify it and note if there was a
>> change) and then the message exchange that authenticates a user based on
>> the user's keys.
>>
>> I'm trying to replicate the basic crypto exchange but strip away all the
>> overhead of the SSH negotiations.  My application is going to assume
>> only one exchange type is occurring.  It's not intended to be a generic
>> SSH/SSL protocol.   The end result is an application that verifies the
>> server is the proper one, the server verifies the client/user is the
>> proper one, the client announces its presence to the server and that's
>> pretty much it, the process ends.  So I don't need to support half a
>> million encryption techniques (I'll likely stick with long RSA keys as
>> the user keys), multiple SSH protocols, shell access, or anything else.
>>    Just the server and user key exchanges to authenticate the server and
>> the client.
>
> Is there a reason SSH has to be the model?  You can use x509 certs and
> link in OpenSSL or GnuTLS and authenticate & encrypt that way.  Don't
> roll your own crypto.  Even if you get the math right, getting the
> implementation details right is subtly hard.
>
> What kind of an implementation are you going for where the overhead of
> SSH is significant?  Must be a very small embedded device if that's a
> big implementation concern.
>

Yes, the end goal is a pair of embedded devices that will authenticate 
between themselves (mostly for fun).  Since I only need to exchange 
small control messages I don't need full shells or other large libraries 
but I do need the basics of the authentication scheme.  I'm using SSH as 
the model because the process flow performs the host check followed by 
the user authentication via key.  If I can understand that basic flow 
and exactly what numbers are being computed where then I can replicate 
that on embedded hardware with certain assumptions in place (e.g. keys 
are RSA, the handshake is always the same, no negotiations for 
encryption type occur, etc.).

_______________________________________________
Ale mailing list
Ale at ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120904/fb327e09/attachment.html