nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
f58ddf26fe
putty-source/test/testcrypt-func.h

623 lines
30 KiB
C
Raw Normal View History

Rewrite the testcrypt.c macro system. Yesterday's commit 52ee636b092c199 which further extended the huge pile of arity-specific annoying wrapper macros pushed me over the edge and inspired me to give some harder thought to finding a way to handle all arities at once. And this time I found one! The new technique changes the syntax of the function specifications in testcrypt.h. In particular, they now have to specify a _name_ for each parameter as well as a type, because the macros generating the C marshalling wrappers will need a structure field for each parameter and cpp isn't flexible enough to generate names for those fields automatically. Rather than tediously name them arg1, arg2 etc, I've reused the names of the parameters from the prototypes or definitions of the underlying real functions (via a one-off auto-extraction process starting from the output of 'clang -Xclang -dump-ast' plus some manual polishing), which means testcrypt.h is now a bit more self-documenting. The testcrypt.py end of the mechanism is rewritten to eat the new format. Since it's got more complicated syntax and nested parens and things, I've written something a bit like a separated lexer/parser system in place of the previous crude regex matcher, which should enforce that the whole header file really does conform to the restricted syntax it has to fit into. The new system uses a lot less code in testcrypt.c, but I've made up for that by also writing a long comment explaining how it works, which was another thing the previous system lacked! Similarly, the new testcrypt.h has some long-overdue instructions at the top.
2021-11-21 10:27:30 +00:00
/*
* List of functions exported by the 'testcrypt' system to provide a
* Python API for running unit tests and auxiliary programs.
*
* Each function definition in this file has the form
*
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
* FUNC(return-type, function-name, ...)
Rewrite the testcrypt.c macro system. Yesterday's commit 52ee636b092c199 which further extended the huge pile of arity-specific annoying wrapper macros pushed me over the edge and inspired me to give some harder thought to finding a way to handle all arities at once. And this time I found one! The new technique changes the syntax of the function specifications in testcrypt.h. In particular, they now have to specify a _name_ for each parameter as well as a type, because the macros generating the C marshalling wrappers will need a structure field for each parameter and cpp isn't flexible enough to generate names for those fields automatically. Rather than tediously name them arg1, arg2 etc, I've reused the names of the parameters from the prototypes or definitions of the underlying real functions (via a one-off auto-extraction process starting from the output of 'clang -Xclang -dump-ast' plus some manual polishing), which means testcrypt.h is now a bit more self-documenting. The testcrypt.py end of the mechanism is rewritten to eat the new format. Since it's got more complicated syntax and nested parens and things, I've written something a bit like a separated lexer/parser system in place of the previous crude regex matcher, which should enforce that the whole header file really does conform to the restricted syntax it has to fit into. The new system uses a lot less code in testcrypt.c, but I've made up for that by also writing a long comment explaining how it works, which was another thing the previous system lacked! Similarly, the new testcrypt.h has some long-overdue instructions at the top.
2021-11-21 10:27:30 +00:00
*
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
* where '...' in turn a variadic list of argument specifications of
* the form
Rewrite the testcrypt.c macro system. Yesterday's commit 52ee636b092c199 which further extended the huge pile of arity-specific annoying wrapper macros pushed me over the edge and inspired me to give some harder thought to finding a way to handle all arities at once. And this time I found one! The new technique changes the syntax of the function specifications in testcrypt.h. In particular, they now have to specify a _name_ for each parameter as well as a type, because the macros generating the C marshalling wrappers will need a structure field for each parameter and cpp isn't flexible enough to generate names for those fields automatically. Rather than tediously name them arg1, arg2 etc, I've reused the names of the parameters from the prototypes or definitions of the underlying real functions (via a one-off auto-extraction process starting from the output of 'clang -Xclang -dump-ast' plus some manual polishing), which means testcrypt.h is now a bit more self-documenting. The testcrypt.py end of the mechanism is rewritten to eat the new format. Since it's got more complicated syntax and nested parens and things, I've written something a bit like a separated lexer/parser system in place of the previous crude regex matcher, which should enforce that the whole header file really does conform to the restricted syntax it has to fit into. The new system uses a lot less code in testcrypt.c, but I've made up for that by also writing a long comment explaining how it works, which was another thing the previous system lacked! Similarly, the new testcrypt.h has some long-overdue instructions at the top.
2021-11-21 10:27:30 +00:00
*
* ARG(argument-type, argument-name)
*
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
* An empty argument list must be marked by including a
* pseudo-argument VOID:
*
* FUNC(return-type, function-name, VOID)
*
Rewrite the testcrypt.c macro system. Yesterday's commit 52ee636b092c199 which further extended the huge pile of arity-specific annoying wrapper macros pushed me over the edge and inspired me to give some harder thought to finding a way to handle all arities at once. And this time I found one! The new technique changes the syntax of the function specifications in testcrypt.h. In particular, they now have to specify a _name_ for each parameter as well as a type, because the macros generating the C marshalling wrappers will need a structure field for each parameter and cpp isn't flexible enough to generate names for those fields automatically. Rather than tediously name them arg1, arg2 etc, I've reused the names of the parameters from the prototypes or definitions of the underlying real functions (via a one-off auto-extraction process starting from the output of 'clang -Xclang -dump-ast' plus some manual polishing), which means testcrypt.h is now a bit more self-documenting. The testcrypt.py end of the mechanism is rewritten to eat the new format. Since it's got more complicated syntax and nested parens and things, I've written something a bit like a separated lexer/parser system in place of the previous crude regex matcher, which should enforce that the whole header file really does conform to the restricted syntax it has to fit into. The new system uses a lot less code in testcrypt.c, but I've made up for that by also writing a long comment explaining how it works, which was another thing the previous system lacked! Similarly, the new testcrypt.h has some long-overdue instructions at the top.
2021-11-21 10:27:30 +00:00
* Type names are always single identifiers, and they have some
* standard prefixes:
*
* 'val_' means that the type refers to something dynamically
* allocated, so that it has a persistent identity, needs to be freed
* when finished with (though this is done automatically by the
* testcrypt.py system via Python's reference counting), and may also
* be mutable. The argument type in C will be a pointer; in Python the
* corresponding argument will be an instance of a 'Value' object
* defined in testcrypt.py.
*
* 'opt_val_' is a modification of 'val_' to indicate that the pointer
* may be NULL. In Python this is translated by accepting (or
* returning) None as an alternative to a Value.
*
* 'out_' on an argument type indicates an additional output
* parameter. The argument type in C has an extra layer of
* indirection, e.g. an 'out_val_mpint' is an 'mpint **' instead of an
* 'mpint *', identifying a pointer variable where the returned
* pointer value will be written. In the Python API, these arguments
* do not appear in the argument list of the Python function; instead
* they cause the return value to become a tuple, with additional
* types appended. For example, a declaration like
*
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
* FUNC(val_foo, example, ARG(out_val_bar, bar), ARG(val_baz, baz))
Rewrite the testcrypt.c macro system. Yesterday's commit 52ee636b092c199 which further extended the huge pile of arity-specific annoying wrapper macros pushed me over the edge and inspired me to give some harder thought to finding a way to handle all arities at once. And this time I found one! The new technique changes the syntax of the function specifications in testcrypt.h. In particular, they now have to specify a _name_ for each parameter as well as a type, because the macros generating the C marshalling wrappers will need a structure field for each parameter and cpp isn't flexible enough to generate names for those fields automatically. Rather than tediously name them arg1, arg2 etc, I've reused the names of the parameters from the prototypes or definitions of the underlying real functions (via a one-off auto-extraction process starting from the output of 'clang -Xclang -dump-ast' plus some manual polishing), which means testcrypt.h is now a bit more self-documenting. The testcrypt.py end of the mechanism is rewritten to eat the new format. Since it's got more complicated syntax and nested parens and things, I've written something a bit like a separated lexer/parser system in place of the previous crude regex matcher, which should enforce that the whole header file really does conform to the restricted syntax it has to fit into. The new system uses a lot less code in testcrypt.c, but I've made up for that by also writing a long comment explaining how it works, which was another thing the previous system lacked! Similarly, the new testcrypt.h has some long-overdue instructions at the top.
2021-11-21 10:27:30 +00:00
*
* would identify a function in C with the following prototype, which
* returns a 'foo *' directly and a 'bar *' by writing it through the
* provided 'bar **' pointer argument:
*
* foo *example(bar **extra_output, baz *input);
*
* and in Python this would become a function taking one argument of
* type 'baz' and returning a tuple of the form (foo, bar).
*
* 'out_' and 'opt_' can go together, if a function returns a second
* output value but it may in some cases be NULL.
*
* 'consumed_' on an argument type indicates that the C function
* receiving that argument frees it as a side effect.
*
* Any argument type which does not start 'val_' is plain old data
* with no dynamic allocation requirements. Ordinary C integers are
* sometimes handled this way (e.g. 'uint'). Other plain-data types
* are represented in Python as a string that must be one of a
* recognised set of keywords; in C these variously translate into
* enumeration types (e.g. argon2flavour, rsaorder) or pointers to
* const vtables of one kind or another (e.g. keyalg, hashalg,
* primegenpolicy).
testcrypt.h: invent FUNC_WRAPPED. FUNC_WRAPPED is an alternative keyword to FUNC which you can use to introduce a function specification in testcrypt.h, indicating that the function is _not_ the one of the same name used in the main PuTTY code, but instead a wrapper on it in testcrypt.c whose API was reworked to be more friendly to translation into Python. There are a lot of those wrappers already, and previously they passed without comment in testcrypt.h, and were put into service by #defining over the top of each name before expanding the marshalling functions. Now, all those #defines are gone, because the use of FUNC_WRAPPED in testcrypt.h is enough to clue in the marshalling wrapper to be generated with a call to foo_wrapper() instead of foo(). Mostly the purpose of this is to make testcrypt.h a bit more self-documenting: if you see FUNC_WRAPPED, you know not to be confused by the Python and C function definitions totally failing to match.
2021-11-21 13:03:34 +00:00
*
* If a function definition begins with FUNC_WRAPPED rather than FUNC,
* it means that the underlying C function has a suffix "_wrapper",
* e.g. ssh_cipher_setiv_wrapper(). Those wrappers are defined in
* testcrypt.c itself, and change the API or semantics in a way that
* makes the function more Python-friendly.
Rewrite the testcrypt.c macro system. Yesterday's commit 52ee636b092c199 which further extended the huge pile of arity-specific annoying wrapper macros pushed me over the edge and inspired me to give some harder thought to finding a way to handle all arities at once. And this time I found one! The new technique changes the syntax of the function specifications in testcrypt.h. In particular, they now have to specify a _name_ for each parameter as well as a type, because the macros generating the C marshalling wrappers will need a structure field for each parameter and cpp isn't flexible enough to generate names for those fields automatically. Rather than tediously name them arg1, arg2 etc, I've reused the names of the parameters from the prototypes or definitions of the underlying real functions (via a one-off auto-extraction process starting from the output of 'clang -Xclang -dump-ast' plus some manual polishing), which means testcrypt.h is now a bit more self-documenting. The testcrypt.py end of the mechanism is rewritten to eat the new format. Since it's got more complicated syntax and nested parens and things, I've written something a bit like a separated lexer/parser system in place of the previous crude regex matcher, which should enforce that the whole header file really does conform to the restricted syntax it has to fit into. The new system uses a lot less code in testcrypt.c, but I've made up for that by also writing a long comment explaining how it works, which was another thing the previous system lacked! Similarly, the new testcrypt.h has some long-overdue instructions at the top.
2021-11-21 10:27:30 +00:00
*/
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* mpint.h functions.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_mpint, mp_new, ARG(uint, maxbits))
FUNC(void, mp_clear, ARG(val_mpint, x))
FUNC(val_mpint, mp_from_bytes_le, ARG(val_string_ptrlen, bytes))
FUNC(val_mpint, mp_from_bytes_be, ARG(val_string_ptrlen, bytes))
FUNC(val_mpint, mp_from_integer, ARG(uint, n))
FUNC(val_mpint, mp_from_decimal_pl, ARG(val_string_ptrlen, decimal))
FUNC(val_mpint, mp_from_decimal, ARG(val_string_asciz, decimal))
FUNC(val_mpint, mp_from_hex_pl, ARG(val_string_ptrlen, hex))
FUNC(val_mpint, mp_from_hex, ARG(val_string_asciz, hex))
FUNC(val_mpint, mp_copy, ARG(val_mpint, x))
FUNC(val_mpint, mp_power_2, ARG(uint, power))
FUNC(uint, mp_get_byte, ARG(val_mpint, x), ARG(uint, byte))
FUNC(uint, mp_get_bit, ARG(val_mpint, x), ARG(uint, bit))
FUNC(void, mp_set_bit, ARG(val_mpint, x), ARG(uint, bit), ARG(uint, val))
FUNC(uint, mp_max_bytes, ARG(val_mpint, x))
FUNC(uint, mp_max_bits, ARG(val_mpint, x))
FUNC(uint, mp_get_nbits, ARG(val_mpint, x))
FUNC(val_string_asciz, mp_get_decimal, ARG(val_mpint, x))
FUNC(val_string_asciz, mp_get_hex, ARG(val_mpint, x))
FUNC(val_string_asciz, mp_get_hex_uppercase, ARG(val_mpint, x))
FUNC(uint, mp_cmp_hs, ARG(val_mpint, a), ARG(val_mpint, b))
FUNC(uint, mp_cmp_eq, ARG(val_mpint, a), ARG(val_mpint, b))
FUNC(uint, mp_hs_integer, ARG(val_mpint, x), ARG(uint, n))
FUNC(uint, mp_eq_integer, ARG(val_mpint, x), ARG(uint, n))
FUNC(void, mp_min_into, ARG(val_mpint, dest), ARG(val_mpint, x),
ARG(val_mpint, y))
FUNC(void, mp_max_into, ARG(val_mpint, dest), ARG(val_mpint, x),
ARG(val_mpint, y))
FUNC(val_mpint, mp_min, ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(val_mpint, mp_max, ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(void, mp_copy_into, ARG(val_mpint, dest), ARG(val_mpint, src))
FUNC(void, mp_select_into, ARG(val_mpint, dest), ARG(val_mpint, src0),
ARG(val_mpint, src1), ARG(uint, choose_src1))
FUNC(void, mp_add_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(void, mp_sub_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(void, mp_mul_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(val_mpint, mp_add, ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(val_mpint, mp_sub, ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(val_mpint, mp_mul, ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(void, mp_and_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(void, mp_or_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(void, mp_xor_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(void, mp_bic_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(void, mp_copy_integer_into, ARG(val_mpint, dest), ARG(uint, n))
FUNC(void, mp_add_integer_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(uint, n))
FUNC(void, mp_sub_integer_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(uint, n))
FUNC(void, mp_mul_integer_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(uint, n))
FUNC(void, mp_cond_add_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b), ARG(uint, yes))
FUNC(void, mp_cond_sub_into, ARG(val_mpint, dest), ARG(val_mpint, a),
ARG(val_mpint, b), ARG(uint, yes))
FUNC(void, mp_cond_swap, ARG(val_mpint, x0), ARG(val_mpint, x1),
ARG(uint, swap))
FUNC(void, mp_cond_clear, ARG(val_mpint, x), ARG(uint, clear))
FUNC(void, mp_divmod_into, ARG(val_mpint, n), ARG(val_mpint, d),
ARG(opt_val_mpint, q), ARG(opt_val_mpint, r))
FUNC(val_mpint, mp_div, ARG(val_mpint, n), ARG(val_mpint, d))
FUNC(val_mpint, mp_mod, ARG(val_mpint, x), ARG(val_mpint, modulus))
FUNC(val_mpint, mp_nthroot, ARG(val_mpint, y), ARG(uint, n),
ARG(opt_val_mpint, remainder))
FUNC(void, mp_reduce_mod_2to, ARG(val_mpint, x), ARG(uint, p))
FUNC(val_mpint, mp_invert_mod_2to, ARG(val_mpint, x), ARG(uint, p))
FUNC(val_mpint, mp_invert, ARG(val_mpint, x), ARG(val_mpint, modulus))
FUNC(void, mp_gcd_into, ARG(val_mpint, a), ARG(val_mpint, b),
ARG(opt_val_mpint, gcd_out), ARG(opt_val_mpint, A_out),
ARG(opt_val_mpint, B_out))
FUNC(val_mpint, mp_gcd, ARG(val_mpint, a), ARG(val_mpint, b))
FUNC(uint, mp_coprime, ARG(val_mpint, a), ARG(val_mpint, b))
FUNC(val_modsqrt, modsqrt_new, ARG(val_mpint, p),
ARG(val_mpint, any_nonsquare_mod_p))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/* The modsqrt functions' 'success' pointer becomes a second return value */
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_mpint, mp_modsqrt, ARG(val_modsqrt, sc), ARG(val_mpint, x),
ARG(out_uint, success))
FUNC(val_monty, monty_new, ARG(val_mpint, modulus))
FUNC_WRAPPED(val_mpint, monty_modulus, ARG(val_monty, mc))
FUNC_WRAPPED(val_mpint, monty_identity, ARG(val_monty, mc))
FUNC(void, monty_import_into, ARG(val_monty, mc), ARG(val_mpint, dest),
ARG(val_mpint, x))
FUNC(val_mpint, monty_import, ARG(val_monty, mc), ARG(val_mpint, x))
FUNC(void, monty_export_into, ARG(val_monty, mc), ARG(val_mpint, dest),
ARG(val_mpint, x))
FUNC(val_mpint, monty_export, ARG(val_monty, mc), ARG(val_mpint, x))
FUNC(void, monty_mul_into, ARG(val_monty, mc), ARG(val_mpint, dest),
ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(val_mpint, monty_add, ARG(val_monty, mc), ARG(val_mpint, x),
ARG(val_mpint, y))
FUNC(val_mpint, monty_sub, ARG(val_monty, mc), ARG(val_mpint, x),
ARG(val_mpint, y))
FUNC(val_mpint, monty_mul, ARG(val_monty, mc), ARG(val_mpint, x),
ARG(val_mpint, y))
FUNC(val_mpint, monty_pow, ARG(val_monty, mc), ARG(val_mpint, base),
ARG(val_mpint, exponent))
FUNC(val_mpint, monty_invert, ARG(val_monty, mc), ARG(val_mpint, x))
FUNC(val_mpint, monty_modsqrt, ARG(val_modsqrt, sc), ARG(val_mpint, mx),
ARG(out_uint, success))
FUNC(val_mpint, mp_modpow, ARG(val_mpint, base), ARG(val_mpint, exponent),
ARG(val_mpint, modulus))
FUNC(val_mpint, mp_modmul, ARG(val_mpint, x), ARG(val_mpint, y),
ARG(val_mpint, modulus))
FUNC(val_mpint, mp_modadd, ARG(val_mpint, x), ARG(val_mpint, y),
ARG(val_mpint, modulus))
FUNC(val_mpint, mp_modsub, ARG(val_mpint, x), ARG(val_mpint, y),
ARG(val_mpint, modulus))
FUNC(void, mp_lshift_safe_into, ARG(val_mpint, dest), ARG(val_mpint, x),
ARG(uint, shift))
FUNC(void, mp_rshift_safe_into, ARG(val_mpint, dest), ARG(val_mpint, x),
ARG(uint, shift))
FUNC(val_mpint, mp_rshift_safe, ARG(val_mpint, x), ARG(uint, shift))
FUNC(void, mp_lshift_fixed_into, ARG(val_mpint, dest), ARG(val_mpint, x),
ARG(uint, shift))
FUNC(void, mp_rshift_fixed_into, ARG(val_mpint, dest), ARG(val_mpint, x),
ARG(uint, shift))
FUNC(val_mpint, mp_rshift_fixed, ARG(val_mpint, x), ARG(uint, shift))
FUNC(val_mpint, mp_random_bits, ARG(uint, bits))
FUNC(val_mpint, mp_random_in_range, ARG(val_mpint, lo), ARG(val_mpint, hi))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* ecc.h functions.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_wcurve, ecc_weierstrass_curve, ARG(val_mpint, p), ARG(val_mpint, a),
ARG(val_mpint, b), ARG(opt_val_mpint, nonsquare_mod_p))
FUNC(val_wpoint, ecc_weierstrass_point_new_identity, ARG(val_wcurve, curve))
FUNC(val_wpoint, ecc_weierstrass_point_new, ARG(val_wcurve, curve),
ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(val_wpoint, ecc_weierstrass_point_new_from_x, ARG(val_wcurve, curve),
ARG(val_mpint, x), ARG(uint, desired_y_parity))
FUNC(val_wpoint, ecc_weierstrass_point_copy, ARG(val_wpoint, orig))
FUNC(uint, ecc_weierstrass_point_valid, ARG(val_wpoint, P))
FUNC(val_wpoint, ecc_weierstrass_add_general, ARG(val_wpoint, P),
ARG(val_wpoint, Q))
FUNC(val_wpoint, ecc_weierstrass_add, ARG(val_wpoint, P), ARG(val_wpoint, Q))
FUNC(val_wpoint, ecc_weierstrass_double, ARG(val_wpoint, P))
FUNC(val_wpoint, ecc_weierstrass_multiply, ARG(val_wpoint, B),
ARG(val_mpint, n))
FUNC(uint, ecc_weierstrass_is_identity, ARG(val_wpoint, P))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/* The output pointers in get_affine all become extra output values */
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(void, ecc_weierstrass_get_affine, ARG(val_wpoint, P),
ARG(out_val_mpint, x), ARG(out_val_mpint, y))
FUNC(val_mcurve, ecc_montgomery_curve, ARG(val_mpint, p), ARG(val_mpint, a),
ARG(val_mpint, b))
FUNC(val_mpoint, ecc_montgomery_point_new, ARG(val_mcurve, curve),
ARG(val_mpint, x))
FUNC(val_mpoint, ecc_montgomery_point_copy, ARG(val_mpoint, orig))
FUNC(val_mpoint, ecc_montgomery_diff_add, ARG(val_mpoint, P),
ARG(val_mpoint, Q), ARG(val_mpoint, PminusQ))
FUNC(val_mpoint, ecc_montgomery_double, ARG(val_mpoint, P))
FUNC(val_mpoint, ecc_montgomery_multiply, ARG(val_mpoint, B), ARG(val_mpint, n))
FUNC(void, ecc_montgomery_get_affine, ARG(val_mpoint, P), ARG(out_val_mpint, x))
FUNC(boolean, ecc_montgomery_is_identity, ARG(val_mpoint, P))
FUNC(val_ecurve, ecc_edwards_curve, ARG(val_mpint, p), ARG(val_mpint, d),
ARG(val_mpint, a), ARG(opt_val_mpint, nonsquare_mod_p))
FUNC(val_epoint, ecc_edwards_point_new, ARG(val_ecurve, curve),
ARG(val_mpint, x), ARG(val_mpint, y))
FUNC(val_epoint, ecc_edwards_point_new_from_y, ARG(val_ecurve, curve),
ARG(val_mpint, y), ARG(uint, desired_x_parity))
FUNC(val_epoint, ecc_edwards_point_copy, ARG(val_epoint, orig))
FUNC(val_epoint, ecc_edwards_add, ARG(val_epoint, P), ARG(val_epoint, Q))
FUNC(val_epoint, ecc_edwards_multiply, ARG(val_epoint, B), ARG(val_mpint, n))
FUNC(uint, ecc_edwards_eq, ARG(val_epoint, P), ARG(val_epoint, Q))
FUNC(void, ecc_edwards_get_affine, ARG(val_epoint, P), ARG(out_val_mpint, x),
ARG(out_val_mpint, y))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* The ssh_hash abstraction. Note the 'consumed', indicating that
* ssh_hash_final puts its input ssh_hash beyond use.
*
* ssh_hash_update is an invention of testcrypt, handled in the real C
* API by the hash object also functioning as a BinarySink.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(opt_val_hash, ssh_hash_new, ARG(hashalg, alg))
FUNC(void, ssh_hash_reset, ARG(val_hash, h))
FUNC(val_hash, ssh_hash_copy, ARG(val_hash, orig))
FUNC_WRAPPED(val_string, ssh_hash_digest, ARG(val_hash, h))
FUNC_WRAPPED(val_string, ssh_hash_final, ARG(consumed_val_hash, h))
FUNC(void, ssh_hash_update, ARG(val_hash, h), ARG(val_string_ptrlen, data))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(opt_val_hash, blake2b_new_general, ARG(uint, hashlen))
Add an implementation of BLAKE2b. I have no plans to use this directly, but it's a component of Argon2, which I'm about to add in the next commit.
2021-02-13 14:47:26 +00:00
Add more variants of SHAKE. This adds a ssh_hashalg defining SHAKE256 with a 32-byte output, in addition to the 114-byte output we already have. Also, it defines a new API for using SHAKE128 and SHAKE256 in the more general form of an extendable output function, which is to say that you still have to put in all the input before reading any output, but once you start reading output you can just keep going until you have enough. Both of these will be needed in an upcoming commit implementing ML-KEM.
2024-12-07 19:32:46 +00:00
FUNC(val_shakexof, shake128_xof_from_input, ARG(val_string_ptrlen, input))
FUNC(val_shakexof, shake256_xof_from_input, ARG(val_string_ptrlen, input))
FUNC_WRAPPED(val_string, shake_xof_read, ARG(val_shakexof, xof), ARG(uint, size))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
* The ssh2_mac abstraction. Note the optional ssh_cipher parameter
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
* to ssh2_mac_new. Also, again, I've invented an ssh2_mac_update so
* you can put data into the MAC.
*/
testcrypt: allow null return from ssh2_mac_new. This can now happen if, for instance, the CLMUL implementation of aesgcm is compiled in, but not available at runtime because we're on an old Intel CPU. In this situation, testcrypt would segfault when driven by test/cryptsuite.py, and test/list-accel.py would erroneously claim the CLMUL implementation was available when it wasn't.
2023-08-22 16:59:19 +00:00
FUNC(opt_val_mac, ssh2_mac_new, ARG(macalg, alg), ARG(opt_val_cipher, cipher))
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(void, ssh2_mac_setkey, ARG(val_mac, m), ARG(val_string_ptrlen, key))
FUNC(void, ssh2_mac_start, ARG(val_mac, m))
FUNC(void, ssh2_mac_update, ARG(val_mac, m), ARG(val_string_ptrlen, data))
Add 'next_message' methods to cipher and MAC vtables. This provides a convenient hook to be called between SSH messages, for the crypto components to do any per-message processing like incrementing a sequence number.
2022-08-16 17:27:06 +00:00
FUNC(void, ssh2_mac_next_message, ARG(val_mac, m))
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC_WRAPPED(val_string, ssh2_mac_genresult, ARG(val_mac, m))
FUNC(val_string_asciz_const, ssh2_mac_text_name, ARG(val_mac, m))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
FUNC(void, aesgcm_set_prefix_lengths,
ARG(val_mac, m), ARG(uint, skip), ARG(uint, aad))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* The ssh_key abstraction. All the uses of BinarySink and
* BinarySource in parameters are replaced with ordinary strings for
* the testing API: new_priv_openssh just takes a string input, and
* all the functions that output key and signature blobs do it by
* returning a string.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_key, ssh_key_new_pub, ARG(keyalg, alg), ARG(val_string_ptrlen, pub))
FUNC(opt_val_key, ssh_key_new_priv, ARG(keyalg, alg),
ARG(val_string_ptrlen, pub), ARG(val_string_ptrlen, priv))
FUNC(opt_val_key, ssh_key_new_priv_openssh, ARG(keyalg, alg),
ARG(val_string_binarysource, src))
FUNC(opt_val_string_asciz, ssh_key_invalid, ARG(val_key, key), ARG(uint, flags))
FUNC(void, ssh_key_sign, ARG(val_key, key), ARG(val_string_ptrlen, data),
ARG(uint, flags), ARG(out_val_string_binarysink, sig))
FUNC(boolean, ssh_key_verify, ARG(val_key, key), ARG(val_string_ptrlen, sig),
ARG(val_string_ptrlen, data))
FUNC(void, ssh_key_public_blob, ARG(val_key, key),
ARG(out_val_string_binarysink, blob))
FUNC(void, ssh_key_private_blob, ARG(val_key, key),
ARG(out_val_string_binarysink, blob))
FUNC(void, ssh_key_openssh_blob, ARG(val_key, key),
ARG(out_val_string_binarysink, blob))
FUNC(val_string_asciz, ssh_key_cache_str, ARG(val_key, key))
FUNC(val_keycomponents, ssh_key_components, ARG(val_key, key))
FUNC(uint, ssh_key_public_bits, ARG(keyalg, self), ARG(val_string_ptrlen, blob))
Certificate-specific ssh_key method suite. Certificate keys don't work the same as normal keys, so the rest of the code is going to have to pay attention to whether a key is a certificate, and if so, treat it differently and do cert-specific stuff to it. So here's a collection of methods for that purpose. With one exception, these methods of ssh_key are not expected to be implemented at all in non-certificate key types: they should only ever be called once you already know you're dealing with a certificate. So most of the new method pointers can be left out of the ssh_keyalg initialisers. The exception is the base_key method, which retrieves the base key of a certificate - the underlying one with the certificate stripped off. It's convenient for non-certificate keys to implement this too, and just return a pointer to themselves. So I've added an implementation in nullkey.c doing that. (The returned pointer doesn't transfer ownership; you have to use the new ssh_key_clone() if you want to keep the base key after freeing the certificate key.) The methods _only_ implemented in certificates: Query methods to return the public key of the CA (for looking up in a list of trusted ones), and to return the key id string (which exists to be written into log files). Obviously, we need a check_cert() method which will verify the CA's actual signature, not to mention checking all the other details like the principal and the validity period. And there's another fiddly method for dealing with the RSA upgrade system, called 'related_alg'. This is quite like alternate_ssh_id, in that its job is to upgrade one key algorithm to a related one with more modern RSA signing flags (or any other similar thing that might later reuse the same mechanism). But where alternate_ssh_id took the actual signing flags as an argument, this takes a pointer to the upgraded base algorithm. So it answers the question "What is to this key algorithm as you are to its base?" - if you call it on opensshcert_ssh_rsa and give it ssh_rsa_sha512, it'll give you back opensshcert_ssh_rsa_sha512. (It's awkward to have to have another of these fiddly methods, and in the longer term I'd like to try to clean up their proliferation a bit. But I even more dislike the alternative of just going through all_keyalgs looking for a cert algorithm with, say, ssh_rsa_sha512 as the base: that approach would work fine now but it would be a lurking time bomb for when all the -cert-v02@ methods appear one day. This way, each certificate type can upgrade itself to the appropriately related version. And at least related_alg is only needed if you _are_ a certificate key type - it's not adding yet another piece of null-method boilerplate to the rest.)
2022-04-20 12:06:08 +00:00
FUNC_WRAPPED(val_key, ssh_key_base_key, ARG(val_key, key))
FUNC_WRAPPED(void, ssh_key_ca_public_blob, ARG(val_key, key),
ARG(out_val_string_binarysink, blob))
FUNC_WRAPPED(void, ssh_key_cert_id_string, ARG(val_key, key),
ARG(out_val_string_binarysink, blob))
FUNC_WRAPPED(boolean, ssh_key_check_cert, ARG(val_key, key),
ARG(boolean, host), ARG(val_string_ptrlen, principal),
Permit configuring RSA signature types in certificates. As distinct from the type of signature generated by the SSH server itself from the host key, this lets you exclude (and by default does exclude) the old "ssh-rsa" SHA-1 signature type from the signature of the CA on the certificate.
2022-05-02 09:18:16 +00:00
ARG(uint, time), ARG(val_string_ptrlen, options),
ARG(out_val_string_binarysink, error))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
/*
* Accessors to retrieve the innards of a 'key_components'.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(uint, key_components_count, ARG(val_keycomponents, kc))
Run testcrypt.h through clang-format. Now that testcrypt.py parses it using a C-like lexer, we don't have the constraint any more that each function definition has to live on exactly one source line for the sake of the previous line-by-line parser. So we can put whitespace wherever we like, and reformat for legibility! I've done the initial pass of this using clang-format, which will optimise for (a) everything fitting in 80 columns, and (b) individual ARG(...) specifications generally not being broken across lines. Those seem like a good combination to me.
2021-11-21 15:01:58 +00:00
FUNC(opt_val_string_asciz_const, key_components_nth_name,
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
ARG(val_keycomponents, kc), ARG(uint, n))
Refactor the key-components mechanism a bit. Having recently pulled it out into its own file, I think it could also do with a bit of tidying. In this rework: - the substructure for a single component now has a globally visible struct tag, so you can make a variable pointing at it, saving verbiage in every piece of code looping over a key_components - the 'is_mp_int' flag has been replaced with a type enum, so that more types can be added without further upheaval - the printing loop in cmdgen.c for puttygen --dump has factored out the initial 'name=' prefix on each line so that it isn't repeated per component type - the storage format for text components is now a strbuf rather than a plain char *, which I think is generally more useful.
2022-04-18 09:10:57 +00:00
FUNC(opt_val_string, key_components_nth_str,
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
ARG(val_keycomponents, kc), ARG(uint, n))
FUNC(opt_val_mpint, key_components_nth_mp, ARG(val_keycomponents, kc),
ARG(uint, n))
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
Switch to RFC 6979 for DSA nonce generation. This fixes a vulnerability that compromises NIST P521 ECDSA keys when they are used with PuTTY's existing DSA nonce generation code. The vulnerability has been assigned the identifier CVE-2024-31497. PuTTY has been doing its DSA signing deterministically for literally as long as it's been doing it at all, because I didn't trust Windows's entropy generation. Deterministic nonce generation was introduced in commit d345ebc2a5a0b59, as part of the initial version of our DSA signing routine. At the time, there was no standard for how to do it, so we had to think up the details of our system ourselves, with some help from the Cambridge University computer security group. More than ten years later, RFC 6979 was published, recommending a similar system for general use, naturally with all the details different. We didn't switch over to doing it that way, because we had a scheme in place already, and as far as I could see, the differences were not security-critical - just the normal sort of variation you expect when any two people design a protocol component of this kind independently. As far as I know, the _structure_ of our scheme is still perfectly fine, in terms of what data gets hashed, how many times, and how the hash output is converted into a nonce. But the weak spot is the choice of hash function: inside our dsa_gen_k() function, we generate 512 bits of random data using SHA-512, and then reduce that to the output range by modular reduction, regardless of what signature algorithm we're generating a nonce for. In the original use case, this introduced a theoretical bias (the output size is an odd prime, which doesn't evenly divide the space of 2^512 possible inputs to the reduction), but the theory was that since integer DSA uses a modulus prime only 160 bits long (being based on SHA-1, at least in the form that SSH uses it), the bias would be too small to be detectable, let alone exploitable. Then we reused the same function for NIST-style ECDSA, when it arrived. This is fine for the P256 curve, and even P384. But in P521, the order of the base point is _greater_ than 2^512, so when we generate a 512-bit number and reduce it, the reduction never makes any difference, and our output nonces are all in the first 2^512 elements of the range of about 2^521. So this _does_ introduce a significant bias in the nonces, compared to the ideal of uniformly random distribution over the whole range. And it's been recently discovered that a bias of this kind is sufficient to expose private keys, given a manageably small number of signatures to work from. (Incidentally, none of this affects Ed25519. The spec for that system includes its own idea of how you should do deterministic nonce generation - completely different again, naturally - and we did it that way rather than our way, so that we could use the existing test vectors.) The simplest fix would be to patch our existing nonce generator to use a longer hash, or concatenate a couple of SHA-512 hashes, or something similar. But I think a more robust approach is to switch it out completely for what is now the standard system. The main reason why I prefer that is that the standard system comes with test vectors, which adds a lot of confidence that I haven't made some other mistake in following my own design. So here's a commit that adds an implementation of RFC 6979, and removes the old dsa_gen_k() function. Tests are added based on the RFC's appendix of test vectors (as many as are compatible with the more limited API of PuTTY's crypto code, e.g. we lack support for the NIST P192 curve, or for doing integer DSA with many different hash functions). One existing test changes its expected outputs, namely the one that has a sample key pair and signature for every key algorithm we support.
2024-04-01 08:18:34 +00:00
/*
* DSA nonce generation.
*/
FUNC(opt_val_mpint, rfc6979, ARG(hashalg, hash), ARG(val_mpint, modulus),
ARG(val_mpint, private_key), ARG(val_string_ptrlen, message))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
* The ssh_cipher abstraction. The in-place encrypt and decrypt
* functions are wrapped to replace them with versions that take one
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
* string and return a separate string.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(opt_val_cipher, ssh_cipher_new, ARG(cipheralg, alg))
FUNC_WRAPPED(void, ssh_cipher_setiv, ARG(val_cipher, c),
ARG(val_string_ptrlen, iv))
FUNC_WRAPPED(void, ssh_cipher_setkey, ARG(val_cipher, c),
ARG(val_string_ptrlen, key))
FUNC_WRAPPED(val_string, ssh_cipher_encrypt, ARG(val_cipher, c),
ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, ssh_cipher_decrypt, ARG(val_cipher, c),
ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, ssh_cipher_encrypt_length, ARG(val_cipher, c),
ARG(val_string_ptrlen, blk), ARG(uint, seq))
FUNC_WRAPPED(val_string, ssh_cipher_decrypt_length, ARG(val_cipher, c),
ARG(val_string_ptrlen, blk), ARG(uint, seq))
Add 'next_message' methods to cipher and MAC vtables. This provides a convenient hook to be called between SSH messages, for the crypto components to do any per-message processing like incrementing a sequence number.
2022-08-16 17:27:06 +00:00
FUNC(void, ssh_cipher_next_message, ARG(val_cipher, c))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* Integer Diffie-Hellman.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_dh, dh_setup_group, ARG(dh_group, group))
FUNC(val_dh, dh_setup_gex, ARG(val_mpint, p), ARG(val_mpint, g))
FUNC(uint, dh_modulus_bit_size, ARG(val_dh, ctx))
Stop using short exponents for Diffie-Hellman. I recently encountered a paper [1] which catalogues all kinds of things that can go wrong when one party in a discrete-log system invents a prime and the other party chooses an exponent. In particular, some choices of prime make it reasonable to use a short exponent to save time, but others make that strategy very bad. That paper is about the ElGamal encryption scheme used in OpenPGP, which is basically integer Diffie-Hellman with one side's key being persistent: a shared-secret integer is derived exactly as in DH, and then it's used to communicate a message integer by simply multiplying the shared secret by the message, mod p. I don't _know_ that any problem of this kind arises in the SSH usage of Diffie-Hellman: the standard integer DH groups in SSH are safe primes, and as far as I know, the usual generation of prime moduli for DH group exchange also picks safe primes. So the short exponents PuTTY has been using _should_ be OK. However, the range of imaginative other possibilities shown in that paper make me nervous, even so! So I think I'm going to retire the short exponent strategy, on general principles of overcaution. This slows down 4096-bit integer DH by about a factor of 3-4 (which would be worse if it weren't for the modpow speedup in the previous commit). I think that's OK, because, firstly, computers are a lot faster these days than when I originally chose to use short exponents, and secondly, more and more implementations are now switching to elliptic-curve DH, which is unaffected by this change (and with which we've always been using maximum-length exponents). [1] On the (in)security of ElGamal in OpenPGP. Luca De Feo, Bertram Poettering, Alessandro Sorniotti. https://eprint.iacr.org/2021/923
2021-11-28 12:10:42 +00:00
FUNC(val_mpint, dh_create_e, ARG(val_dh, ctx))
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC_WRAPPED(boolean, dh_validate_f, ARG(val_dh, ctx), ARG(val_mpint, f))
FUNC(val_mpint, dh_find_K, ARG(val_dh, ctx), ARG(val_mpint, f))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* Elliptic-curve Diffie-Hellman.
*/
Refactor ecdh_kex into an organised vtable. This is already slightly nice because it lets me separate the Weierstrass and Montgomery code more completely, without having to have a vtable tucked into dh->extra. But more to the point, it will allow completely different kex methods to fit into the same framework later. To that end, I've moved more of the descriptive message generation into the vtable, and also provided the constructor with a flag that will let it do different things in client and server. Also, following on from a previous commit, I've arranged that the new API returns arbitrary binary data for the exchange hash, rather than an mp_int. An upcoming implementation of this interface will want to return an encoded string instead of an encoded mp_int.
2022-04-14 06:04:33 +00:00
FUNC(val_ecdh, ecdh_key_new, ARG(ecdh_alg, alg), ARG(boolean, is_server))
FUNC(void, ecdh_key_getpublic, ARG(val_ecdh, key),
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
ARG(out_val_string_binarysink, pub))
Refactor ecdh_kex into an organised vtable. This is already slightly nice because it lets me separate the Weierstrass and Montgomery code more completely, without having to have a vtable tucked into dh->extra. But more to the point, it will allow completely different kex methods to fit into the same framework later. To that end, I've moved more of the descriptive message generation into the vtable, and also provided the constructor with a flag that will let it do different things in client and server. Also, following on from a previous commit, I've arranged that the new API returns arbitrary binary data for the exchange hash, rather than an mp_int. An upcoming implementation of this interface will want to return an encoded string instead of an encoded mp_int.
2022-04-14 06:04:33 +00:00
FUNC_WRAPPED(opt_val_string, ecdh_key_getkey, ARG(val_ecdh, key),
ARG(val_string_ptrlen, pub))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
Implement OpenSSH 9.x's NTRU Prime / Curve25519 kex. This consists of DJB's 'Streamlined NTRU Prime' quantum-resistant cryptosystem, currently in round 3 of the NIST post-quantum key exchange competition; it's run in parallel with ordinary Curve25519, and generates a shared secret combining the output of both systems. (Hence, even if you don't trust this newfangled NTRU Prime thing at all, it's at least no _less_ secure than the kex you were using already.) As the OpenSSH developers point out, key exchange is the most urgent thing to make quantum-resistant, even before working quantum computers big enough to break crypto become available, because a break of the kex algorithm can be applied retroactively to recordings of your past sessions. By contrast, authentication is a real-time protocol, and can only be broken by a quantum computer if there's one available to attack you _already_. I've implemented both sides of the mechanism, so that PuTTY and Uppity both support it. In my initial testing, the two sides can both interoperate with the appropriate half of OpenSSH, and also (of course, but it would be embarrassing to mess it up) with each other.
2022-04-15 16:19:47 +00:00
/*
* NTRU and its subroutines.
*/
FUNC_WRAPPED(int16_list, ntru_ring_multiply, ARG(int16_list, a),
ARG(int16_list, b), ARG(uint, p), ARG(uint, q))
FUNC_WRAPPED(opt_int16_list, ntru_ring_invert, ARG(int16_list, r),
ARG(uint, p), ARG(uint, q))
FUNC_WRAPPED(int16_list, ntru_mod3, ARG(int16_list, r),
ARG(uint, p), ARG(uint, q))
FUNC_WRAPPED(int16_list, ntru_round3, ARG(int16_list, r),
ARG(uint, p), ARG(uint, q))
FUNC_WRAPPED(int16_list, ntru_bias, ARG(int16_list, r),
ARG(uint, bias), ARG(uint, p), ARG(uint, q))
FUNC_WRAPPED(int16_list, ntru_scale, ARG(int16_list, r),
ARG(uint, scale), ARG(uint, p), ARG(uint, q))
FUNC_WRAPPED(val_ntruencodeschedule, ntru_encode_schedule, ARG(int16_list, ms))
FUNC(uint, ntru_encode_schedule_length, ARG(val_ntruencodeschedule, sched))
FUNC_WRAPPED(void, ntru_encode, ARG(val_ntruencodeschedule, sched),
ARG(int16_list, rs), ARG(out_val_string_binarysink, data))
FUNC_WRAPPED(opt_int16_list, ntru_decode, ARG(val_ntruencodeschedule, sched),
ARG(val_string_ptrlen, data))
FUNC_WRAPPED(int16_list, ntru_gen_short, ARG(uint, p), ARG(uint, w))
FUNC(val_ntrukeypair, ntru_keygen, ARG(uint, p), ARG(uint, q), ARG(uint, w))
FUNC_WRAPPED(int16_list, ntru_pubkey, ARG(val_ntrukeypair, keypair))
FUNC_WRAPPED(int16_list, ntru_encrypt, ARG(int16_list, plaintext),
ARG(int16_list, pubkey), ARG(uint, p), ARG(uint, q))
FUNC_WRAPPED(int16_list, ntru_decrypt, ARG(int16_list, ciphertext),
ARG(val_ntrukeypair, keypair))
New post-quantum kex: ML-KEM, and three hybrids of it. As standardised by NIST in FIPS 203, this is a lattice-based post-quantum KEM. Very vaguely, the idea of it is that your public key is a matrix A and vector t, and the private key is the knowledge of how to decompose t into two vectors with all their coefficients small, one transformed by A relative to the other. Encryption of a binary secret starts by turning each bit into one of two maximally separated residues mod a prime q, and then adding 'noise' based on the public key in the form of small increments and decrements mod q, again with some of the noise transformed by A relative to the rest. Decryption uses the knowledge of t's decomposition to align the two sets of noise so that the _large_ changes (which masked the secret from an eavesdropper) cancel out, leaving only a collection of small changes to the original secret vector. Then the vector of input bits can be recovered by assuming that those accumulated small pieces of noise haven't concentrated in any particular residue enough to push it more than half way to the other of its possible starting values. A weird feature of it is that decryption is not a true mathematical inverse of encryption. The assumption that the noise doesn't get large enough to flip any bit of the secret is only probabilistically valid, not a hard guarantee. In other words, key agreement can fail, simply by getting particularly unlucky with the distribution of your random noise! However, the probability of a failure is very low - less than 2^-138 even for ML-KEM-512, and gets even smaller with the larger variants. An awkward feature for our purposes is that the matrix A, containing a large number of residues mod the prime q=3329, is required to be constructed by a process of rejection sampling, i.e. generating random 12-bit values and throwing away the out-of-range ones. That would be a real pain for our side-channel testing system, which generally handles rejection sampling badly (since it necessarily involves data-dependent control flow and timing variation). Fortunately, the matrix and the random seed it was made from are both public: the matrix seed is transmitted as part of the public key, so it's not necessary to try to hide it. Accordingly, I was able to get the implementation to pass testsc by means of not varying the matrix seed between runs, which is justified by the principle of testsc that you vary the _secrets_ to ensure timing is independent of them - and the matrix seed isn't a secret, so you're allowed to keep it the same. The three hybrid algorithms, defined by the current Internet-Draft draft-kampanakis-curdle-ssh-pq-ke, include one hybrid of ML-KEM-768 with Curve25519 in exactly the same way we were already hybridising NTRU Prime with Curve25519, and two more hybrids of ML-KEM with ECDH over a NIST curve. The former hybrid interoperates with the implementation in OpenSSH 9.9; all three interoperate with the fork 'openssh-oqs' at github.com/open-quantum-safe/openssh, and also with the Python library AsyncSSH.
2024-12-07 19:33:39 +00:00
/*
* ML-KEM and its subroutines.
*/
FUNC(void, mlkem_keygen,
ARG(out_val_string_binarysink, ek), ARG(out_val_string_binarysink, dk),
ARG(mlkem_params, params))
FUNC_WRAPPED(void, mlkem_keygen_internal,
ARG(out_val_string_binarysink, ek),
ARG(out_val_string_binarysink, dk),
ARG(mlkem_params, params),
ARG(val_string_ptrlen, d), ARG(val_string_ptrlen, z))
FUNC_WRAPPED(void, mlkem_keygen_rho_sigma,
ARG(out_val_string_binarysink, ek),
ARG(out_val_string_binarysink, dk),
ARG(mlkem_params, params), ARG(val_string_ptrlen, rho),
ARG(val_string_ptrlen, sigma), ARG(val_string_ptrlen, z))
FUNC(boolean, mlkem_encaps,
ARG(out_val_string_binarysink, ciphertext),
ARG(out_val_string_binarysink, k),
ARG(mlkem_params, params),
ARG(val_string_ptrlen, ek))
FUNC_WRAPPED(boolean, mlkem_encaps_internal,
ARG(out_val_string_binarysink, ciphertext),
ARG(out_val_string_binarysink, k),
ARG(mlkem_params, params),
ARG(val_string_ptrlen, ek), ARG(val_string_ptrlen, m))
FUNC(boolean, mlkem_decaps, ARG(out_val_string_binarysink, k),
ARG(mlkem_params, params), ARG(val_string_ptrlen, dk),
ARG(val_string_ptrlen, ciphertext))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
Factor out get_rsa_ssh1_priv_agent from Pageant. The code that reads an SSH1_AGENTC_ADD_RSA_IDENTITY message and parses an RSA private key out of it now does it by calling a BinarySource function in sshrsa.c, instead of doing inline in the Pageant message handler. This has no functional change, except that now I can expose that separate function in the testcrypt API, where it provides me with a mechanism for creating a bare RSAKey structure for purposes of testing RSA key exchange.
2019-12-15 20:12:36 +00:00
* RSA key exchange, and also the BinarySource get function
* get_ssh1_rsa_priv_agent, which is a convenient way to make an
* RSAKey for RSA kex testing purposes.
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_rsakex, ssh_rsakex_newkey, ARG(val_string_ptrlen, data))
FUNC(uint, ssh_rsakex_klen, ARG(val_rsakex, key))
FUNC(val_string, ssh_rsakex_encrypt, ARG(val_rsakex, key), ARG(hashalg, h),
ARG(val_string_ptrlen, plaintext))
FUNC(opt_val_mpint, ssh_rsakex_decrypt, ARG(val_rsakex, key), ARG(hashalg, h),
ARG(val_string_ptrlen, ciphertext))
FUNC(val_rsakex, get_rsa_ssh1_priv_agent, ARG(val_string_binarysource, src))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* Bare RSA keys as used in SSH-1. The construction API functions
* write into an existing RSAKey object, so I've invented an 'rsa_new'
* function to make one in the first place.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_rsa, rsa_new, VOID)
FUNC(void, get_rsa_ssh1_pub, ARG(val_string_binarysource, src),
ARG(val_rsa, key), ARG(rsaorder, order))
FUNC(void, get_rsa_ssh1_priv, ARG(val_string_binarysource, src),
ARG(val_rsa, key))
FUNC_WRAPPED(opt_val_string, rsa_ssh1_encrypt, ARG(val_string_ptrlen, data),
ARG(val_rsa, key))
FUNC(val_mpint, rsa_ssh1_decrypt, ARG(val_mpint, input), ARG(val_rsa, key))
FUNC_WRAPPED(val_string, rsa_ssh1_decrypt_pkcs1, ARG(val_mpint, input),
ARG(val_rsa, key))
FUNC(val_string_asciz, rsastr_fmt, ARG(val_rsa, key))
FUNC(val_string_asciz, rsa_ssh1_fingerprint, ARG(val_rsa, key))
FUNC(void, rsa_ssh1_public_blob, ARG(out_val_string_binarysink, blob),
ARG(val_rsa, key), ARG(rsaorder, order))
FUNC(int, rsa_ssh1_public_blob_len, ARG(val_string_ptrlen, data))
FUNC(void, rsa_ssh1_private_blob_agent, ARG(out_val_string_binarysink, blob),
ARG(val_rsa, key))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
/*
* The PRNG type. Similarly to hashes and MACs, I've invented an extra
* function prng_seed_update for putting seed data into the PRNG's
* exposed BinarySink.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_prng, prng_new, ARG(hashalg, hashalg))
FUNC(void, prng_seed_begin, ARG(val_prng, pr))
FUNC(void, prng_seed_update, ARG(val_prng, pr), ARG(val_string_ptrlen, data))
FUNC(void, prng_seed_finish, ARG(val_prng, pr))
FUNC_WRAPPED(val_string, prng_read, ARG(val_prng, pr), ARG(uint, size))
FUNC(void, prng_add_entropy, ARG(val_prng, pr), ARG(uint, source_id),
ARG(val_string_ptrlen, data))
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
Expose the key-file marshalling functions in testcrypt. This will allow me to write tests for them.
2020-01-06 19:58:25 +00:00
/*
* Key load/save functions, or rather, the BinarySource / strbuf API
* that sits just inside the file I/O versions.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(boolean, ppk_encrypted_s, ARG(val_string_binarysource, src),
ARG(out_opt_val_string_asciz, comment))
FUNC(boolean, rsa1_encrypted_s, ARG(val_string_binarysource, src),
ARG(out_opt_val_string_asciz, comment))
FUNC(boolean, ppk_loadpub_s, ARG(val_string_binarysource, src),
ARG(out_opt_val_string_asciz, algorithm),
ARG(out_val_string_binarysink, blob),
ARG(out_opt_val_string_asciz, comment),
ARG(out_opt_val_string_asciz_const, error))
FUNC(int, rsa1_loadpub_s, ARG(val_string_binarysource, src),
ARG(out_val_string_binarysink, blob),
ARG(out_opt_val_string_asciz, comment),
ARG(out_opt_val_string_asciz_const, error))
FUNC_WRAPPED(opt_val_key, ppk_load_s, ARG(val_string_binarysource, src),
ARG(out_opt_val_string_asciz, comment),
ARG(opt_val_string_asciz, passphrase),
ARG(out_opt_val_string_asciz_const, error))
FUNC_WRAPPED(int, rsa1_load_s, ARG(val_string_binarysource, src),
ARG(val_rsa, key), ARG(out_opt_val_string_asciz, comment),
ARG(opt_val_string_asciz, passphrase),
ARG(out_opt_val_string_asciz_const, error))
FUNC_WRAPPED(val_string, ppk_save_sb, ARG(val_key, key),
ARG(opt_val_string_asciz, comment),
ARG(opt_val_string_asciz, passphrase), ARG(uint, fmt_version),
ARG(argon2flavour, flavour), ARG(uint, mem), ARG(uint, passes),
ARG(uint, parallel))
FUNC_WRAPPED(val_string, rsa1_save_sb, ARG(val_rsa, key),
ARG(opt_val_string_asciz, comment),
ARG(opt_val_string_asciz, passphrase))
Expose the key-file marshalling functions in testcrypt. This will allow me to write tests for them.
2020-01-06 19:58:25 +00:00
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_string_asciz, ssh2_fingerprint_blob, ARG(val_string_ptrlen, blob),
ARG(fptype, fptype))
Introduce OpenSSH-compatible SHA256 key fingerprinting. There's a new enumeration of fingerprint types, and you tell ssh2_fingerprint() or ssh2_fingerprint_blob() which of them to use. So far, this is only implemented behind the scenes, and exposed for testcrypt to test. All the call sites of ssh2_fingerprint pass a fixed default fptype, which is still set to the old MD5. That will change shortly.
2021-03-13 09:52:56 +00:00
Add implementation of the Argon2 password hash. This is going to be used in the new version of the PPK file format. It was the winner of the Password Hashing Context, which I think makes it a reasonable choice. Argon2 comes in three flavours: one with no data dependency in its memory addressing, one with _deliberate_ data dependency (intended to serialise computation, to hinder parallel brute-forcing), and a hybrid form that starts off data-independent and then switches over to the dependent version once the sensitive input data has been adequately mixed around. I test all three in the test suite; the side-channel tester can only expect Argon2i to pass; and, following the spec's recommendation, I'll be using Argon2id for the actual key file encryption.
2021-02-13 17:30:12 +00:00
/*
* Password hashing.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC_WRAPPED(val_string, argon2, ARG(argon2flavour, flavour), ARG(uint, mem),
ARG(uint, passes), ARG(uint, parallel), ARG(uint, taglen),
ARG(val_string_ptrlen, P), ARG(val_string_ptrlen, S),
ARG(val_string_ptrlen, K), ARG(val_string_ptrlen, X))
FUNC(val_string, argon2_long_hash, ARG(uint, length),
ARG(val_string_ptrlen, data))
Expose openssh_bcrypt() to testcrypt, and test it. I happened to notice in passing that this function doesn't have any tests (although it will have been at least somewhat tested by the cmdgen interop test system). This involved writing a wrapper that passes the passphrase and salt as ptrlens, and I decided it made more sense to make the same change to the original function too and adjust the call sites appropriately. I derived a test case by getting OpenSSH itself to make an encrypted key file, and then using the inputs and output from the password hash operation that decrypted it again.
2021-12-24 09:56:30 +00:00
FUNC_WRAPPED(val_string, openssh_bcrypt, ARG(val_string_ptrlen, passphrase),
ARG(val_string_ptrlen, salt), ARG(uint, rounds),
ARG(uint, outbytes))
Add implementation of the Argon2 password hash. This is going to be used in the new version of the PPK file format. It was the winner of the Password Hashing Context, which I think makes it a reasonable choice. Argon2 comes in three flavours: one with no data dependency in its memory addressing, one with _deliberate_ data dependency (intended to serialise computation, to hinder parallel brute-forcing), and a hybrid form that starts off data-independent and then switches over to the dependent version once the sensitive input data has been adequately mixed around. I test all three in the test suite; the side-channel tester can only expect Argon2i to pass; and, following the spec's recommendation, I'll be using Argon2id for the actual key file encryption.
2021-02-13 17:30:12 +00:00
Expose key generation functions in testcrypt. They're not much use for 'real' key generation, since like all the other randomness-using testcrypt functions, they need you to have explicitly queued up some random data. But for generating keys for test purposes, they have the great virtue that they deliver the key in the internal format, where we can generate all the various public and private blobs from it as well as the on-disk formats. A minor change to one of the keygen functions itself: rsa_generate now fills in the 'bits' and 'bytes' fields of the returned RSAKey, without which it didn't actually work to try to generate a public blob from it. (We'd never noticed before, because no previous client of rsa_generate even tried that.)
2020-01-09 07:21:30 +00:00
/*
* Key generation functions.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC_WRAPPED(val_key, rsa_generate, ARG(uint, bits), ARG(boolean, strong),
ARG(val_pgc, pgc))
FUNC_WRAPPED(val_key, dsa_generate, ARG(uint, bits), ARG(val_pgc, pgc))
FUNC_WRAPPED(opt_val_key, ecdsa_generate, ARG(uint, bits))
FUNC_WRAPPED(opt_val_key, eddsa_generate, ARG(uint, bits))
FUNC(val_rsa, rsa1_generate, ARG(uint, bits), ARG(boolean, strong),
ARG(val_pgc, pgc))
FUNC(val_pgc, primegen_new_context, ARG(primegenpolicy, policy))
FUNC_WRAPPED(opt_val_mpint, primegen_generate, ARG(val_pgc, ctx),
ARG(consumed_val_pcs, pcs))
FUNC(val_string, primegen_mpu_certificate, ARG(val_pgc, ctx), ARG(val_mpint, p))
FUNC(val_pcs, pcs_new, ARG(uint, bits))
FUNC(val_pcs, pcs_new_with_firstbits, ARG(uint, bits), ARG(uint, first),
ARG(uint, nfirst))
FUNC(void, pcs_require_residue, ARG(val_pcs, s), ARG(val_mpint, mod),
ARG(val_mpint, res))
FUNC(void, pcs_require_residue_1, ARG(val_pcs, s), ARG(val_mpint, mod))
FUNC(void, pcs_require_residue_1_mod_prime, ARG(val_pcs, s),
ARG(val_mpint, mod))
FUNC(void, pcs_avoid_residue_small, ARG(val_pcs, s), ARG(uint, mod),
ARG(uint, res))
FUNC(void, pcs_try_sophie_germain, ARG(val_pcs, s))
FUNC(void, pcs_set_oneshot, ARG(val_pcs, s))
FUNC(void, pcs_ready, ARG(val_pcs, s))
FUNC(void, pcs_inspect, ARG(val_pcs, pcs), ARG(out_val_mpint, limit_out),
ARG(out_val_mpint, factor_out), ARG(out_val_mpint, addend_out))
FUNC(val_mpint, pcs_generate, ARG(val_pcs, s))
FUNC(val_pockle, pockle_new, VOID)
FUNC(uint, pockle_mark, ARG(val_pockle, pockle))
FUNC(void, pockle_release, ARG(val_pockle, pockle), ARG(uint, mark))
FUNC(pocklestatus, pockle_add_small_prime, ARG(val_pockle, pockle),
ARG(val_mpint, p))
FUNC_WRAPPED(pocklestatus, pockle_add_prime, ARG(val_pockle, pockle),
ARG(val_mpint, p), ARG(mpint_list, factors),
ARG(val_mpint, witness))
FUNC(val_string, pockle_mpu, ARG(val_pockle, pockle), ARG(val_mpint, p))
FUNC(val_millerrabin, miller_rabin_new, ARG(val_mpint, p))
FUNC(mr_result, miller_rabin_test, ARG(val_millerrabin, mr), ARG(val_mpint, w))
Expose key generation functions in testcrypt. They're not much use for 'real' key generation, since like all the other randomness-using testcrypt functions, they need you to have explicitly queued up some random data. But for generating keys for test purposes, they have the great virtue that they deliver the key in the internal format, where we can generate all the various public and private blobs from it as well as the on-disk formats. A minor change to one of the keygen functions itself: rsa_generate now fills in the 'bits' and 'bytes' fields of the returned RSAKey, without which it didn't actually work to try to generate a public blob from it. (We'd never noticed before, because no previous client of rsa_generate even tried that.)
2020-01-09 07:21:30 +00:00
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* Miscellaneous.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(val_wpoint, ecdsa_public, ARG(val_mpint, private_key), ARG(keyalg, alg))
FUNC(val_epoint, eddsa_public, ARG(val_mpint, private_key), ARG(keyalg, alg))
FUNC_WRAPPED(val_string, des_encrypt_xdmauth, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, des_decrypt_xdmauth, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, des3_encrypt_pubkey, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, des3_decrypt_pubkey, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, des3_encrypt_pubkey_ossh, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, iv), ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, des3_decrypt_pubkey_ossh, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, iv), ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, aes256_encrypt_pubkey, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, iv), ARG(val_string_ptrlen, blk))
FUNC_WRAPPED(val_string, aes256_decrypt_pubkey, ARG(val_string_ptrlen, key),
ARG(val_string_ptrlen, iv), ARG(val_string_ptrlen, blk))
FUNC(uint, crc32_rfc1662, ARG(val_string_ptrlen, data))
FUNC(uint, crc32_ssh1, ARG(val_string_ptrlen, data))
FUNC(uint, crc32_update, ARG(uint, crc_input), ARG(val_string_ptrlen, data))
FUNC(boolean, crcda_detect, ARG(val_string_ptrlen, packet),
ARG(val_string_ptrlen, iv))
FUNC(val_string, get_implementations_commasep, ARG(val_string_ptrlen, alg))
FUNC(void, http_digest_response, ARG(out_val_string_binarysink, response),
ARG(val_string_ptrlen, username), ARG(val_string_ptrlen, password),
ARG(val_string_ptrlen, realm), ARG(val_string_ptrlen, method),
ARG(val_string_ptrlen, uri), ARG(val_string_ptrlen, qop),
ARG(val_string_ptrlen, nonce), ARG(val_string_ptrlen, opaque),
ARG(uint, nonce_count), ARG(httpdigesthash, hash),
ARG(boolean, hash_username))
New test system for mp_int and cryptography. I've written a new standalone test program which incorporates all of PuTTY's crypto code, including the mp_int and low-level elliptic curve layers but also going all the way up to the implementations of the MAC, hash, cipher, public key and kex abstractions. The test program itself, 'testcrypt', speaks a simple line-oriented protocol on standard I/O in which you write the name of a function call followed by some inputs, and it gives you back a list of outputs preceded by a line telling you how many there are. Dynamically allocated objects are assigned string ids in the protocol, and there's a 'free' function that tells testcrypt when it can dispose of one. It's possible to speak that protocol by hand, but cumbersome. I've also provided a Python module that wraps it, by running testcrypt as a persistent subprocess and gatewaying all the function calls into things that look reasonably natural to call from Python. The Python module and testcrypt.c both read a carefully formatted header file testcrypt.h which contains the name and signature of every exported function, so it costs minimal effort to expose a given function through this test API. In a few cases it's necessary to write a wrapper in testcrypt.c that makes the function look more friendly, but mostly you don't even need that. (Though that is one of the motivations between a lot of API cleanups I've done recently!) I considered doing Python integration in the more obvious way, by linking parts of the PuTTY code directly into a native-code .so Python module. I decided against it because this way is more flexible: I can run the testcrypt program on its own, or compile it in a way that Python wouldn't play nicely with (I bet compiling just that .so with Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or attach a debugger to it. I can even recompile testcrypt for a different CPU architecture (32- vs 64-bit, or even running it on a different machine over ssh or under emulation) and still layer the nice API on top of that via the local Python interpreter. All I need is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
/*
* These functions aren't part of PuTTY's own API, but are additions
* by testcrypt itself for administrative purposes.
*/
testcrypt-funcs.h: remove extra parens round argument lists. They were there to work around that annoying feature of VS's preprocessor when it expands __VA_ARGS__ into the argument list of another macro. But I've just thought of a workaround that I can apply in testcrypt.c itself, so that those parens don't have to appear in every function definition in the header file. The trick is, instead of writing destination_macro(__VA_ARGS__) you instead write JUXTAPOSE(destination_macro, (__VA_ARGS__)) where JUXTAPOSE is defined to be a macro that simply expands its two arguments next to each other: #define JUXTAPOSE(first, second) first second This works because the arguments to JUXTAPOSE get macro-expanded _before_ passing them to JUXTAPOSE itself - the same reason that the standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h here). So this defuses the magic behaviour of commas expanded from __VA_ARGS__, and causes the destination macro to get all its arguments in the expected places again.
2021-11-28 09:39:49 +00:00
FUNC(void, random_queue, ARG(val_string_ptrlen, data))
FUNC(uint, random_queue_len, VOID)
FUNC(void, random_make_prng, ARG(hashalg, hashalg),
ARG(val_string_ptrlen, seed))
FUNC(void, random_clear, VOID)
Reference in New Issue Copy Permalink