[ale] Documentation of SSH exchange (including math)

[Derek Atkins]

Hi,

Alex Carver <agcarver+ale at acarver.net> writes:

> 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.

Does it have to be free?
The company I work for sells an embedded SSL toolkit just for this purpose.

-derek

> 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
>>
>
> _______________________________________________
> 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
>
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available