[ale] Documentation of SSH exchange (including math)

[David Tomaschik]

On Tue, Sep 4, 2012 at 11:33 PM, Alex Carver <agcarver+ale at acarver.net> wrote:
> 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.

Define "small microcontroller".  Hopefully we're not talking about a
PIC or AVR here :)  Not sure if even a 32-bit AVR would have anywhere
near the power for even basic crypto.

Is it authentication only, or do you need confidentiality as well?  If
authentication only, you could use a CRAM algorithm or basically any
HMAC with a PSK.

David

> 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



-- 
David Tomaschik
OpenPGP: 0x5DEA789B
http://systemoverlord.com
david at systemoverlord.com