github
/
putty
зеркало из https://github.com/github/putty.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
putty/sshdss.c

509 строки
14 KiB
C
Исходник Обычный вид История

Sprinkle some header comments in various files in an attempt to explain what they're for. [originally from svn r6639]
2006-04-23 22:26:03 +04:00
/*
* Digital Signature Standard implementation for PuTTY.
*/
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
#include <stdio.h>
#include <stdlib.h>
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
#include <assert.h>
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
#include "ssh.h"
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
#include "misc.h"
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
static void dss_freekey(ssh_key *key); /* forward reference */
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
static ssh_key *dss_new_pub(const ssh_keyalg *self, ptrlen data)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
BinarySource src[1];
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
struct dss_key *dss;
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
BinarySource_BARE_INIT(src, data.ptr, data.len);
if (!ptrlen_eq_string(get_string(src), "ssh-dss"))
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
return NULL;
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
dss = snew(struct dss_key);
Make ssh_key and ssh{2,1}_cipher into structs. In commit 884a7df94 I claimed that all my trait-like vtable systems now had the generic object type being a struct rather than a bare vtable pointer (e.g. instead of 'Socket' being a typedef for a pointer to a const Socket_vtable, it's a typedef for a struct _containing_ a vtable pointer). In fact, I missed a few. This commit converts ssh_key, ssh2_cipher and ssh1_cipher into the same form as the rest.
2018-11-27 00:02:28 +03:00
dss->sshk.vt = &ssh_dss;
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
dss->p = get_mp_ssh2(src);
dss->q = get_mp_ssh2(src);
dss->g = get_mp_ssh2(src);
dss->y = get_mp_ssh2(src);
Sanitise freeing of DSA keys. [originally from svn r9984]
2013-08-04 23:33:43 +04:00
dss->x = NULL;
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
if (get_err(src) ||
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
!bignum_cmp(dss->q, Zero) || !bignum_cmp(dss->p, Zero)) {
/* Invalid key. */
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
dss_freekey(&dss->sshk);
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
return NULL;
}
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
return &dss->sshk;
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
}
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
static void dss_freekey(ssh_key *key)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct dss_key *dss = container_of(key, struct dss_key, sshk);
Sanitise freeing of DSA keys. [originally from svn r9984]
2013-08-04 23:33:43 +04:00
if (dss->p)
freebn(dss->p);
if (dss->q)
freebn(dss->q);
if (dss->g)
freebn(dss->g);
if (dss->y)
freebn(dss->y);
if (dss->x)
freebn(dss->x);
Make memory management uniform: _everything_ now goes through the smalloc() macros and thence to the safemalloc() functions in misc.c. This should allow me to plug in a debugging allocator and track memory leaks and segfaults and things. [originally from svn r818]
2000-12-12 13:33:13 +03:00
sfree(dss);
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
}
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
static char *dss_cache_str(ssh_key *key)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct dss_key *dss = container_of(key, struct dss_key, sshk);
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
char *p;
Rationalised host key storage. Also started code reorg: persistent-state routines have been moved out into a replaceable module winstore.c. [originally from svn r639]
2000-09-27 19:21:04 +04:00
int len, i, pos, nibbles;
static const char hex[] = "0123456789abcdef";
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
if (!dss->p)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
return NULL;
len = 8 + 4 + 1; /* 4 x "0x", punctuation, \0 */
len += 4 * (bignum_bitcount(dss->p) + 15) / 16;
len += 4 * (bignum_bitcount(dss->q) + 15) / 16;
len += 4 * (bignum_bitcount(dss->g) + 15) / 16;
len += 4 * (bignum_bitcount(dss->y) + 15) / 16;
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
p = snewn(len, char);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
if (!p)
return NULL;
Rationalised host key storage. Also started code reorg: persistent-state routines have been moved out into a replaceable module winstore.c. [originally from svn r639]
2000-09-27 19:21:04 +04:00
pos = 0;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
pos += sprintf(p + pos, "0x");
nibbles = (3 + bignum_bitcount(dss->p)) / 4;
if (nibbles < 1)
nibbles = 1;
for (i = nibbles; i--;)
p[pos++] =
hex[(bignum_byte(dss->p, i / 2) >> (4 * (i % 2))) & 0xF];
pos += sprintf(p + pos, ",0x");
nibbles = (3 + bignum_bitcount(dss->q)) / 4;
if (nibbles < 1)
nibbles = 1;
for (i = nibbles; i--;)
p[pos++] =
hex[(bignum_byte(dss->q, i / 2) >> (4 * (i % 2))) & 0xF];
pos += sprintf(p + pos, ",0x");
nibbles = (3 + bignum_bitcount(dss->g)) / 4;
if (nibbles < 1)
nibbles = 1;
for (i = nibbles; i--;)
p[pos++] =
hex[(bignum_byte(dss->g, i / 2) >> (4 * (i % 2))) & 0xF];
pos += sprintf(p + pos, ",0x");
nibbles = (3 + bignum_bitcount(dss->y)) / 4;
if (nibbles < 1)
nibbles = 1;
for (i = nibbles; i--;)
p[pos++] =
hex[(bignum_byte(dss->y, i / 2) >> (4 * (i % 2))) & 0xF];
Rationalised host key storage. Also started code reorg: persistent-state routines have been moved out into a replaceable module winstore.c. [originally from svn r639]
2000-09-27 19:21:04 +04:00
p[pos] = '\0';
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
return p;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
static bool dss_verify(ssh_key *key, ptrlen sig, ptrlen data)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct dss_key *dss = container_of(key, struct dss_key, sshk);
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
BinarySource src[1];
unsigned char hash[20];
Make the frankly ridiculous prototypes for modpow() and modmul() more sane [originally from svn r752]
2000-10-23 20:11:31 +04:00
Bignum r, s, w, gu1p, yu2p, gu1yu2p, u1, u2, sha, v;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool toret;
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
if (!dss->p)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
return false;
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
BinarySource_BARE_INIT(src, sig.ptr, sig.len);
Work around DSA formatting bug in commercial-SSH 2.0.13 [originally from svn r665]
2000-10-03 13:05:56 +04:00
/*
* Commercial SSH (2.0.13) and OpenSSH disagree over the format
Replace mentions of SSH-2 I-Ds with references to the corresponding RFCs. [originally from svn r7759]
2007-10-04 01:21:18 +04:00
* of a DSA signature. OpenSSH is in line with RFC 4253:
Work around DSA formatting bug in commercial-SSH 2.0.13 [originally from svn r665]
2000-10-03 13:05:56 +04:00
* it uses a string "ssh-dss", followed by a 40-byte string
* containing two 160-bit integers end-to-end. Commercial SSH
* can't be bothered with the header bit, and considers a DSA
* signature blob to be _just_ the 40-byte string containing
* the two 160-bit integers. We tell them apart by measuring
* the length: length 40 means the commercial-SSH bug, anything
Replace mentions of SSH-2 I-Ds with references to the corresponding RFCs. [originally from svn r7759]
2007-10-04 01:21:18 +04:00
* else is assumed to be RFC-compliant.
Work around DSA formatting bug in commercial-SSH 2.0.13 [originally from svn r665]
2000-10-03 13:05:56 +04:00
*/
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
if (sig.len != 40) { /* bug not present; read admin fields */
ptrlen type = get_string(src);
sig = get_string(src);
if (get_err(src) || !ptrlen_eq_string(type, "ssh-dss") ||
sig.len != 40)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
return false;
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
}
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
/* Now we're sitting on a 40-byte string for sure. */
r = bignum_from_bytes(sig.ptr, 20);
s = bignum_from_bytes((const char *)sig.ptr + 20, 20);
Another couple of memory leaks. [originally from svn r9988]
2013-08-04 23:33:57 +04:00
if (!r || !s) {
if (r)
freebn(r);
if (s)
freebn(s);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
return false;
Another couple of memory leaks. [originally from svn r9988]
2013-08-04 23:33:57 +04:00
}
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
Avoid trying to take the modular inverse of zero in response to a sufficiently silly DSA signature. [originally from svn r9989]
2013-08-04 23:34:00 +04:00
if (!bignum_cmp(s, Zero)) {
freebn(r);
freebn(s);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
return false;
Avoid trying to take the modular inverse of zero in response to a sufficiently silly DSA signature. [originally from svn r9989]
2013-08-04 23:34:00 +04:00
}
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
/*
* Step 1. w <- s^-1 mod q.
*/
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
w = modinv(s, dss->q);
Make modinv able to return NULL if its inputs are not coprime, and check for that return value everywhere it is used. [originally from svn r9990]
2013-08-04 23:34:07 +04:00
if (!w) {
freebn(r);
freebn(s);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
return false;
Make modinv able to return NULL if its inputs are not coprime, and check for that return value everywhere it is used. [originally from svn r9990]
2013-08-04 23:34:07 +04:00
}
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
/*
* Step 2. u1 <- SHA(message) * w mod q.
*/
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
SHA_Simple(data.ptr, data.len, hash);
sha = bignum_from_bytes(hash, 20);
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
u1 = modmul(sha, w, dss->q);
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
/*
* Step 3. u2 <- r * w mod q.
*/
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
u2 = modmul(r, w, dss->q);
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
/*
* Step 4. v <- (g^u1 * y^u2 mod p) mod q.
*/
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
gu1p = modpow(dss->g, u1, dss->p);
yu2p = modpow(dss->y, u2, dss->p);
gu1yu2p = modmul(gu1p, yu2p, dss->p);
v = modmul(gu1yu2p, One, dss->q);
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
/*
* Step 5. v should now be equal to r.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
toret = !bignum_cmp(v, r);
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
freebn(w);
freebn(sha);
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04:00
freebn(u1);
freebn(u2);
Make the frankly ridiculous prototypes for modpow() and modmul() more sane [originally from svn r752]
2000-10-23 20:11:31 +04:00
freebn(gu1p);
freebn(yu2p);
freebn(gu1yu2p);
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
freebn(v);
freebn(r);
freebn(s);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
return toret;
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
}
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
static void dss_public_blob(ssh_key *key, BinarySink *bs)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct dss_key *dss = container_of(key, struct dss_key, sshk);
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 12:59:39 +03:00
put_stringz(bs, "ssh-dss");
put_mp_ssh2(bs, dss->p);
put_mp_ssh2(bs, dss->q);
put_mp_ssh2(bs, dss->g);
put_mp_ssh2(bs, dss->y);
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
}
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
static void dss_private_blob(ssh_key *key, BinarySink *bs)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct dss_key *dss = container_of(key, struct dss_key, sshk);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 12:59:39 +03:00
put_mp_ssh2(bs, dss->x);
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
}
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
static ssh_key *dss_new_priv(const ssh_keyalg *self, ptrlen pub, ptrlen priv)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
BinarySource src[1];
Move null pointer checks to before FROMFIELD. This fixes an oversight in commit 0fc2d3b45: if a key creation function returns a null 'ssh_key *', then adjusting the pointer's address using FROMFIELD is a mistake, both in technical C terms (undefined behaviour) and practically speaking because it will foil the subsequent check against NULL. Instead, if we're going to check a pointer against NULL, we must do it _before_ applying this kind of address-adjusting type conversion.
2018-05-31 20:32:09 +03:00
ssh_key *sshk;
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
struct dss_key *dss;
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
ptrlen hash;
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
SHA_State s;
unsigned char digest[20];
Bignum ytest;
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
sshk = dss_new_pub(self, pub);
Move null pointer checks to before FROMFIELD. This fixes an oversight in commit 0fc2d3b45: if a key creation function returns a null 'ssh_key *', then adjusting the pointer's address using FROMFIELD is a mistake, both in technical C terms (undefined behaviour) and practically speaking because it will foil the subsequent check against NULL. Instead, if we're going to check a pointer against NULL, we must do it _before_ applying this kind of address-adjusting type conversion.
2018-05-31 20:32:09 +03:00
if (!sshk)
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
return NULL;
Move null pointer checks to before FROMFIELD. This fixes an oversight in commit 0fc2d3b45: if a key creation function returns a null 'ssh_key *', then adjusting the pointer's address using FROMFIELD is a mistake, both in technical C terms (undefined behaviour) and practically speaking because it will foil the subsequent check against NULL. Instead, if we're going to check a pointer against NULL, we must do it _before_ applying this kind of address-adjusting type conversion.
2018-05-31 20:32:09 +03:00
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
dss = container_of(sshk, struct dss_key, sshk);
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
BinarySource_BARE_INIT(src, priv.ptr, priv.len);
dss->x = get_mp_ssh2(src);
if (get_err(src)) {
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
dss_freekey(&dss->sshk);
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
return NULL;
}
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
/*
INCOMPATIBLE CHANGE to the SSH2 private key file format. There is now a passphrase-keyed MAC covering _all_ important data in the file, including the public blob and the key comment. Should conclusively scupper any attacks based on nobbling the key file in an attempt to sucker the machine that decrypts it. MACing the comment field also protects against a key-substitution attack (if someone's worked out a way past our DSA protections and can extract the private key from a signature, swapping key files and substituting comments might just enable them to get the signature they need to do this. Paranoid, but might as well). [originally from svn r1413]
2001-11-25 17:31:46 +03:00
* Check the obsolete hash in the old DSS key format.
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
*/
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
hash = get_string(src);
if (hash.len == 20) {
INCOMPATIBLE CHANGE to the SSH2 private key file format. There is now a passphrase-keyed MAC covering _all_ important data in the file, including the public blob and the key comment. Should conclusively scupper any attacks based on nobbling the key file in an attempt to sucker the machine that decrypts it. MACing the comment field also protects against a key-substitution attack (if someone's worked out a way past our DSA protections and can extract the private key from a signature, swapping key files and substituting comments might just enable them to get the signature they need to do this. Paranoid, but might as well). [originally from svn r1413]
2001-11-25 17:31:46 +03:00
SHA_Init(&s);
Simplify hashing operations in sshrsa.c and sshdss.c. We can now simply call the centralised functions to put uint32s and mpints into hash states, so there's no need to have duplicate local copies doing the same things less type-generically.
2018-05-24 11:42:02 +03:00
put_mp_ssh2(&s, dss->p);
put_mp_ssh2(&s, dss->q);
put_mp_ssh2(&s, dss->g);
INCOMPATIBLE CHANGE to the SSH2 private key file format. There is now a passphrase-keyed MAC covering _all_ important data in the file, including the public blob and the key comment. Should conclusively scupper any attacks based on nobbling the key file in an attempt to sucker the machine that decrypts it. MACing the comment field also protects against a key-substitution attack (if someone's worked out a way past our DSA protections and can extract the private key from a signature, swapping key files and substituting comments might just enable them to get the signature they need to do this. Paranoid, but might as well). [originally from svn r1413]
2001-11-25 17:31:46 +03:00
SHA_Final(&s, digest);
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
if (0 != memcmp(hash.ptr, digest, 20)) {
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
dss_freekey(&dss->sshk);
INCOMPATIBLE CHANGE to the SSH2 private key file format. There is now a passphrase-keyed MAC covering _all_ important data in the file, including the public blob and the key comment. Should conclusively scupper any attacks based on nobbling the key file in an attempt to sucker the machine that decrypts it. MACing the comment field also protects against a key-substitution attack (if someone's worked out a way past our DSA protections and can extract the private key from a signature, swapping key files and substituting comments might just enable them to get the signature they need to do this. Paranoid, but might as well). [originally from svn r1413]
2001-11-25 17:31:46 +03:00
return NULL;
}
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
}
/*
* Now ensure g^x mod p really is y.
*/
ytest = modpow(dss->g, dss->x, dss->p);
if (0 != bignum_cmp(ytest, dss->y)) {
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
dss_freekey(&dss->sshk);
Fix another giant batch of resource leaks. (Mostly memory, but there's one missing fclose too.) [originally from svn r9919]
2013-07-14 14:46:07 +04:00
freebn(ytest);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
return NULL;
}
freebn(ytest);
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
return &dss->sshk;
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
}
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
static ssh_key *dss_new_priv_openssh(const ssh_keyalg *self,
BinarySource *src)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
struct dss_key *dss;
Introduced wrapper macros snew(), snewn() and sresize() for the malloc functions, which automatically cast to the same type they're allocating the size of. Should prevent any future errors involving mallocing the size of the wrong structure type, and will also make life easier if we ever need to turn the PuTTY core code from real C into C++-friendly C. I haven't touched the Mac frontend in this checkin because I couldn't compile or test it. [originally from svn r3014]
2003-03-29 19:14:26 +03:00
dss = snew(struct dss_key);
Make ssh_key and ssh{2,1}_cipher into structs. In commit 884a7df94 I claimed that all my trait-like vtable systems now had the generic object type being a struct rather than a bare vtable pointer (e.g. instead of 'Socket' being a typedef for a pointer to a const Socket_vtable, it's a typedef for a struct _containing_ a vtable pointer). In fact, I missed a few. This commit converts ssh_key, ssh2_cipher and ssh1_cipher into the same form as the rest.
2018-11-27 00:02:28 +03:00
dss->sshk.vt = &ssh_dss;
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
dss->p = get_mp_ssh2(src);
dss->q = get_mp_ssh2(src);
dss->g = get_mp_ssh2(src);
dss->y = get_mp_ssh2(src);
dss->x = get_mp_ssh2(src);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
if (get_err(src) ||
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
!bignum_cmp(dss->q, Zero) || !bignum_cmp(dss->p, Zero)) {
/* Invalid key. */
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
dss_freekey(&dss->sshk);
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
return NULL;
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
}
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
return &dss->sshk;
Add support for the OpenSSH SSH2 agent protocol. [originally from svn r976]
2001-03-03 18:31:35 +03:00
}
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
static void dss_openssh_blob(ssh_key *key, BinarySink *bs)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct dss_key *dss = container_of(key, struct dss_key, sshk);
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 12:59:39 +03:00
put_mp_ssh2(bs, dss->p);
put_mp_ssh2(bs, dss->q);
put_mp_ssh2(bs, dss->g);
put_mp_ssh2(bs, dss->y);
put_mp_ssh2(bs, dss->x);
Pageant interface changes. You can now do `pageant -c command' to spawn another command after starting Pageant. Also, if Pageant is already running, `pageant keyfile' and `pageant -c command' will do the Right Thing, that is, add the key to the _first_ Pageant and/or run a command and then exit. The only time you now get the `Pageant is already running' error is if you try to start the second copy with no arguments. NB the affected files in this checkin are rather wide-ranging because I renamed the not really SSH1-specific `ssh1_bignum_bitcount' function to just `bignum_bitcount'. [originally from svn r1044]
2001-04-16 15:16:58 +04:00
}
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
static int dss_pubkey_bits(const ssh_keyalg *self, ptrlen pub)
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 22:15:32 +03:00
{
Move null pointer checks to before FROMFIELD. This fixes an oversight in commit 0fc2d3b45: if a key creation function returns a null 'ssh_key *', then adjusting the pointer's address using FROMFIELD is a mistake, both in technical C terms (undefined behaviour) and practically speaking because it will foil the subsequent check against NULL. Instead, if we're going to check a pointer against NULL, we must do it _before_ applying this kind of address-adjusting type conversion.
2018-05-31 20:32:09 +03:00
ssh_key *sshk;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 22:15:32 +03:00
struct dss_key *dss;
int ret;
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
sshk = dss_new_pub(self, pub);
Move null pointer checks to before FROMFIELD. This fixes an oversight in commit 0fc2d3b45: if a key creation function returns a null 'ssh_key *', then adjusting the pointer's address using FROMFIELD is a mistake, both in technical C terms (undefined behaviour) and practically speaking because it will foil the subsequent check against NULL. Instead, if we're going to check a pointer against NULL, we must do it _before_ applying this kind of address-adjusting type conversion.
2018-05-31 20:32:09 +03:00
if (!sshk)
Validate newly created DSA keys more carefully. Don't want a structure half-filled with null pointers. [originally from svn r9986]
2013-08-04 23:33:49 +04:00
return -1;
Move null pointer checks to before FROMFIELD. This fixes an oversight in commit 0fc2d3b45: if a key creation function returns a null 'ssh_key *', then adjusting the pointer's address using FROMFIELD is a mistake, both in technical C terms (undefined behaviour) and practically speaking because it will foil the subsequent check against NULL. Instead, if we're going to check a pointer against NULL, we must do it _before_ applying this kind of address-adjusting type conversion.
2018-05-31 20:32:09 +03:00
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
dss = container_of(sshk, struct dss_key, sshk);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 22:15:32 +03:00
ret = bignum_bitcount(dss->p);
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
dss_freekey(&dss->sshk);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 22:15:32 +03:00
return ret;
}
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
Bignum *dss_gen_k(const char *id_string, Bignum modulus, Bignum private_key,
unsigned char *digest, int digest_len)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
{
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
/*
* The basic DSS signing algorithm is:
*
* - invent a random k between 1 and q-1 (exclusive).
* - Compute r = (g^k mod p) mod q.
* - Compute s = k^-1 * (hash + x*r) mod q.
*
* This has the dangerous properties that:
*
* - if an attacker in possession of the public key _and_ the
* signature (for example, the host you just authenticated
* to) can guess your k, he can reverse the computation of s
* and work out x = r^-1 * (s*k - hash) mod q. That is, he
* can deduce the private half of your key, and masquerade
* as you for as long as the key is still valid.
*
* - since r is a function purely of k and the public key, if
* the attacker only has a _range of possibilities_ for k
* it's easy for him to work through them all and check each
* one against r; he'll never be unsure of whether he's got
* the right one.
*
* - if you ever sign two different hashes with the same k, it
* will be immediately obvious because the two signatures
* will have the same r, and moreover an attacker in
* possession of both signatures (and the public key of
* course) can compute k = (hash1-hash2) * (s1-s2)^-1 mod q,
* and from there deduce x as before.
*
* - the Bleichenbacher attack on DSA makes use of methods of
* generating k which are significantly non-uniformly
* distributed; in particular, generating a 160-bit random
* number and reducing it mod q is right out.
*
* For this reason we must be pretty careful about how we
* generate our k. Since this code runs on Windows, with no
* particularly good system entropy sources, we can't trust our
* RNG itself to produce properly unpredictable data. Hence, we
* use a totally different scheme instead.
*
* What we do is to take a SHA-512 (_big_) hash of the private
* key x, and then feed this into another SHA-512 hash that
* also includes the message hash being signed. That is:
*
* proto_k = SHA512 ( SHA512(x) || SHA160(message) )
*
* This number is 512 bits long, so reducing it mod q won't be
* noticeably non-uniform. So
*
* k = proto_k mod q
*
* This has the interesting property that it's _deterministic_:
* signing the same hash twice with the same key yields the
* same signature.
*
Add extra explanatory comment about the DSA k generation. [originally from svn r1285]
2001-09-23 01:00:16 +04:00
* Despite this determinism, it's still not predictable to an
* attacker, because in order to repeat the SHA-512
* construction that created it, the attacker would have to
* know the private key value x - and by assumption he doesn't,
* because if he knew that he wouldn't be attacking k!
*
* (This trick doesn't, _per se_, protect against reuse of k.
* Reuse of k is left to chance; all it does is prevent
* _excessively high_ chances of reuse of k due to entropy
* problems.)
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
*
* Thanks to Colin Plumb for the general idea of using x to
* ensure k is hard to guess, and to the Cambridge University
* Computer Security Group for helping to argue out all the
* fine details.
*/
SHA512_State ss;
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
unsigned char digest512[64];
Bignum proto_k, k;
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
/*
* Hash some identifying text plus x.
*/
SHA512_Init(&ss);
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 12:03:36 +03:00
put_asciz(&ss, id_string);
Simplify hashing operations in sshrsa.c and sshdss.c. We can now simply call the centralised functions to put uint32s and mpints into hash states, so there's no need to have duplicate local copies doing the same things less type-generically.
2018-05-24 11:42:02 +03:00
put_mp_ssh2(&ss, private_key);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
SHA512_Final(&ss, digest512);
/*
* Now hash that digest plus the message hash.
*/
SHA512_Init(&ss);
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 12:03:36 +03:00
put_data(&ss, digest512, sizeof(digest512));
put_data(&ss, digest, digest_len);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
Make modinv able to return NULL if its inputs are not coprime, and check for that return value everywhere it is used. [originally from svn r9990]
2013-08-04 23:34:07 +04:00
while (1) {
SHA512_State ss2 = ss; /* structure copy */
SHA512_Final(&ss2, digest512);
smemclr(&ss2, sizeof(ss2));
/*
* Now convert the result into a bignum, and reduce it mod q.
*/
proto_k = bignum_from_bytes(digest512, 64);
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
k = bigmod(proto_k, modulus);
Make modinv able to return NULL if its inputs are not coprime, and check for that return value everywhere it is used. [originally from svn r9990]
2013-08-04 23:34:07 +04:00
freebn(proto_k);
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
if (bignum_cmp(k, One) != 0 && bignum_cmp(k, Zero) != 0) {
smemclr(&ss, sizeof(ss));
smemclr(digest512, sizeof(digest512));
return k;
Make modinv able to return NULL if its inputs are not coprime, and check for that return value everywhere it is used. [originally from svn r9990]
2013-08-04 23:34:07 +04:00
}
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
/* Very unlikely we get here, but if so, k was unsuitable. */
freebn(k);
/* Perturb the hash to think of a different k. */
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 12:03:36 +03:00
put_byte(&ss, 'x');
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
/* Go round and try again. */
Make modinv able to return NULL if its inputs are not coprime, and check for that return value everywhere it is used. [originally from svn r9990]
2013-08-04 23:34:07 +04:00
}
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
}
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
static void dss_sign(ssh_key *key, const void *data, int datalen,
Pass flags from agent sign request to ssh_key_sign. Now each public-key algorithm gets to indicate what flags it supports, and the ones it specifies support for may turn up in a call to its sign() method. We still don't actually support any flags yet, though.
2018-11-19 23:24:37 +03:00
unsigned flags, BinarySink *bs)
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-06 01:49:08 +03:00
struct dss_key *dss = container_of(key, struct dss_key, sshk);
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
Bignum k, gkp, hash, kinv, hxr, r, s;
unsigned char digest[20];
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 12:59:39 +03:00
int i;
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
SHA_Simple(data, datalen, digest);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
k = dss_gen_k("DSA deterministic k generator", dss->q, dss->x,
digest, sizeof(digest));
kinv = modinv(k, dss->q); /* k^-1 mod q */
assert(kinv);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
/*
* Now we have k, so just go ahead and compute the signature.
*/
gkp = modpow(dss->g, k, dss->p); /* g^k mod p */
r = bigmod(gkp, dss->q); /* r = (g^k mod p) mod q */
freebn(gkp);
hash = bignum_from_bytes(digest, 20);
hxr = bigmuladd(dss->x, r, hash); /* hash + x*r */
s = modmul(kinv, hxr, dss->q); /* s = k^-1 * (hash + x*r) mod q */
freebn(hxr);
freebn(kinv);
Another couple of memory leaks. [originally from svn r9988]
2013-08-04 23:33:57 +04:00
freebn(k);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
freebn(hash);
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 12:59:39 +03:00
put_stringz(bs, "ssh-dss");
put_uint32(bs, 40);
for (i = 0; i < 20; i++)
put_byte(bs, bignum_byte(r, 19 - i));
for (i = 0; i < 20; i++)
put_byte(bs, bignum_byte(s, 19 - i));
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
freebn(r);
freebn(s);
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
}
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
const ssh_keyalg ssh_dss = {
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
dss_new_pub,
dss_new_priv,
dss_new_priv_openssh,
Improve SSH2 host key abstraction into a generic `signing key' abstraction, so as to be able to re-use the same abstraction for user authentication keys and probably in the SSH2 agent (when that happens) as well. [originally from svn r815]
2000-12-02 15:48:15 +03:00
dss_freekey,
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
dss_sign,
dss_verify,
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
dss_public_blob,
dss_private_blob,
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
dss_openssh_blob,
dss_cache_str,
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 22:15:32 +03:00
dss_pubkey_bits,
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
Rationalised host key storage. Also started code reorg: persistent-state routines have been moved out into a replaceable module winstore.c. [originally from svn r639]
2000-09-27 19:21:04 +04:00
"ssh-dss",
Provide an 'extra' pointer in ssh_signkey and ssh_kex. This gives families of public key and kex functions (by which I mean those sharing a set of methods) a place to store parameters that allow the methods to vary depending on which exact algorithm is in use. The ssh_kex structure already had a set of parameters specific to Diffie-Hellman key exchange; I've moved those into sshdh.c and made them part of the 'extra' structure for that family only, so that unrelated kex methods don't have to faff about saying NULL,NULL,0,0. (This required me to write an extra accessor function for ssh.c to ask whether a DH method was group-exchange style or fixed-group style, but that doesn't seem too silly.)
2015-05-15 12:12:08 +03:00
"dss",
NULL,
Pass flags from agent sign request to ssh_key_sign. Now each public-key algorithm gets to indicate what flags it supports, and the ones it specifies support for may turn up in a call to its sign() method. We still don't actually support any flags yet, though.
2018-11-19 23:24:37 +03:00
0, /* no supported flags */
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
};