Re: ECC

[Alan Dunn <amdunn@xxxxxxxxx>]

Oops, I think the documentation is largely right in describing the
meaning of the value (though I think it can be a list and the
documentation seems to suggest that it must be a single value).

On Sat, Feb 15, 2014 at 8:50 AM, Alan Dunn <amdunn@xxxxxxxxx> wrote:
> I actually like the ability to specify exactly what algorithms I think
> I'm using key-wise, but maybe that's just me.
>
> I would note that it seems like the option SSH_BIND_OPTIONS_HOSTKEY
> does something different at the moment than what we might expect.  It
> calls ssh_bind_options_set_algo, so this option actually sets the
> algorithms that the server will allow.  So perhaps this should be
> changed in the documentation.  If we're going to make a new option
> like Aris proposes, then we might want to pick a new name to keep old
> code working, unless the current behavior is considered a bug.
>
> Thanks,
> - Alan
>
> On Sat, Feb 15, 2014 at 7:05 AM, Aris Adamantiadis <aris@xxxxxxxxxxxx> wrote:
>> Hi everybody,
>>
>> This is also my fault, I worked a lot on server side last year and never
>> bothered checking if the server was accepting ecdsa keys.
>> Regarding the API, is there any advantage in adding an option specific
>> to ECDSA ?
>> I see there's already SSH_BIND_OPTIONS_HOSTKEY and if we follow
>> OpenSSH's semantics:
>>      HostKey
>>              Specifies a file containing a private host key used by
>> SSH.  The default is
>>              /etc/ssh/ssh_host_key for protocol version 1, and
>> /etc/ssh/ssh_host_dsa_key,
>>              /etc/ssh/ssh_host_ecdsa_key and /etc/ssh/ssh_host_rsa_key
>> for protocol version
>>              2.  Note that sshd(8) will refuse to use a file if it is
>> group/world-accessi-
>>              ble.  It is possible to have multiple host key files.
>> ``rsa1'' keys are used
>>              for version 1 and ``dsa'', ``ecdsa'' or ``rsa'' are used
>> for version 2 of the
>>              SSH protocol.
>> This option should also work with ecdsa, is standard (maps to an openssh
>> settings) and doesn't require the caller to know the type of key beforehand.
>>
>> Aris
>>
>> Le 15/02/14 11:27, Andreas Schneider a écrit :
>>> On Friday 14 February 2014 16:41:42 you wrote:
>>>> For what it's worth, the attached patch should at fix the missing
>>>> option (and remove some duplication in the key option code).
>>> Thanks for your patch. I have some comments.
>>>
>>> @@ -42,6 +42,7 @@ enum ssh_bind_options_e {
>>>    SSH_BIND_OPTIONS_HOSTKEY,
>>>    SSH_BIND_OPTIONS_DSAKEY,
>>>    SSH_BIND_OPTIONS_RSAKEY,
>>> +  SSH_BIND_OPTIONS_ECDSAKEY,
>>>    SSH_BIND_OPTIONS_BANNER,
>>>    SSH_BIND_OPTIONS_LOG_VERBOSITY,
>>>    SSH_BIND_OPTIONS_LOG_VERBOSITY_STR
>>>
>>> This will break the ABI. The option should be added at the end of the enum!
>>>
>>> I know that the style is pretty broken in libssh and I need to write a
>>> styleguide. Please use 4 spaces and pki.c or pki_crypt.c should be the style
>>> to use.
>>>
>>>
>>> if (ssh_bind_set_key(sshbind, &sshbind->dsakey, value) < 0) {
>>>
>>> should be:
>>>
>>> rc = ssh_bind_set_key(sshbind, &sshbind->dsakey, value);
>>> if (rc < 0) {}
>>>
>>> http://blog.cryptomilk.org/2013/03/28/writing-and-reading-code/
>>>
>>>
>>> I will integrate the full example soon. So we can work on that and extend it
>>> with ecdsa support.
>>>
>>>
>>>
>>>       -- andreas
>>>
>>>
>>
>>