<span style="font-family: Arial;">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&#39;s cert <br><br>-derek<br><br>Sent from my HTC smartphone<br><br>----- Reply message -----<br>From: &quot;Alex Carver&quot; &lt;agcarver+ale@acarver.net&gt;<br>To: &lt;ale@ale.org&gt;<br>Subject: [ale] Documentation of SSH exchange (including math)<br>Date: Tue, Sep 4, 2012 5:59 PM<br><br></span><br>On 9/4/2012 15:50, David Tomaschik wrote:<br>&gt; On Sun, Sep 2, 2012 at 10:58 PM, Alex Carver &lt;agcarver+ale@acarver.net&gt; wrote:<br>&gt;&gt; Looks like that&#39;s what I&#39;m going to have to do. &nbsp;I read through the RFCs<br>&gt;&gt; but they are overly complicated when I&#39;m really looking for the basic<br>&gt;&gt; flow of data without the protocol negotiation overhead. &nbsp;I&#39;m trying to<br>&gt;&gt; figure out how the host keys are first used followed by the user&#39;s keys<br>&gt;&gt; to authenticate the host (well, identify it and note if there was a<br>&gt;&gt; change) and then the message exchange that authenticates a user based on<br>&gt;&gt; the user&#39;s keys.<br>&gt;&gt;<br>&gt;&gt; I&#39;m trying to replicate the basic crypto exchange but strip away all the<br>&gt;&gt; overhead of the SSH negotiations. &nbsp;My application is going to assume<br>&gt;&gt; only one exchange type is occurring. &nbsp;It&#39;s not intended to be a generic<br>&gt;&gt; SSH/SSL protocol. &nbsp; The end result is an application that verifies the<br>&gt;&gt; server is the proper one, the server verifies the client/user is the<br>&gt;&gt; proper one, the client announces its presence to the server and that&#39;s<br>&gt;&gt; pretty much it, the process ends. &nbsp;So I don&#39;t need to support half a<br>&gt;&gt; million encryption techniques (I&#39;ll likely stick with long RSA keys as<br>&gt;&gt; the user keys), multiple SSH protocols, shell access, or anything else.<br>&gt;&gt; &nbsp; &nbsp;Just the server and user key exchanges to authenticate the server and<br>&gt;&gt; the client.<br>&gt;<br>&gt; Is there a reason SSH has to be the model? &nbsp;You can use x509 certs and<br>&gt; link in OpenSSL or GnuTLS and authenticate &amp; encrypt that way. &nbsp;Don&#39;t<br>&gt; roll your own crypto. &nbsp;Even if you get the math right, getting the<br>&gt; implementation details right is subtly hard.<br>&gt;<br>&gt; What kind of an implementation are you going for where the overhead of<br>&gt; SSH is significant? &nbsp;Must be a very small embedded device if that&#39;s a<br>&gt; big implementation concern.<br>&gt;<br><br>Yes, the end goal is a pair of embedded devices that will authenticate <br>between themselves (mostly for fun). &nbsp;Since I only need to exchange <br>small control messages I don&#39;t need full shells or other large libraries <br>but I do need the basics of the authentication scheme. &nbsp;I&#39;m using SSH as <br>the model because the process flow performs the host check followed by <br>the user authentication via key. &nbsp;If I can understand that basic flow <br>and exactly what numbers are being computed where then I can replicate <br>that on embedded hardware with certain assumptions in place (e.g. keys <br>are RSA, the handshake is always the same, no negotiations for <br>encryption type occur, etc.).<br><br>_______________________________________________<br>Ale mailing list<br>Ale@ale.org<br>http://mail.ale.org/mailman/listinfo/ale<br>See JOBS, ANNOUNCE and SCHOOLS lists at<br>http://mail.ale.org/mailman/listinfo<br>