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

563 lines
26 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
*
* FUNC(return-type, function-name, (arguments))
*
* where 'arguments' in turn is either VOID, or a comma-separated list
* of argument specifications of the form
*
* ARG(argument-type, argument-name)
*
* 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
*
* FUNC(val_foo, example, (ARG(out_val_bar, bar), ARG(val_baz, baz)))
*
* 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.
*/
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
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)))
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(void, mp_min_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, x), ARG(val_mpint, y)))
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(void, mp_max_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, x), ARG(val_mpint, y)))
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
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)))
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(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,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b)))
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(void, mp_sub_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b)))
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(void, mp_mul_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b)))
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
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)))
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(void, mp_and_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b)))
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(void, mp_or_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b)))
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(void, mp_xor_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b)))
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(void, mp_bic_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b)))
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
FUNC(void, mp_copy_integer_into, (ARG(val_mpint, dest), ARG(uint, n)))
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(void, mp_add_integer_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(uint, n)))
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(void, mp_sub_integer_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(uint, n)))
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(void, mp_mul_integer_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(uint, n)))
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(void, mp_cond_add_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b),
ARG(uint, yes)))
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(void, mp_cond_sub_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, a), ARG(val_mpint, b),
ARG(uint, yes)))
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(void, mp_cond_swap,
(ARG(val_mpint, x0), ARG(val_mpint, x1), ARG(uint, swap)))
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
FUNC(void, mp_cond_clear, (ARG(val_mpint, x), ARG(uint, clear)))
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(void, mp_divmod_into,
(ARG(val_mpint, n), ARG(val_mpint, d), ARG(opt_val_mpint, q),
ARG(opt_val_mpint, r)))
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
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)))
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(val_mpint, mp_nthroot,
(ARG(val_mpint, y), ARG(uint, n), ARG(opt_val_mpint, remainder)))
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
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)))
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(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)))
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
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)))
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(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 */
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(val_mpint, mp_modsqrt,
(ARG(val_modsqrt, sc), ARG(val_mpint, x), ARG(out_uint, success)))
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
FUNC(val_monty, monty_new, (ARG(val_mpint, modulus)))
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
FUNC_WRAPPED(val_mpint, monty_modulus, (ARG(val_monty, mc)))
FUNC_WRAPPED(val_mpint, monty_identity, (ARG(val_monty, mc)))
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(void, monty_import_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_monty, mc), ARG(val_mpint, dest), ARG(val_mpint, x)))
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
FUNC(val_mpint, monty_import, (ARG(val_monty, mc), ARG(val_mpint, x)))
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(void, monty_export_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_monty, mc), ARG(val_mpint, dest), ARG(val_mpint, x)))
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
FUNC(val_mpint, monty_export, (ARG(val_monty, mc), ARG(val_mpint, x)))
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(void, monty_mul_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_monty, mc), ARG(val_mpint, dest), ARG(val_mpint, x),
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
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)))
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
FUNC(val_mpint, monty_invert, (ARG(val_monty, mc), ARG(val_mpint, x)))
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(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,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, x), ARG(uint, shift)))
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(void, mp_rshift_safe_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, x), ARG(uint, shift)))
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
FUNC(val_mpint, mp_rshift_safe, (ARG(val_mpint, x), ARG(uint, shift)))
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(void, mp_lshift_fixed_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, x), ARG(uint, shift)))
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(void, mp_rshift_fixed_into,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpint, dest), ARG(val_mpint, x), ARG(uint, shift)))
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
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.
*/
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(val_wcurve, ecc_weierstrass_curve,
(ARG(val_mpint, p), ARG(val_mpint, a), ARG(val_mpint, b),
ARG(opt_val_mpint, nonsquare_mod_p)))
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
FUNC(val_wpoint, ecc_weierstrass_point_new_identity, (ARG(val_wcurve, curve)))
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(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)))
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(val_wpoint, ecc_weierstrass_point_copy, (ARG(val_wpoint, orig)))
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
FUNC(uint, ecc_weierstrass_point_valid, (ARG(val_wpoint, P)))
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(val_wpoint, ecc_weierstrass_add_general,
(ARG(val_wpoint, P), ARG(val_wpoint, Q)))
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
FUNC(val_wpoint, ecc_weierstrass_add, (ARG(val_wpoint, P), ARG(val_wpoint, Q)))
FUNC(val_wpoint, ecc_weierstrass_double, (ARG(val_wpoint, P)))
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(val_wpoint, ecc_weierstrass_multiply,
(ARG(val_wpoint, B), ARG(val_mpint, n)))
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
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 */
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(void, ecc_weierstrass_get_affine,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_wpoint, P), ARG(out_val_mpint, x), ARG(out_val_mpint, y)))
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(val_mcurve, ecc_montgomery_curve,
(ARG(val_mpint, p), ARG(val_mpint, a), ARG(val_mpint, b)))
FUNC(val_mpoint, ecc_montgomery_point_new,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mcurve, curve), ARG(val_mpint, x)))
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
FUNC(val_mpoint, ecc_montgomery_point_copy, (ARG(val_mpoint, orig)))
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(val_mpoint, ecc_montgomery_diff_add,
(ARG(val_mpoint, P), ARG(val_mpoint, Q), ARG(val_mpoint, PminusQ)))
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
FUNC(val_mpoint, ecc_montgomery_double, (ARG(val_mpoint, P)))
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(val_mpoint, ecc_montgomery_multiply,
(ARG(val_mpoint, B), ARG(val_mpint, n)))
FUNC(void, ecc_montgomery_get_affine,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_mpoint, P), ARG(out_val_mpint, x)))
FUNC(boolean, ecc_montgomery_is_identity, (ARG(val_mpoint, P)))
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(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)))
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(val_epoint, ecc_edwards_point_copy, (ARG(val_epoint, orig)))
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
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)))
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(void, ecc_edwards_get_affine,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(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.
*/
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
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)))
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
FUNC_WRAPPED(val_string, ssh_hash_digest, (ARG(val_hash, h)))
FUNC_WRAPPED(val_string, ssh_hash_final, (ARG(consumed_val_hash, h)))
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
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
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
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
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.
*/
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
FUNC(val_mac, ssh2_mac_new, (ARG(macalg, alg), ARG(opt_val_cipher, cipher)))
FUNC(void, ssh2_mac_setkey, (ARG(val_mac, m), ARG(val_string_ptrlen, key)))
FUNC(void, ssh2_mac_start, (ARG(val_mac, m)))
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(void, ssh2_mac_update, (ARG(val_mac, m), ARG(val_string_ptrlen, data)))
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
FUNC_WRAPPED(val_string, ssh2_mac_genresult, (ARG(val_mac, m)))
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
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
/*
* 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: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(val_key, ssh_key_new_pub, (ARG(keyalg, alg), ARG(val_string_ptrlen, pub)))
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_key, ssh_key_new_priv,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(keyalg, alg), ARG(val_string_ptrlen, pub),
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
ARG(val_string_ptrlen, priv)))
FUNC(opt_val_key, ssh_key_new_priv_openssh,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(keyalg, alg), ARG(val_string_binarysource, src)))
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, 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),
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
ARG(out_val_string_binarysink, sig)))
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(boolean, ssh_key_verify,
(ARG(val_key, key), ARG(val_string_ptrlen, sig),
ARG(val_string_ptrlen, data)))
FUNC(void, ssh_key_public_blob,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_key, key), ARG(out_val_string_binarysink, blob)))
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(void, ssh_key_private_blob,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_key, key), ARG(out_val_string_binarysink, blob)))
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(void, ssh_key_openssh_blob,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_key, key), ARG(out_val_string_binarysink, blob)))
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
FUNC(val_string_asciz, ssh_key_cache_str, (ARG(val_key, key)))
FUNC(val_keycomponents, ssh_key_components, (ARG(val_key, key)))
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(uint, ssh_key_public_bits,
(ARG(keyalg, self), ARG(val_string_ptrlen, blob)))
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'.
*/
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
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,
(ARG(val_keycomponents, kc), ARG(uint, n)))
FUNC(opt_val_string_asciz_const, key_components_nth_str,
(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
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.
*/
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
FUNC(opt_val_cipher, ssh_cipher_new, (ARG(cipheralg, alg)))
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_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)))
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: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +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)))
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
FUNC(uint, dh_modulus_bit_size, (ARG(val_dh, ctx)))
FUNC(val_mpint, dh_create_e, (ARG(val_dh, ctx), ARG(uint, nbits)))
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
FUNC_WRAPPED(boolean, dh_validate_f, (ARG(val_dh, ctx), ARG(val_mpint, f)))
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
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.
*/
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(val_ecdh, ssh_ecdhkex_newkey, (ARG(ecdh_alg, alg)))
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(void, ssh_ecdhkex_getpublic,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(val_ecdh, key), ARG(out_val_string_binarysink, pub)))
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_mpint, ssh_ecdhkex_getkey,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(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
/*
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
*/
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
FUNC(val_rsakex, ssh_rsakex_newkey, (ARG(val_string_ptrlen, data)))
FUNC(uint, ssh_rsakex_klen, (ARG(val_rsakex, key)))
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(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)))
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
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.
*/
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
FUNC(val_rsa, rsa_new, (VOID))
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(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)))
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
FUNC(val_mpint, rsa_ssh1_decrypt, (ARG(val_mpint, input), ARG(val_rsa, key)))
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_WRAPPED(val_string, rsa_ssh1_decrypt_pkcs1,
(ARG(val_mpint, input), ARG(val_rsa, key)))
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
FUNC(val_string_asciz, rsastr_fmt, (ARG(val_rsa, key)))
FUNC(val_string_asciz, rsa_ssh1_fingerprint, (ARG(val_rsa, key)))
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(void, rsa_ssh1_public_blob,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(ARG(out_val_string_binarysink, blob), ARG(val_rsa, key),
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
ARG(rsaorder, order)))
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
FUNC(int, rsa_ssh1_public_blob_len, (ARG(val_string_ptrlen, data)))
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(void, rsa_ssh1_private_blob_agent,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(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.
*/
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
FUNC(val_prng, prng_new, (ARG(hashalg, hashalg)))
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(void, prng_seed_begin, (ARG(val_prng, pr)))
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
FUNC(void, prng_seed_update, (ARG(val_prng, pr), ARG(val_string_ptrlen, data)))
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(void, prng_seed_finish, (ARG(val_prng, pr)))
FUNC_WRAPPED(val_string, prng_read, (ARG(val_prng, pr), ARG(uint, size)))
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(void, prng_add_entropy,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(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.
*/
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(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),
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
ARG(out_val_string_binarysink, blob),
ARG(out_opt_val_string_asciz, comment),
ARG(out_opt_val_string_asciz_const, error)))
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(int, rsa1_loadpub_s,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(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)))
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_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),
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
ARG(out_opt_val_string_asciz_const, error)))
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_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),
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
ARG(out_opt_val_string_asciz_const, error)))
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_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
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(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.
*/
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_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)))
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.
*/
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_WRAPPED(val_key, rsa_generate,
(ARG(uint, bits), ARG(boolean, strong), ARG(val_pgc, pgc)))
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
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)))
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(val_rsa, rsa1_generate,
(ARG(uint, bits), ARG(boolean, strong), ARG(val_pgc, pgc)))
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
FUNC(val_pgc, primegen_new_context, (ARG(primegenpolicy, policy)))
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_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)))
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
FUNC(val_pcs, pcs_new, (ARG(uint, bits)))
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(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)))
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
FUNC(void, pcs_require_residue_1, (ARG(val_pcs, s), ARG(val_mpint, mod)))
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(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)))
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
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)))
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(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)))
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
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)))
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(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)))
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
FUNC(val_string, pockle_mpu, (ARG(val_pockle, pockle), ARG(val_mpint, p)))
FUNC(val_millerrabin, miller_rabin_new, (ARG(val_mpint, p)))
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(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.
*/
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
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)))
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_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)))
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
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)))
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(boolean, crcda_detect,
(ARG(val_string_ptrlen, packet), ARG(val_string_ptrlen, iv)))
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
FUNC(val_string, get_implementations_commasep, (ARG(val_string_ptrlen, alg)))
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(void, http_digest_response,
testcrypt: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
(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: adjust some function parameter names. Now those names appear in help files, I thought it was worth giving them a read-through and spotting any really obviously confusing or wrong ones. Quite a few make more sense in the original context of C than in the derived Python (e.g. 'BinarySink *bs' as a place to write output to makes sense, but the output 'val_string bs' is less helpful). A couple were so confusing that I also corrected them in the original C, notably the misuse of 'wc' for the elliptic curve point input to ecc_weierstrass_point_copy. ('wc' in that section of the code is normally a parameter describing a whole curve.)
2021-11-21 22:13:02 +00:00
FUNC(void, random_queue, (ARG(val_string_ptrlen, data)))
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
FUNC(uint, random_queue_len, (VOID))
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(void, random_make_prng,
(ARG(hashalg, hashalg), ARG(val_string_ptrlen, seed)))
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
FUNC(void, random_clear, (VOID))
Reference in New Issue Copy Permalink