[ale] Documentation of SSH exchange (including math)

[Alex Carver]

Trusting the certificates or host keys on the two ends isn't a problem 
in this case.  In my implementation design, the two sets of host keys 
and user keys are installed on both ends of the link via an OOB 
connection (using a desktop machine to do the heavy lifting for key 
generation).  So both ends are trusted in this case.

I'll investigate SSL/cert and see how that goes through.  In any case 
whatever I use has to fit on a small microcontroller.

On 9/4/2012 19:17, Derek Atkins wrote:
> 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
>
>
>
> _______________________________________________
> 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
>