diff options
Diffstat (limited to 'comm/third_party/libgcrypt/doc/gcrypt.info-1')
| -rw-r--r-- | comm/third_party/libgcrypt/doc/gcrypt.info-1 | 7269 |
1 files changed, 7269 insertions, 0 deletions
diff --git a/comm/third_party/libgcrypt/doc/gcrypt.info-1 b/comm/third_party/libgcrypt/doc/gcrypt.info-1 new file mode 100644 index 0000000000..3bd16f486e --- /dev/null +++ b/comm/third_party/libgcrypt/doc/gcrypt.info-1 @@ -0,0 +1,7269 @@ +This is gcrypt.info, produced by makeinfo version 6.5 from gcrypt.texi. + +This manual is for Libgcrypt version 1.9.2 and was last updated 28 +January 2021. Libgcrypt is GNU's library of cryptographic building +blocks. + +Copyright (C) 2000, 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2011, 2012 +Free Software Foundation, Inc. +Copyright (C) 2012, 2013, 2016, 2017 g10 Code GmbH + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. The text of the + license can be found in the section entitled "GNU General Public + License". +INFO-DIR-SECTION GNU Libraries +START-INFO-DIR-ENTRY +* libgcrypt: (gcrypt). Cryptographic function library. +END-INFO-DIR-ENTRY + + +File: gcrypt.info, Node: Top, Next: Introduction, Up: (dir) + +The Libgcrypt Library +********************* + +This manual is for Libgcrypt version 1.9.2 and was last updated 28 +January 2021. Libgcrypt is GNU's library of cryptographic building +blocks. + +Copyright (C) 2000, 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2011, 2012 +Free Software Foundation, Inc. +Copyright (C) 2012, 2013, 2016, 2017 g10 Code GmbH + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. The text of the + license can be found in the section entitled "GNU General Public + License". + +* Menu: + +* Introduction:: What is Libgcrypt. +* Preparation:: What you should do before using the library. +* Generalities:: General library functions and data types. +* Handler Functions:: Working with handler functions. +* Symmetric cryptography:: How to use symmetric cryptography. +* Public Key cryptography:: How to use public key cryptography. +* Hashing:: How to use hash algorithms. +* Message Authentication Codes:: How to use MAC algorithms. +* Key Derivation:: How to derive keys from strings +* Random Numbers:: How to work with random numbers. +* S-expressions:: How to manage S-expressions. +* MPI library:: How to work with multi-precision-integers. +* Prime numbers:: How to use the Prime number related functions. +* Utilities:: Utility functions. +* Tools:: Utility tools. +* Configuration:: Configuration files and environment variables. +* Architecture:: How Libgcrypt works internally. + +Appendices + +* Self-Tests:: Description of the self-tests. +* FIPS Mode:: Description of the FIPS mode. +* Library Copying:: The GNU Lesser General Public License + says how you can copy and share Libgcrypt. +* Copying:: The GNU General Public License says how you + can copy and share some parts of Libgcrypt. + +Indices + +* Figures and Tables:: Index of figures and tables. +* Concept Index:: Index of concepts and programs. +* Function and Data Index:: Index of functions, variables and data types. + + +File: gcrypt.info, Node: Introduction, Next: Preparation, Prev: Top, Up: Top + +1 Introduction +************** + +Libgcrypt is a library providing cryptographic building blocks. + +* Menu: + +* Getting Started:: How to use this manual. +* Features:: A glance at Libgcrypt's features. +* Overview:: Overview about the library. + + +File: gcrypt.info, Node: Getting Started, Next: Features, Up: Introduction + +1.1 Getting Started +=================== + +This manual documents the Libgcrypt library application programming +interface (API). All functions and data types provided by the library +are explained. + +The reader is assumed to possess basic knowledge about applied +cryptography. + + This manual can be used in several ways. If read from the beginning +to the end, it gives a good introduction into the library and how it can +be used in an application. Forward references are included where +necessary. Later on, the manual can be used as a reference manual to +get just the information needed about any particular interface of the +library. Experienced programmers might want to start looking at the +examples at the end of the manual, and then only read up those parts of +the interface which are unclear. + + +File: gcrypt.info, Node: Features, Next: Overview, Prev: Getting Started, Up: Introduction + +1.2 Features +============ + +Libgcrypt might have a couple of advantages over other libraries doing a +similar job. + +It's Free Software + Anybody can use, modify, and redistribute it under the terms of the + GNU Lesser General Public License (*note Library Copying::). Note, + that some parts (which are in general not needed by applications) + are subject to the terms of the GNU General Public License (*note + Copying::); please see the README file of the distribution for of + list of these parts. + +It encapsulates the low level cryptography + Libgcrypt provides a high level interface to cryptographic building + blocks using an extensible and flexible API. + + +File: gcrypt.info, Node: Overview, Prev: Features, Up: Introduction + +1.3 Overview +============ + +The Libgcrypt library is fully thread-safe, where it makes sense to be +thread-safe. Not thread-safe are some cryptographic functions that +modify a certain context stored in handles. If the user really intents +to use such functions from different threads on the same handle, he has +to take care of the serialization of such functions himself. If not +described otherwise, every function is thread-safe. + + Libgcrypt depends on the library 'libgpg-error', which contains some +common code used by other GnuPG components. + + +File: gcrypt.info, Node: Preparation, Next: Generalities, Prev: Introduction, Up: Top + +2 Preparation +************* + +To use Libgcrypt, you have to perform some changes to your sources and +the build system. The necessary changes are small and explained in the +following sections. At the end of this chapter, it is described how the +library is initialized, and how the requirements of the library are +verified. + +* Menu: + +* Header:: What header file you need to include. +* Building sources:: How to build sources using the library. +* Building sources using Automake:: How to build sources with the help of Automake. +* Initializing the library:: How to initialize the library. +* Multi-Threading:: How Libgcrypt can be used in a MT environment. +* Enabling FIPS mode:: How to enable the FIPS mode. +* Hardware features:: How to disable hardware features. + + +File: gcrypt.info, Node: Header, Next: Building sources, Up: Preparation + +2.1 Header +========== + +All interfaces (data types and functions) of the library are defined in +the header file 'gcrypt.h'. You must include this in all source files +using the library, either directly or through some other header file, +like this: + + #include <gcrypt.h> + + The name space of Libgcrypt is 'gcry_*' for function and type names +and 'GCRY*' for other symbols. In addition the same name prefixes with +one prepended underscore are reserved for internal use and should never +be used by an application. Note that Libgcrypt uses libgpg-error, which +uses 'gpg_*' as name space for function and type names and 'GPG_*' for +other symbols, including all the error codes. + +Certain parts of gcrypt.h may be excluded by defining these macros: + +'GCRYPT_NO_MPI_MACROS' + Do not define the shorthand macros 'mpi_*' for 'gcry_mpi_*'. + +'GCRYPT_NO_DEPRECATED' + Do not include definitions for deprecated features. This is useful + to make sure that no deprecated features are used. + + +File: gcrypt.info, Node: Building sources, Next: Building sources using Automake, Prev: Header, Up: Preparation + +2.2 Building sources +==================== + +If you want to compile a source file including the 'gcrypt.h' header +file, you must make sure that the compiler can find it in the directory +hierarchy. This is accomplished by adding the path to the directory in +which the header file is located to the compilers include file search +path (via the '-I' option). + + However, the path to the include file is determined at the time the +source is configured. To solve this problem, Libgcrypt ships with a +small helper program 'libgcrypt-config' that knows the path to the +include file and other configuration options. The options that need to +be added to the compiler invocation at compile time are output by the +'--cflags' option to 'libgcrypt-config'. The following example shows +how it can be used at the command line: + + gcc -c foo.c `libgcrypt-config --cflags` + + Adding the output of 'libgcrypt-config --cflags' to the compiler’s +command line will ensure that the compiler can find the Libgcrypt header +file. + + A similar problem occurs when linking the program with the library. +Again, the compiler has to find the library files. For this to work, +the path to the library files has to be added to the library search path +(via the '-L' option). For this, the option '--libs' to +'libgcrypt-config' can be used. For convenience, this option also +outputs all other options that are required to link the program with the +Libgcrypt libraries (in particular, the '-lgcrypt' option). The example +shows how to link 'foo.o' with the Libgcrypt library to a program 'foo'. + + gcc -o foo foo.o `libgcrypt-config --libs` + + Of course you can also combine both examples to a single command by +specifying both options to 'libgcrypt-config': + + gcc -o foo foo.c `libgcrypt-config --cflags --libs` + + +File: gcrypt.info, Node: Building sources using Automake, Next: Initializing the library, Prev: Building sources, Up: Preparation + +2.3 Building sources using Automake +=================================== + +It is much easier if you use GNU Automake instead of writing your own +Makefiles. If you do that, you do not have to worry about finding and +invoking the 'libgcrypt-config' script at all. Libgcrypt provides an +extension to Automake that does all the work for you. + + -- Macro: AM_PATH_LIBGCRYPT ([MINIMUM-VERSION], [ACTION-IF-FOUND], + [ACTION-IF-NOT-FOUND]) + Check whether Libgcrypt (at least version MINIMUM-VERSION, if + given) exists on the host system. If it is found, execute + ACTION-IF-FOUND, otherwise do ACTION-IF-NOT-FOUND, if given. + + Additionally, the function defines 'LIBGCRYPT_CFLAGS' to the flags + needed for compilation of the program to find the 'gcrypt.h' header + file, and 'LIBGCRYPT_LIBS' to the linker flags needed to link the + program to the Libgcrypt library. If the used helper script does + not match the target type you are building for a warning is printed + and the string 'libgcrypt' is appended to the variable + 'gpg_config_script_warn'. + + This macro searches for 'libgcrypt-config' along the PATH. If you + are cross-compiling, it is useful to set the environment variable + 'SYSROOT' to the top directory of your target. The macro will then + first look for the helper program in the 'bin' directory below that + top directory. An absolute directory name must be used for + 'SYSROOT'. Finally, if the configure command line option + '--with-libgcrypt-prefix' is used, only its value is used for the + top directory below which the helper script is expected. + + You can use the defined Autoconf variables like this in your +'Makefile.am': + + AM_CPPFLAGS = $(LIBGCRYPT_CFLAGS) + LDADD = $(LIBGCRYPT_LIBS) + + +File: gcrypt.info, Node: Initializing the library, Next: Multi-Threading, Prev: Building sources using Automake, Up: Preparation + +2.4 Initializing the library +============================ + +Before the library can be used, it must initialize itself. This is +achieved by invoking the function 'gcry_check_version' described below. + + Also, it is often desirable to check that the version of Libgcrypt +used is indeed one which fits all requirements. Even with binary +compatibility, new features may have been introduced, but due to problem +with the dynamic linker an old version may actually be used. So you may +want to check that the version is okay right after program startup. + + -- Function: const char * gcry_check_version (const char *REQ_VERSION) + + The function 'gcry_check_version' initializes some subsystems used + by Libgcrypt and must be invoked before any other function in the + library. *Note Multi-Threading::. + + Furthermore, this function returns the version number of the + library. It can also verify that the version number is higher than + a certain required version number REQ_VERSION, if this value is not + a null pointer. + + Libgcrypt uses a concept known as secure memory, which is a region of +memory set aside for storing sensitive data. Because such memory is a +scarce resource, it needs to be setup in advanced to a fixed size. +Further, most operating systems have special requirements on how that +secure memory can be used. For example, it might be required to install +an application as "setuid(root)" to allow allocating such memory. +Libgcrypt requires a sequence of initialization steps to make sure that +this works correctly. The following examples show the necessary steps. + + If you don't have a need for secure memory, for example if your +application does not use secret keys or other confidential data or it +runs in a controlled environment where key material floating around in +memory is not a problem, you should initialize Libgcrypt this way: + + /* Version check should be the very first call because it + makes sure that important subsystems are initialized. + #define NEED_LIBGCRYPT_VERSION to the minimum required version. */ + if (!gcry_check_version (NEED_LIBGCRYPT_VERSION)) + { + fprintf (stderr, "libgcrypt is too old (need %s, have %s)\n", + NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL)); + exit (2); + } + + /* Disable secure memory. */ + gcry_control (GCRYCTL_DISABLE_SECMEM, 0); + + /* ... If required, other initialization goes here. */ + + /* Tell Libgcrypt that initialization has completed. */ + gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); + + If you have to protect your keys or other information in memory +against being swapped out to disk and to enable an automatic overwrite +of used and freed memory, you need to initialize Libgcrypt this way: + + /* Version check should be the very first call because it + makes sure that important subsystems are initialized. + #define NEED_LIBGCRYPT_VERSION to the minimum required version. */ + if (!gcry_check_version (NEED_LIBGCRYPT_VERSION)) + { + fprintf (stderr, "libgcrypt is too old (need %s, have %s)\n", + NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL)); + exit (2); + } + + /* We don't want to see any warnings, e.g. because we have not yet + parsed program options which might be used to suppress such + warnings. */ + gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); + + /* ... If required, other initialization goes here. Note that the + process might still be running with increased privileges and that + the secure memory has not been initialized. */ + + /* Allocate a pool of 16k secure memory. This makes the secure memory + available and also drops privileges where needed. Note that by + using functions like gcry_xmalloc_secure and gcry_mpi_snew Libgcrypt + may expand the secure memory pool with memory which lacks the + property of not being swapped out to disk. */ + gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); + + /* It is now okay to let Libgcrypt complain when there was/is + a problem with the secure memory. */ + gcry_control (GCRYCTL_RESUME_SECMEM_WARN); + + /* ... If required, other initialization goes here. */ + + /* Tell Libgcrypt that initialization has completed. */ + gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); + + It is important that these initialization steps are not done by a +library but by the actual application. A library using Libgcrypt might +want to check for finished initialization using: + + if (!gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P)) + { + fputs ("libgcrypt has not been initialized\n", stderr); + abort (); + } + + Instead of terminating the process, the library may instead print a +warning and try to initialize Libgcrypt itself. See also the section on +multi-threading below for more pitfalls. + + +File: gcrypt.info, Node: Multi-Threading, Next: Enabling FIPS mode, Prev: Initializing the library, Up: Preparation + +2.5 Multi-Threading +=================== + +As mentioned earlier, the Libgcrypt library is thread-safe if you adhere +to the following requirements: + + * If you use pthread and your applications forks and does not + directly call exec (even calling stdio functions), all kind of + problems may occur. Future versions of Libgcrypt will try to + cleanup using pthread_atfork but even that may lead to problems. + This is a common problem with almost all applications using pthread + and fork. + + * The function 'gcry_check_version' must be called before any other + function in the library. To achieve this in multi-threaded + programs, you must synchronize the memory with respect to other + threads that also want to use Libgcrypt. For this, it is + sufficient to call 'gcry_check_version' before creating the other + threads using Libgcrypt(1). + + * Just like the function 'gpg_strerror', the function 'gcry_strerror' + is not thread safe. You have to use 'gpg_strerror_r' instead. + + ---------- Footnotes ---------- + + (1) At least this is true for POSIX threads, as 'pthread_create' is a +function that synchronizes memory with respects to other threads. There +are many functions which have this property, a complete list can be +found in POSIX, IEEE Std 1003.1-2003, Base Definitions, Issue 6, in the +definition of the term "Memory Synchronization". For other thread +packages, more relaxed or more strict rules may apply. + + +File: gcrypt.info, Node: Enabling FIPS mode, Next: Hardware features, Prev: Multi-Threading, Up: Preparation + +2.6 How to enable the FIPS mode +=============================== + +Libgcrypt may be used in a FIPS 140-2 mode. Note, that this does not +necessary mean that Libcgrypt is an appoved FIPS 140-2 module. Check +the NIST database at <http://csrc.nist.gov/groups/STM/cmvp/> to see what +versions of Libgcrypt are approved. + + Because FIPS 140 has certain restrictions on the use of cryptography +which are not always wanted, Libgcrypt needs to be put into FIPS mode +explicitly. Three alternative mechanisms are provided to switch +Libgcrypt into this mode: + + * If the file '/proc/sys/crypto/fips_enabled' exists and contains a + numeric value other than '0', Libgcrypt is put into FIPS mode at + initialization time. Obviously this works only on systems with a + 'proc' file system (i.e. GNU/Linux). + + * If the file '/etc/gcrypt/fips_enabled' exists, Libgcrypt is put + into FIPS mode at initialization time. Note that this filename is + hardwired and does not depend on any configuration options. + + * If the application requests FIPS mode using the control command + 'GCRYCTL_FORCE_FIPS_MODE'. This must be done prior to any + initialization (i.e. before 'gcry_check_version'). + + In addition to the standard FIPS mode, Libgcrypt may also be put into +an Enforced FIPS mode by writing a non-zero value into the file +'/etc/gcrypt/fips_enabled' or by using the control command +'GCRYCTL_SET_ENFORCED_FIPS_FLAG' before any other calls to libgcrypt. +The Enforced FIPS mode helps to detect applications which don't fulfill +all requirements for using Libgcrypt in FIPS mode (*note FIPS Mode::). + + Once Libgcrypt has been put into FIPS mode, it is not possible to +switch back to standard mode without terminating the process first. If +the logging verbosity level of Libgcrypt has been set to at least 2, the +state transitions and the self-tests are logged. + + +File: gcrypt.info, Node: Hardware features, Prev: Enabling FIPS mode, Up: Preparation + +2.7 How to disable hardware features +==================================== + +Libgcrypt makes use of certain hardware features. If the use of a +feature is not desired it may be either be disabled by a program or +globally using a configuration file. The currently supported features +are + +'padlock-rng' +'padlock-aes' +'padlock-sha' +'padlock-mmul' +'intel-cpu' +'intel-fast-shld' +'intel-bmi2' +'intel-ssse3' +'intel-sse4.1' +'intel-pclmul' +'intel-aesni' +'intel-rdrand' +'intel-avx' +'intel-avx2' +'intel-fast-vpgather' +'intel-rdtsc' +'intel-shaext' +'arm-neon' +'arm-aes' +'arm-sha1' +'arm-sha2' +'arm-pmull' + + To disable a feature for all processes using Libgcrypt 1.6 or newer, +create the file '/etc/gcrypt/hwf.deny' and put each feature not to be +used on a single line. Empty lines, white space, and lines prefixed +with a hash mark are ignored. The file should be world readable. + + To disable a feature specifically for a program that program must +tell it Libgcrypt before before calling 'gcry_check_version'. +Example:(1) + + gcry_control (GCRYCTL_DISABLE_HWF, "intel-rdrand", NULL); + +To print the list of active features you may use this command: + + mpicalc --print-config | grep ^hwflist: | tr : '\n' | tail -n +2 + + ---------- Footnotes ---------- + + (1) NB. Libgcrypt uses the RDRAND feature only as one source of +entropy. A CPU with a broken RDRAND will thus not compromise of the +random number generator + + +File: gcrypt.info, Node: Generalities, Next: Handler Functions, Prev: Preparation, Up: Top + +3 Generalities +************** + +* Menu: + +* Controlling the library:: Controlling Libgcrypt's behavior. +* Error Handling:: Error codes and such. + + +File: gcrypt.info, Node: Controlling the library, Next: Error Handling, Up: Generalities + +3.1 Controlling the library +=========================== + + -- Function: gcry_error_t gcry_control (enum gcry_ctl_cmds CMD, ...) + + This function can be used to influence the general behavior of + Libgcrypt in several ways. Depending on CMD, more arguments can or + have to be provided. + + 'GCRYCTL_ENABLE_M_GUARD; Arguments: none' + This command enables the built-in memory guard. It must not + be used to activate the memory guard after the memory + management has already been used; therefore it can ONLY be + used before 'gcry_check_version'. Note that the memory guard + is NOT used when the user of the library has set his own + memory management callbacks. + + 'GCRYCTL_ENABLE_QUICK_RANDOM; Arguments: none' + This command inhibits the use the very secure random quality + level ('GCRY_VERY_STRONG_RANDOM') and degrades all request + down to 'GCRY_STRONG_RANDOM'. In general this is not + recommended. However, for some applications the extra quality + random Libgcrypt tries to create is not justified and this + option may help to get better performance. Please check with + a crypto expert whether this option can be used for your + application. + + This option can only be used at initialization time. + + 'GCRYCTL_DUMP_RANDOM_STATS; Arguments: none' + This command dumps random number generator related statistics + to the library's logging stream. + + 'GCRYCTL_DUMP_MEMORY_STATS; Arguments: none' + This command dumps memory management related statistics to the + library's logging stream. + + 'GCRYCTL_DUMP_SECMEM_STATS; Arguments: none' + This command dumps secure memory management related statistics + to the library's logging stream. + + 'GCRYCTL_DROP_PRIVS; Arguments: none' + This command disables the use of secure memory and drops the + privileges of the current process. This command has not much + use; the suggested way to disable secure memory is to use + 'GCRYCTL_DISABLE_SECMEM' right after initialization. + + 'GCRYCTL_DISABLE_SECMEM; Arguments: none' + This command disables the use of secure memory. If this + command is used in FIPS mode, FIPS mode will be disabled and + the function 'gcry_fips_mode_active' returns false. However, + in Enforced FIPS mode this command has no effect at all. + + Many applications do not require secure memory, so they should + disable it right away. This command should be executed right + after 'gcry_check_version'. + + 'GCRYCTL_DISABLE_LOCKED_SECMEM; Arguments: none' + This command disables the use of the mlock call for secure + memory. Disabling the use of mlock may for example be done if + an encrypted swap space is in use. This command should be + executed right after 'gcry_check_version'. Note that by using + functions like gcry_xmalloc_secure and gcry_mpi_snew Libgcrypt + may expand the secure memory pool with memory which lacks the + property of not being swapped out to disk (but will still be + zeroed out on free). + + 'GCRYCTL_DISABLE_PRIV_DROP; Arguments: none' + This command sets a global flag to tell the secure memory + subsystem that it shall not drop privileges after secure + memory has been allocated. This command is commonly used + right after 'gcry_check_version' but may also be used right + away at program startup. It won't have an effect after the + secure memory pool has been initialized. WARNING: A process + running setuid(root) is a severe security risk. Processes + making use of Libgcrypt or other complex code should drop + these extra privileges as soon as possible. If this command + has been used the caller is responsible for dropping the + privileges. + + 'GCRYCTL_INIT_SECMEM; Arguments: unsigned int nbytes' + This command is used to allocate a pool of secure memory and + thus enabling the use of secure memory. It also drops all + extra privileges the process has (i.e. if it is run as setuid + (root)). If the argument NBYTES is 0, secure memory will be + disabled. The minimum amount of secure memory allocated is + currently 16384 bytes; you may thus use a value of 1 to + request that default size. + + 'GCRYCTL_AUTO_EXPAND_SECMEM; Arguments: unsigned int chunksize' + This command enables on-the-fly expanding of the secure memory + area. Note that by using functions like 'gcry_xmalloc_secure' + and 'gcry_mpi_snew' will do this auto expanding anyway. The + argument to this option is the suggested size for new secure + memory areas. A larger size improves performance of all + memory allocation and releasing functions. The given + chunksize is rounded up to the next 32KiB. The drawback of + auto expanding is that memory might be swapped out to disk; + this can be fixed by configuring the system to use an + encrypted swap space. + + 'GCRYCTL_TERM_SECMEM; Arguments: none' + This command zeroises the secure memory and destroys the + handler. The secure memory pool may not be used anymore after + running this command. If the secure memory pool as already + been destroyed, this command has no effect. Applications + might want to run this command from their exit handler to make + sure that the secure memory gets properly destroyed. This + command is not necessarily thread-safe but that should not be + needed in cleanup code. It may be called from a signal + handler. + + 'GCRYCTL_DISABLE_SECMEM_WARN; Arguments: none' + Disable warning messages about problems with the secure memory + subsystem. This command should be run right after + 'gcry_check_version'. + + 'GCRYCTL_SUSPEND_SECMEM_WARN; Arguments: none' + Postpone warning messages from the secure memory subsystem. + *Note the initialization example: sample-use-suspend-secmem, + on how to use it. + + 'GCRYCTL_RESUME_SECMEM_WARN; Arguments: none' + Resume warning messages from the secure memory subsystem. + *Note the initialization example: sample-use-resume-secmem, on + how to use it. + + 'GCRYCTL_USE_SECURE_RNDPOOL; Arguments: none' + This command tells the PRNG to store random numbers in secure + memory. This command should be run right after + 'gcry_check_version' and not later than the command + GCRYCTL_INIT_SECMEM. Note that in FIPS mode the secure memory + is always used. + + 'GCRYCTL_SET_RANDOM_SEED_FILE; Arguments: const char *filename' + This command specifies the file, which is to be used as seed + file for the PRNG. If the seed file is registered prior to + initialization of the PRNG, the seed file's content (if it + exists and seems to be valid) is fed into the PRNG pool. + After the seed file has been registered, the PRNG can be + signalled to write out the PRNG pool's content into the seed + file with the following command. + + 'GCRYCTL_UPDATE_RANDOM_SEED_FILE; Arguments: none' + Write out the PRNG pool's content into the registered seed + file. + + Multiple instances of the applications sharing the same random + seed file can be started in parallel, in which case they will + read out the same pool and then race for updating it (the last + update overwrites earlier updates). They will differentiate + only by the weak entropy that is added in read_seed_file based + on the PID and clock, and up to 16 bytes of weak random + non-blockingly. The consequence is that the output of these + different instances is correlated to some extent. In a + perfect attack scenario, the attacker can control (or at least + guess) the PID and clock of the application, and drain the + system's entropy pool to reduce the "up to 16 bytes" above to + 0. Then the dependencies of the initial states of the pools + are completely known. Note that this is not an issue if + random of 'GCRY_VERY_STRONG_RANDOM' quality is requested as in + this case enough extra entropy gets mixed. It is also not an + issue when using Linux (rndlinux driver), because this one + guarantees to read full 16 bytes from /dev/urandom and thus + there is no way for an attacker without kernel access to + control these 16 bytes. + + 'GCRYCTL_CLOSE_RANDOM_DEVICE; Arguments: none' + Try to close the random device. If on Unix system you call + fork(), the child process does no call exec(), and you do not + intend to use Libgcrypt in the child, it might be useful to + use this control code to close the inherited file descriptors + of the random device. If Libgcrypt is later used again by the + child, the device will be re-opened. On non-Unix systems this + control code is ignored. + + 'GCRYCTL_SET_VERBOSITY; Arguments: int level' + This command sets the verbosity of the logging. A level of 0 + disables all extra logging whereas positive numbers enable + more verbose logging. The level may be changed at any time + but be aware that no memory synchronization is done so the + effect of this command might not immediately show up in other + threads. This command may even be used prior to + 'gcry_check_version'. + + 'GCRYCTL_SET_DEBUG_FLAGS; Arguments: unsigned int flags' + Set the debug flag bits as given by the argument. Be aware + that no memory synchronization is done so the effect of this + command might not immediately show up in other threads. The + debug flags are not considered part of the API and thus may + change without notice. As of now bit 0 enables debugging of + cipher functions and bit 1 debugging of + multi-precision-integers. This command may even be used prior + to 'gcry_check_version'. + + 'GCRYCTL_CLEAR_DEBUG_FLAGS; Arguments: unsigned int flags' + Set the debug flag bits as given by the argument. Be aware + that that no memory synchronization is done so the effect of + this command might not immediately show up in other threads. + This command may even be used prior to 'gcry_check_version'. + + 'GCRYCTL_DISABLE_INTERNAL_LOCKING; Arguments: none' + This command does nothing. It exists only for backward + compatibility. + + 'GCRYCTL_ANY_INITIALIZATION_P; Arguments: none' + This command returns true if the library has been basically + initialized. Such a basic initialization happens implicitly + with many commands to get certain internal subsystems running. + The common and suggested way to do this basic initialization + is by calling gcry_check_version. + + 'GCRYCTL_INITIALIZATION_FINISHED; Arguments: none' + This command tells the library that the application has + finished the initialization. + + 'GCRYCTL_INITIALIZATION_FINISHED_P; Arguments: none' + This command returns true if the command + GCRYCTL_INITIALIZATION_FINISHED has already been run. + + 'GCRYCTL_SET_THREAD_CBS; Arguments: struct ath_ops *ath_ops' + This command is obsolete since version 1.6. + + 'GCRYCTL_FAST_POLL; Arguments: none' + Run a fast random poll. + + 'GCRYCTL_SET_RNDEGD_SOCKET; Arguments: const char *filename' + This command may be used to override the default name of the + EGD socket to connect to. It may be used only during + initialization as it is not thread safe. Changing the socket + name again is not supported. The function may return an error + if the given filename is too long for a local socket name. + + EGD is an alternative random gatherer, used only on systems + lacking a proper random device. + + 'GCRYCTL_PRINT_CONFIG; Arguments: FILE *stream' + This command dumps information pertaining to the configuration + of the library to the given stream. If NULL is given for + STREAM, the log system is used. This command may be used + before the initialization has been finished but not before a + 'gcry_check_version'. Note that the macro 'estream_t' can be + used instead of 'gpgrt_stream_t'. + + 'GCRYCTL_OPERATIONAL_P; Arguments: none' + This command returns true if the library is in an operational + state. This information makes only sense in FIPS mode. In + contrast to other functions, this is a pure test function and + won't put the library into FIPS mode or change the internal + state. This command may be used before the initialization has + been finished but not before a 'gcry_check_version'. + + 'GCRYCTL_FIPS_MODE_P; Arguments: none' + This command returns true if the library is in FIPS mode. + Note, that this is no indication about the current state of + the library. This command may be used before the + initialization has been finished but not before a + 'gcry_check_version'. An application may use this command or + the convenience macro below to check whether FIPS mode is + actually active. + + -- Function: int gcry_fips_mode_active (void) + + Returns true if the FIPS mode is active. Note that this + is implemented as a macro. + + 'GCRYCTL_FORCE_FIPS_MODE; Arguments: none' + Running this command puts the library into FIPS mode. If the + library is already in FIPS mode, a self-test is triggered and + thus the library will be put into operational state. This + command may be used before a call to 'gcry_check_version' and + that is actually the recommended way to let an application + switch the library into FIPS mode. Note that Libgcrypt will + reject an attempt to switch to fips mode during or after the + initialization. + + 'GCRYCTL_SET_ENFORCED_FIPS_FLAG; Arguments: none' + Running this command sets the internal flag that puts the + library into the enforced FIPS mode during the FIPS mode + initialization. This command does not affect the library if + the library is not put into the FIPS mode and it must be used + before any other libgcrypt library calls that initialize the + library such as 'gcry_check_version'. Note that Libgcrypt + will reject an attempt to switch to the enforced fips mode + during or after the initialization. + + 'GCRYCTL_SET_PREFERRED_RNG_TYPE; Arguments: int' + These are advisory commands to select a certain random number + generator. They are only advisory because libraries may not + know what an application actually wants or vice versa. Thus + Libgcrypt employs a priority check to select the actually used + RNG. If an applications selects a lower priority RNG but a + library requests a higher priority RNG Libgcrypt will switch + to the higher priority RNG. Applications and libraries should + use these control codes before 'gcry_check_version'. The + available generators are: + 'GCRY_RNG_TYPE_STANDARD' + A conservative standard generator based on the + "Continuously Seeded Pseudo Random Number Generator" + designed by Peter Gutmann. + 'GCRY_RNG_TYPE_FIPS' + A deterministic random number generator conforming to he + document "NIST-Recommended Random Number Generator Based + on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES + and AES Algorithms" (2005-01-31). This implementation + uses the AES variant. + 'GCRY_RNG_TYPE_SYSTEM' + A wrapper around the system's native RNG. On Unix system + these are usually the /dev/random and /dev/urandom + devices. + The default is 'GCRY_RNG_TYPE_STANDARD' unless FIPS mode as + been enabled; in which case 'GCRY_RNG_TYPE_FIPS' is used and + locked against further changes. + + 'GCRYCTL_GET_CURRENT_RNG_TYPE; Arguments: int *' + This command stores the type of the currently used RNG as an + integer value at the provided address. + + 'GCRYCTL_SELFTEST; Arguments: none' + This may be used at anytime to have the library run all + implemented self-tests. It works in standard and in FIPS + mode. Returns 0 on success or an error code on failure. + + 'GCRYCTL_DISABLE_HWF; Arguments: const char *name' + + Libgcrypt detects certain features of the CPU at startup time. + For performance tests it is sometimes required not to use such + a feature. This option may be used to disable a certain + feature; i.e. Libgcrypt behaves as if this feature has not + been detected. This call can be used several times to disable + a set of features, or features may be given as a colon or + comma delimited string. The special feature "all" can be used + to disable all available features. + + Note that the detection code might be run if the feature has + been disabled. This command must be used at initialization + time; i.e. before calling 'gcry_check_version'. + + 'GCRYCTL_REINIT_SYSCALL_CLAMP; Arguments: none' + + Libgcrypt wraps blocking system calls with two functions calls + ("system call clamp") to give user land threading libraries a + hook for re-scheduling. This works by reading the system call + clamp from Libgpg-error at initialization time. However + sometimes Libgcrypt needs to be initialized before the user + land threading systems and at that point the system call clamp + has not been registered with Libgpg-error and in turn + Libgcrypt would not use them. The control code can be used to + tell Libgcrypt that a system call clamp has now been + registered with Libgpg-error and advise Libgcrypt to read the + clamp again. Obviously this control code may only be used + before a second thread is started in a process. + + +File: gcrypt.info, Node: Error Handling, Prev: Controlling the library, Up: Generalities + +3.2 Error Handling +================== + +Many functions in Libgcrypt can return an error if they fail. For this +reason, the application should always catch the error condition and take +appropriate measures, for example by releasing the resources and passing +the error up to the caller, or by displaying a descriptive message to +the user and cancelling the operation. + + Some error values do not indicate a system error or an error in the +operation, but the result of an operation that failed properly. For +example, if you try to decrypt a tempered message, the decryption will +fail. Another error value actually means that the end of a data buffer +or list has been reached. The following descriptions explain for many +error codes what they mean usually. Some error values have specific +meanings if returned by a certain functions. Such cases are described +in the documentation of those functions. + + Libgcrypt uses the 'libgpg-error' library. This allows to share the +error codes with other components of the GnuPG system, and to pass error +values transparently from the crypto engine, or some helper application +of the crypto engine, to the user. This way no information is lost. As +a consequence, Libgcrypt does not use its own identifiers for error +codes, but uses those provided by 'libgpg-error'. They usually start +with 'GPG_ERR_'. + + However, Libgcrypt does provide aliases for the functions defined in +libgpg-error, which might be preferred for name space consistency. + + Most functions in Libgcrypt return an error code in the case of +failure. For this reason, the application should always catch the error +condition and take appropriate measures, for example by releasing the +resources and passing the error up to the caller, or by displaying a +descriptive message to the user and canceling the operation. + + Some error values do not indicate a system error or an error in the +operation, but the result of an operation that failed properly. + + GnuPG components, including Libgcrypt, use an extra library named +libgpg-error to provide a common error handling scheme. For more +information on libgpg-error, see the according manual. + +* Menu: + +* Error Values:: The error value and what it means. +* Error Sources:: A list of important error sources. +* Error Codes:: A list of important error codes. +* Error Strings:: How to get a descriptive string from a value. + + +File: gcrypt.info, Node: Error Values, Next: Error Sources, Up: Error Handling + +3.2.1 Error Values +------------------ + + -- Data type: gcry_err_code_t + The 'gcry_err_code_t' type is an alias for the 'libgpg-error' type + 'gpg_err_code_t'. The error code indicates the type of an error, + or the reason why an operation failed. + + A list of important error codes can be found in the next section. + + -- Data type: gcry_err_source_t + The 'gcry_err_source_t' type is an alias for the 'libgpg-error' + type 'gpg_err_source_t'. The error source has not a precisely + defined meaning. Sometimes it is the place where the error + happened, sometimes it is the place where an error was encoded into + an error value. Usually the error source will give an indication + to where to look for the problem. This is not always true, but it + is attempted to achieve this goal. + + A list of important error sources can be found in the next section. + + -- Data type: gcry_error_t + The 'gcry_error_t' type is an alias for the 'libgpg-error' type + 'gpg_error_t'. An error value like this has always two components, + an error code and an error source. Both together form the error + value. + + Thus, the error value can not be directly compared against an error + code, but the accessor functions described below must be used. + However, it is guaranteed that only 0 is used to indicate success + ('GPG_ERR_NO_ERROR'), and that in this case all other parts of the + error value are set to 0, too. + + Note that in Libgcrypt, the error source is used purely for + diagnostic purposes. Only the error code should be checked to test + for a certain outcome of a function. The manual only documents the + error code part of an error value. The error source is left + unspecified and might be anything. + + -- Function: gcry_err_code_t gcry_err_code (gcry_error_t ERR) + The static inline function 'gcry_err_code' returns the + 'gcry_err_code_t' component of the error value ERR. This function + must be used to extract the error code from an error value in order + to compare it with the 'GPG_ERR_*' error code macros. + + -- Function: gcry_err_source_t gcry_err_source (gcry_error_t ERR) + The static inline function 'gcry_err_source' returns the + 'gcry_err_source_t' component of the error value ERR. This + function must be used to extract the error source from an error + value in order to compare it with the 'GPG_ERR_SOURCE_*' error + source macros. + + -- Function: gcry_error_t gcry_err_make (gcry_err_source_t SOURCE, + gcry_err_code_t CODE) + The static inline function 'gcry_err_make' returns the error value + consisting of the error source SOURCE and the error code CODE. + + This function can be used in callback functions to construct an + error value to return it to the library. + + -- Function: gcry_error_t gcry_error (gcry_err_code_t CODE) + The static inline function 'gcry_error' returns the error value + consisting of the default error source and the error code CODE. + + For GCRY applications, the default error source is + 'GPG_ERR_SOURCE_USER_1'. You can define 'GCRY_ERR_SOURCE_DEFAULT' + before including 'gcrypt.h' to change this default. + + This function can be used in callback functions to construct an + error value to return it to the library. + + The 'libgpg-error' library provides error codes for all system error +numbers it knows about. If ERR is an unknown error number, the error +code 'GPG_ERR_UNKNOWN_ERRNO' is used. The following functions can be +used to construct error values from system errno numbers. + + -- Function: gcry_error_t gcry_err_make_from_errno + (gcry_err_source_t SOURCE, int ERR) + The function 'gcry_err_make_from_errno' is like 'gcry_err_make', + but it takes a system error like 'errno' instead of a + 'gcry_err_code_t' error code. + + -- Function: gcry_error_t gcry_error_from_errno (int ERR) + The function 'gcry_error_from_errno' is like 'gcry_error', but it + takes a system error like 'errno' instead of a 'gcry_err_code_t' + error code. + + Sometimes you might want to map system error numbers to error codes +directly, or map an error code representing a system error back to the +system error number. The following functions can be used to do that. + + -- Function: gcry_err_code_t gcry_err_code_from_errno (int ERR) + The function 'gcry_err_code_from_errno' returns the error code for + the system error ERR. If ERR is not a known system error, the + function returns 'GPG_ERR_UNKNOWN_ERRNO'. + + -- Function: int gcry_err_code_to_errno (gcry_err_code_t ERR) + The function 'gcry_err_code_to_errno' returns the system error for + the error code ERR. If ERR is not an error code representing a + system error, or if this system error is not defined on this + system, the function returns '0'. + + +File: gcrypt.info, Node: Error Sources, Next: Error Codes, Prev: Error Values, Up: Error Handling + +3.2.2 Error Sources +------------------- + +The library 'libgpg-error' defines an error source for every component +of the GnuPG system. The error source part of an error value is not +well defined. As such it is mainly useful to improve the diagnostic +error message for the user. + + If the error code part of an error value is '0', the whole error +value will be '0'. In this case the error source part is of course +'GPG_ERR_SOURCE_UNKNOWN'. + + The list of error sources that might occur in applications using +Libgcrypt is: + +'GPG_ERR_SOURCE_UNKNOWN' + The error source is not known. The value of this error source is + '0'. + +'GPG_ERR_SOURCE_GPGME' + The error source is GPGME itself. + +'GPG_ERR_SOURCE_GPG' + The error source is GnuPG, which is the crypto engine used for the + OpenPGP protocol. + +'GPG_ERR_SOURCE_GPGSM' + The error source is GPGSM, which is the crypto engine used for the + OpenPGP protocol. + +'GPG_ERR_SOURCE_GCRYPT' + The error source is 'libgcrypt', which is used by crypto engines to + perform cryptographic operations. + +'GPG_ERR_SOURCE_GPGAGENT' + The error source is 'gpg-agent', which is used by crypto engines to + perform operations with the secret key. + +'GPG_ERR_SOURCE_PINENTRY' + The error source is 'pinentry', which is used by 'gpg-agent' to + query the passphrase to unlock a secret key. + +'GPG_ERR_SOURCE_SCD' + The error source is the SmartCard Daemon, which is used by + 'gpg-agent' to delegate operations with the secret key to a + SmartCard. + +'GPG_ERR_SOURCE_KEYBOX' + The error source is 'libkbx', a library used by the crypto engines + to manage local keyrings. + +'GPG_ERR_SOURCE_USER_1' +'GPG_ERR_SOURCE_USER_2' +'GPG_ERR_SOURCE_USER_3' +'GPG_ERR_SOURCE_USER_4' + These error sources are not used by any GnuPG component and can be + used by other software. For example, applications using Libgcrypt + can use them to mark error values coming from callback handlers. + Thus 'GPG_ERR_SOURCE_USER_1' is the default for errors created with + 'gcry_error' and 'gcry_error_from_errno', unless you define + 'GCRY_ERR_SOURCE_DEFAULT' before including 'gcrypt.h'. + + +File: gcrypt.info, Node: Error Codes, Next: Error Strings, Prev: Error Sources, Up: Error Handling + +3.2.3 Error Codes +----------------- + +The library 'libgpg-error' defines many error values. The following +list includes the most important error codes. + +'GPG_ERR_EOF' + This value indicates the end of a list, buffer or file. + +'GPG_ERR_NO_ERROR' + This value indicates success. The value of this error code is '0'. + Also, it is guaranteed that an error value made from the error code + '0' will be '0' itself (as a whole). This means that the error + source information is lost for this error code, however, as this + error code indicates that no error occurred, this is generally not + a problem. + +'GPG_ERR_GENERAL' + This value means that something went wrong, but either there is not + enough information about the problem to return a more useful error + value, or there is no separate error value for this type of + problem. + +'GPG_ERR_ENOMEM' + This value means that an out-of-memory condition occurred. + +'GPG_ERR_E...' + System errors are mapped to GPG_ERR_EFOO where FOO is the symbol + for the system error. + +'GPG_ERR_INV_VALUE' + This value means that some user provided data was out of range. + +'GPG_ERR_UNUSABLE_PUBKEY' + This value means that some recipients for a message were invalid. + +'GPG_ERR_UNUSABLE_SECKEY' + This value means that some signers were invalid. + +'GPG_ERR_NO_DATA' + This value means that data was expected where no data was found. + +'GPG_ERR_CONFLICT' + This value means that a conflict of some sort occurred. + +'GPG_ERR_NOT_IMPLEMENTED' + This value indicates that the specific function (or operation) is + not implemented. This error should never happen. It can only + occur if you use certain values or configuration options which do + not work, but for which we think that they should work at some + later time. + +'GPG_ERR_DECRYPT_FAILED' + This value indicates that a decryption operation was unsuccessful. + +'GPG_ERR_WRONG_KEY_USAGE' + This value indicates that a key is not used appropriately. + +'GPG_ERR_NO_SECKEY' + This value indicates that no secret key for the user ID is + available. + +'GPG_ERR_UNSUPPORTED_ALGORITHM' + This value means a verification failed because the cryptographic + algorithm is not supported by the crypto backend. + +'GPG_ERR_BAD_SIGNATURE' + This value means a verification failed because the signature is + bad. + +'GPG_ERR_NO_PUBKEY' + This value means a verification failed because the public key is + not available. + +'GPG_ERR_NOT_OPERATIONAL' + This value means that the library is not yet in state which allows + to use this function. This error code is in particular returned if + Libgcrypt is operated in FIPS mode and the internal state of the + library does not yet or not anymore allow the use of a service. + + This error code is only available with newer libgpg-error versions, + thus you might see "invalid error code" when passing this to + 'gpg_strerror'. The numeric value of this error code is 176. + +'GPG_ERR_USER_1' +'GPG_ERR_USER_2' +'...' +'GPG_ERR_USER_16' + These error codes are not used by any GnuPG component and can be + freely used by other software. Applications using Libgcrypt might + use them to mark specific errors returned by callback handlers if + no suitable error codes (including the system errors) for these + errors exist already. + + +File: gcrypt.info, Node: Error Strings, Prev: Error Codes, Up: Error Handling + +3.2.4 Error Strings +------------------- + + -- Function: const char * gcry_strerror (gcry_error_t ERR) + The function 'gcry_strerror' returns a pointer to a statically + allocated string containing a description of the error code + contained in the error value ERR. This string can be used to + output a diagnostic message to the user. + + -- Function: const char * gcry_strsource (gcry_error_t ERR) + The function 'gcry_strsource' returns a pointer to a statically + allocated string containing a description of the error source + contained in the error value ERR. This string can be used to + output a diagnostic message to the user. + + The following example illustrates the use of the functions described +above: + + { + gcry_cipher_hd_t handle; + gcry_error_t err = 0; + + err = gcry_cipher_open (&handle, GCRY_CIPHER_AES, + GCRY_CIPHER_MODE_CBC, 0); + if (err) + { + fprintf (stderr, "Failure: %s/%s\n", + gcry_strsource (err), + gcry_strerror (err)); + } + } + + +File: gcrypt.info, Node: Handler Functions, Next: Symmetric cryptography, Prev: Generalities, Up: Top + +4 Handler Functions +******************* + +Libgcrypt makes it possible to install so called 'handler functions', +which get called by Libgcrypt in case of certain events. + +* Menu: + +* Progress handler:: Using a progress handler function. +* Allocation handler:: Using special memory allocation functions. +* Error handler:: Using error handler functions. +* Logging handler:: Using a special logging function. + + +File: gcrypt.info, Node: Progress handler, Next: Allocation handler, Up: Handler Functions + +4.1 Progress handler +==================== + +It is often useful to retrieve some feedback while long running +operations are performed. + + -- Data type: gcry_handler_progress_t + Progress handler functions have to be of the type + 'gcry_handler_progress_t', which is defined as: + + 'void (*gcry_handler_progress_t) (void *, const char *, int, int, + int)' + + The following function may be used to register a handler function for +this purpose. + + -- Function: void gcry_set_progress_handler (gcry_handler_progress_t + CB, void *CB_DATA) + + This function installs CB as the 'Progress handler' function. It + may be used only during initialization. CB must be defined as + follows: + + void + my_progress_handler (void *CB_DATA, const char *WHAT, + int PRINTCHAR, int CURRENT, int TOTAL) + { + /* Do something. */ + } + + A description of the arguments of the progress handler function + follows. + + CB_DATA + The argument provided in the call to + 'gcry_set_progress_handler'. + WHAT + A string identifying the type of the progress output. The + following values for WHAT are defined: + + 'need_entropy' + Not enough entropy is available. TOTAL holds the number + of required bytes. + + 'wait_dev_random' + Waiting to re-open a random device. TOTAL gives the + number of seconds until the next try. + + 'primegen' + Values for PRINTCHAR: + '\n' + Prime generated. + '!' + Need to refresh the pool of prime numbers. + '<, >' + Number of bits adjusted. + '^' + Searching for a generator. + '.' + Fermat test on 10 candidates failed. + ':' + Restart with a new random value. + '+' + Rabin Miller test passed. + + +File: gcrypt.info, Node: Allocation handler, Next: Error handler, Prev: Progress handler, Up: Handler Functions + +4.2 Allocation handler +====================== + +It is possible to make Libgcrypt use special memory allocation functions +instead of the built-in ones. + + Memory allocation functions are of the following types: + -- Data type: gcry_handler_alloc_t + This type is defined as: 'void *(*gcry_handler_alloc_t) (size_t + n)'. + -- Data type: gcry_handler_secure_check_t + This type is defined as: 'int *(*gcry_handler_secure_check_t) + (const void *)'. + -- Data type: gcry_handler_realloc_t + This type is defined as: 'void *(*gcry_handler_realloc_t) (void *p, + size_t n)'. + -- Data type: gcry_handler_free_t + This type is defined as: 'void *(*gcry_handler_free_t) (void *)'. + + Special memory allocation functions can be installed with the +following function: + + -- Function: void gcry_set_allocation_handler (gcry_handler_alloc_t + FUNC_ALLOC, gcry_handler_alloc_t FUNC_ALLOC_SECURE, + gcry_handler_secure_check_t FUNC_SECURE_CHECK, + gcry_handler_realloc_t FUNC_REALLOC, gcry_handler_free_t + FUNC_FREE) + Install the provided functions and use them instead of the built-in + functions for doing memory allocation. Using this function is in + general not recommended because the standard Libgcrypt allocation + functions are guaranteed to zeroize memory if needed. + + This function may be used only during initialization and may not be + used in fips mode. + + +File: gcrypt.info, Node: Error handler, Next: Logging handler, Prev: Allocation handler, Up: Handler Functions + +4.3 Error handler +================= + +The following functions may be used to register handler functions that +are called by Libgcrypt in case certain error conditions occur. They +may and should be registered prior to calling 'gcry_check_version'. + + -- Data type: gcry_handler_no_mem_t + This type is defined as: 'int (*gcry_handler_no_mem_t) (void *, + size_t, unsigned int)' + -- Function: void gcry_set_outofcore_handler (gcry_handler_no_mem_t + FUNC_NO_MEM, void *CB_DATA) + This function registers FUNC_NO_MEM as 'out-of-core handler', which + means that it will be called in the case of not having enough + memory available. The handler is called with 3 arguments: The + first one is the pointer CB_DATA as set with this function, the + second is the requested memory size and the last being a flag. If + bit 0 of the flag is set, secure memory has been requested. The + handler should either return true to indicate that Libgcrypt should + try again allocating memory or return false to let Libgcrypt use + its default fatal error handler. + + -- Data type: gcry_handler_error_t + This type is defined as: 'void (*gcry_handler_error_t) (void *, + int, const char *)' + + -- Function: void gcry_set_fatalerror_handler (gcry_handler_error_t + FUNC_ERROR, void *CB_DATA) + This function registers FUNC_ERROR as 'error handler', which means + that it will be called in error conditions. + + +File: gcrypt.info, Node: Logging handler, Prev: Error handler, Up: Handler Functions + +4.4 Logging handler +=================== + + -- Data type: gcry_handler_log_t + This type is defined as: 'void (*gcry_handler_log_t) (void *, int, + const char *, va_list)' + + -- Function: void gcry_set_log_handler (gcry_handler_log_t FUNC_LOG, + void *CB_DATA) + This function registers FUNC_LOG as 'logging handler', which means + that it will be called in case Libgcrypt wants to log a message. + This function may and should be used prior to calling + 'gcry_check_version'. + + +File: gcrypt.info, Node: Symmetric cryptography, Next: Public Key cryptography, Prev: Handler Functions, Up: Top + +5 Symmetric cryptography +************************ + +The cipher functions are used for symmetrical cryptography, i.e. +cryptography using a shared key. The programming model follows an +open/process/close paradigm and is in that similar to other building +blocks provided by Libgcrypt. + +* Menu: + +* Available ciphers:: List of ciphers supported by the library. +* Available cipher modes:: List of cipher modes supported by the library. +* Working with cipher handles:: How to perform operations related to cipher handles. +* General cipher functions:: General cipher functions independent of cipher handles. + + +File: gcrypt.info, Node: Available ciphers, Next: Available cipher modes, Up: Symmetric cryptography + +5.1 Available ciphers +===================== + +'GCRY_CIPHER_NONE' + This is not a real algorithm but used by some functions as error + return. The value always evaluates to false. + +'GCRY_CIPHER_IDEA' + This is the IDEA algorithm. + +'GCRY_CIPHER_3DES' + Triple-DES with 3 Keys as EDE. The key size of this algorithm is + 168 bits but you have to pass 192 bits because the most significant + bits of each byte are ignored. + +'GCRY_CIPHER_CAST5' + CAST128-5 block cipher algorithm. The key size is 128 bits. + +'GCRY_CIPHER_BLOWFISH' + The blowfish algorithm. The supported key sizes are 8 to 576 bits + in 8 bit increments. + +'GCRY_CIPHER_SAFER_SK128' + Reserved and not currently implemented. + +'GCRY_CIPHER_DES_SK' + Reserved and not currently implemented. + +'GCRY_CIPHER_AES' +'GCRY_CIPHER_AES128' +'GCRY_CIPHER_RIJNDAEL' +'GCRY_CIPHER_RIJNDAEL128' + AES (Rijndael) with a 128 bit key. + +'GCRY_CIPHER_AES192' +'GCRY_CIPHER_RIJNDAEL192' + AES (Rijndael) with a 192 bit key. + +'GCRY_CIPHER_AES256' +'GCRY_CIPHER_RIJNDAEL256' + AES (Rijndael) with a 256 bit key. + +'GCRY_CIPHER_TWOFISH' + The Twofish algorithm with a 256 bit key. + +'GCRY_CIPHER_TWOFISH128' + The Twofish algorithm with a 128 bit key. + +'GCRY_CIPHER_ARCFOUR' + An algorithm which is 100% compatible with RSA Inc.'s RC4 + algorithm. Note that this is a stream cipher and must be used very + carefully to avoid a couple of weaknesses. + +'GCRY_CIPHER_DES' + Standard DES with a 56 bit key. You need to pass 64 bit but the + high bits of each byte are ignored. Note, that this is a weak + algorithm which can be broken in reasonable time using a brute + force approach. + +'GCRY_CIPHER_SERPENT128' +'GCRY_CIPHER_SERPENT192' +'GCRY_CIPHER_SERPENT256' + The Serpent cipher from the AES contest. + +'GCRY_CIPHER_RFC2268_40' +'GCRY_CIPHER_RFC2268_128' + Ron's Cipher 2 in the 40 and 128 bit variants. + +'GCRY_CIPHER_SEED' + A 128 bit cipher as described by RFC4269. + +'GCRY_CIPHER_CAMELLIA128' +'GCRY_CIPHER_CAMELLIA192' +'GCRY_CIPHER_CAMELLIA256' + The Camellia cipher by NTT. See + <http://info.isl.ntt.co.jp/crypt/eng/camellia/specifications.html>. + +'GCRY_CIPHER_SALSA20' + This is the Salsa20 stream cipher. + +'GCRY_CIPHER_SALSA20R12' + This is the Salsa20/12 - reduced round version of Salsa20 stream + cipher. + +'GCRY_CIPHER_GOST28147' + The GOST 28147-89 cipher, defined in the respective GOST standard. + Translation of this GOST into English is provided in the RFC-5830. + +'GCRY_CIPHER_GOST28147_MESH' + The GOST 28147-89 cipher, defined in the respective GOST standard. + Translation of this GOST into English is provided in the RFC-5830. + This cipher will use CryptoPro keymeshing as defined in RFC 4357 if + it has to be used for the selected parameter set. + +'GCRY_CIPHER_CHACHA20' + This is the ChaCha20 stream cipher. + +'GCRY_CIPHER_SM4' + A 128 bit cipher by the State Cryptography Administration of China + (SCA). See <https://tools.ietf.org/html/draft-ribose-cfrg-sm4-10>. + + +File: gcrypt.info, Node: Available cipher modes, Next: Working with cipher handles, Prev: Available ciphers, Up: Symmetric cryptography + +5.2 Available cipher modes +========================== + +'GCRY_CIPHER_MODE_NONE' + No mode specified. This should not be used. The only exception is + that if Libgcrypt is not used in FIPS mode and if any debug flag + has been set, this mode may be used to bypass the actual + encryption. + +'GCRY_CIPHER_MODE_ECB' + Electronic Codebook mode. + +'GCRY_CIPHER_MODE_CFB' +'GCRY_CIPHER_MODE_CFB8' + Cipher Feedback mode. For GCRY_CIPHER_MODE_CFB the shift size + equals the block size of the cipher (e.g. for AES it is CFB-128). + For GCRY_CIPHER_MODE_CFB8 the shift size is 8 bit but that variant + is not yet available. + +'GCRY_CIPHER_MODE_CBC' + Cipher Block Chaining mode. + +'GCRY_CIPHER_MODE_STREAM' + Stream mode, only to be used with stream cipher algorithms. + +'GCRY_CIPHER_MODE_OFB' + Output Feedback mode. + +'GCRY_CIPHER_MODE_CTR' + Counter mode. + +'GCRY_CIPHER_MODE_AESWRAP' + This mode is used to implement the AES-Wrap algorithm according to + RFC-3394. It may be used with any 128 bit block length algorithm, + however the specs require one of the 3 AES algorithms. These + special conditions apply: If 'gcry_cipher_setiv' has not been used + the standard IV is used; if it has been used the lower 64 bit of + the IV are used as the Alternative Initial Value. On encryption + the provided output buffer must be 64 bit (8 byte) larger than the + input buffer; in-place encryption is still allowed. On decryption + the output buffer may be specified 64 bit (8 byte) shorter than + then input buffer. As per specs the input length must be at least + 128 bits and the length must be a multiple of 64 bits. + +'GCRY_CIPHER_MODE_CCM' + Counter with CBC-MAC mode is an Authenticated Encryption with + Associated Data (AEAD) block cipher mode, which is specified in + 'NIST Special Publication 800-38C' and RFC 3610. + +'GCRY_CIPHER_MODE_GCM' + Galois/Counter Mode (GCM) is an Authenticated Encryption with + Associated Data (AEAD) block cipher mode, which is specified in + 'NIST Special Publication 800-38D'. + +'GCRY_CIPHER_MODE_POLY1305' + This mode implements the Poly1305 Authenticated Encryption with + Associated Data (AEAD) mode according to RFC-8439. This mode can + be used with ChaCha20 stream cipher. + +'GCRY_CIPHER_MODE_OCB' + OCB is an Authenticated Encryption with Associated Data (AEAD) + block cipher mode, which is specified in RFC-7253. Supported tag + lengths are 128, 96, and 64 bit with the default being 128 bit. To + switch to a different tag length 'gcry_cipher_ctl' using the + command 'GCRYCTL_SET_TAGLEN' and the address of an 'int' variable + set to 12 (for 96 bit) or 8 (for 64 bit) provided for the 'buffer' + argument and 'sizeof(int)' for 'buflen'. + + Note that the use of 'gcry_cipher_final' is required. + +'GCRY_CIPHER_MODE_XTS' + XEX-based tweaked-codebook mode with ciphertext stealing (XTS) mode + is used to implement the AES-XTS as specified in IEEE 1619 Standard + Architecture for Encrypted Shared Storage Media and NIST SP800-38E. + + The XTS mode requires doubling key-length, for example, using + 512-bit key with AES-256 ('GCRY_CIPHER_AES256'). The 128-bit tweak + value is feed to XTS mode as little-endian byte array using + 'gcry_cipher_setiv' function. When encrypting or decrypting, + full-sized data unit buffers needs to be passed to + 'gcry_cipher_encrypt' or 'gcry_cipher_decrypt'. The tweak value is + automatically incremented after each call of 'gcry_cipher_encrypt' + and 'gcry_cipher_decrypt'. Auto-increment allows avoiding need of + setting IV between processing of sequential data units. + +'GCRY_CIPHER_MODE_EAX' + EAX is an Authenticated Encryption with Associated Data (AEAD) + block cipher mode by Bellare, Rogaway, and Wagner (see + <http://web.cs.ucdavis.edu/~rogaway/papers/eax.html>). + + +File: gcrypt.info, Node: Working with cipher handles, Next: General cipher functions, Prev: Available cipher modes, Up: Symmetric cryptography + +5.3 Working with cipher handles +=============================== + +To use a cipher algorithm, you must first allocate an according handle. +This is to be done using the open function: + + -- Function: gcry_error_t gcry_cipher_open (gcry_cipher_hd_t *HD, int + ALGO, int MODE, unsigned int FLAGS) + + This function creates the context handle required for most of the + other cipher functions and returns a handle to it in 'hd'. In case + of an error, an according error code is returned. + + The ID of algorithm to use must be specified via ALGO. See *note + Available ciphers::, for a list of supported ciphers and the + according constants. + + Besides using the constants directly, the function + 'gcry_cipher_map_name' may be used to convert the textual name of + an algorithm into the according numeric ID. + + The cipher mode to use must be specified via MODE. See *note + Available cipher modes::, for a list of supported cipher modes and + the according constants. Note that some modes are incompatible + with some algorithms - in particular, stream mode + ('GCRY_CIPHER_MODE_STREAM') only works with stream ciphers. + Poly1305 AEAD mode ('GCRY_CIPHER_MODE_POLY1305') only works with + ChaCha20 stream cipher. The block cipher modes + ('GCRY_CIPHER_MODE_ECB', 'GCRY_CIPHER_MODE_CBC', + 'GCRY_CIPHER_MODE_CFB', 'GCRY_CIPHER_MODE_OFB', + 'GCRY_CIPHER_MODE_CTR' and 'GCRY_CIPHER_MODE_EAX') will work with + any block cipher algorithm. GCM mode ('GCRY_CIPHER_MODE_CCM'), CCM + mode ('GCRY_CIPHER_MODE_GCM'), OCB mode ('GCRY_CIPHER_MODE_OCB'), + and XTS mode ('GCRY_CIPHER_MODE_XTS') will only work with block + cipher algorithms which have the block size of 16 bytes. + + The third argument FLAGS can either be passed as '0' or as the + bit-wise OR of the following constants. + + 'GCRY_CIPHER_SECURE' + Make sure that all operations are allocated in secure memory. + This is useful when the key material is highly confidential. + 'GCRY_CIPHER_ENABLE_SYNC' + This flag enables the CFB sync mode, which is a special + feature of Libgcrypt's CFB mode implementation to allow for + OpenPGP's CFB variant. See 'gcry_cipher_sync'. + 'GCRY_CIPHER_CBC_CTS' + Enable cipher text stealing (CTS) for the CBC mode. Cannot be + used simultaneous as GCRY_CIPHER_CBC_MAC. CTS mode makes it + possible to transform data of almost arbitrary size (only + limitation is that it must be greater than the algorithm's + block size). + 'GCRY_CIPHER_CBC_MAC' + Compute CBC-MAC keyed checksums. This is the same as CBC + mode, but only output the last block. Cannot be used + simultaneous as GCRY_CIPHER_CBC_CTS. + + Use the following function to release an existing handle: + + -- Function: void gcry_cipher_close (gcry_cipher_hd_t H) + + This function releases the context created by 'gcry_cipher_open'. + It also zeroises all sensitive information associated with this + cipher handle. + + In order to use a handle for performing cryptographic operations, a +'key' has to be set first: + + -- Function: gcry_error_t gcry_cipher_setkey (gcry_cipher_hd_t H, const + void *K, size_t L) + + Set the key K used for encryption or decryption in the context + denoted by the handle H. The length L (in bytes) of the key K must + match the required length of the algorithm set for this context or + be in the allowed range for algorithms with variable key size. The + function checks this and returns an error if there is a problem. A + caller should always check for an error. + + Most crypto modes requires an initialization vector (IV), which +usually is a non-secret random string acting as a kind of salt value. +The CTR mode requires a counter, which is also similar to a salt value. +To set the IV or CTR, use these functions: + + -- Function: gcry_error_t gcry_cipher_setiv (gcry_cipher_hd_t H, const + void *K, size_t L) + + Set the initialization vector used for encryption or decryption. + The vector is passed as the buffer K of length L bytes and copied + to internal data structures. The function checks that the IV + matches the requirement of the selected algorithm and mode. + + This function is also used by AEAD modes and with Salsa20 and + ChaCha20 stream ciphers to set or update the required nonce. In + these cases it needs to be called after setting the key. + + -- Function: gcry_error_t gcry_cipher_setctr (gcry_cipher_hd_t H, const + void *C, size_t L) + + Set the counter vector used for encryption or decryption. The + counter is passed as the buffer C of length L bytes and copied to + internal data structures. The function checks that the counter + matches the requirement of the selected algorithm (i.e., it must be + the same size as the block size). + + -- Function: gcry_error_t gcry_cipher_reset (gcry_cipher_hd_t H) + + Set the given handle's context back to the state it had after the + last call to gcry_cipher_setkey and clear the initialization + vector. + + Note that gcry_cipher_reset is implemented as a macro. + + Authenticated Encryption with Associated Data (AEAD) block cipher +modes require the handling of the authentication tag and the additional +authenticated data, which can be done by using the following functions: + + -- Function: gcry_error_t gcry_cipher_authenticate (gcry_cipher_hd_t H, + const void *ABUF, size_t ABUFLEN) + + Process the buffer ABUF of length ABUFLEN as the additional + authenticated data (AAD) for AEAD cipher modes. + + -- Function: gcry_error_t gcry_cipher_gettag (gcry_cipher_hd_t H, + void *TAG, size_t TAGLEN) + + This function is used to read the authentication tag after + encryption. The function finalizes and outputs the authentication + tag to the buffer TAG of length TAGLEN bytes. + + Depending on the used mode certain restrictions for TAGLEN are + enforced: For GCM TAGLEN must be at least 16 or one of the allowed + truncated lengths (4, 8, 12, 13, 14, or 15). + + -- Function: gcry_error_t gcry_cipher_checktag (gcry_cipher_hd_t H, + const void *TAG, size_t TAGLEN) + + Check the authentication tag after decryption. The authentication + tag is passed as the buffer TAG of length TAGLEN bytes and compared + to internal authentication tag computed during decryption. Error + code 'GPG_ERR_CHECKSUM' is returned if the authentication tag in + the buffer TAG does not match the authentication tag calculated + during decryption. + + Depending on the used mode certain restrictions for TAGLEN are + enforced: For GCM TAGLEN must either be 16 or one of the allowed + truncated lengths (4, 8, 12, 13, 14, or 15). + + The actual encryption and decryption is done by using one of the +following functions. They may be used as often as required to process +all the data. + + -- Function: gcry_error_t gcry_cipher_encrypt (gcry_cipher_hd_t H, + unsigned char *out, size_t OUTSIZE, const unsigned char *IN, + size_t INLEN) + + 'gcry_cipher_encrypt' is used to encrypt the data. This function + can either work in place or with two buffers. It uses the cipher + context already setup and described by the handle H. There are 2 + ways to use the function: If IN is passed as 'NULL' and INLEN is + '0', in-place encryption of the data in OUT of length OUTSIZE takes + place. With IN being not 'NULL', INLEN bytes are encrypted to the + buffer OUT which must have at least a size of INLEN. OUTSIZE must + be set to the allocated size of OUT, so that the function can check + that there is sufficient space. Note that overlapping buffers are + not allowed. + + Depending on the selected algorithms and encryption mode, the + length of the buffers must be a multiple of the block size. + + Some encryption modes require that 'gcry_cipher_final' is used + before the final data chunk is passed to this function. + + The function returns '0' on success or an error code. + + -- Function: gcry_error_t gcry_cipher_decrypt (gcry_cipher_hd_t H, + unsigned char *out, size_t OUTSIZE, const unsigned char *IN, + size_t INLEN) + + 'gcry_cipher_decrypt' is used to decrypt the data. This function + can either work in place or with two buffers. It uses the cipher + context already setup and described by the handle H. There are 2 + ways to use the function: If IN is passed as 'NULL' and INLEN is + '0', in-place decryption of the data in OUT or length OUTSIZE takes + place. With IN being not 'NULL', INLEN bytes are decrypted to the + buffer OUT which must have at least a size of INLEN. OUTSIZE must + be set to the allocated size of OUT, so that the function can check + that there is sufficient space. Note that overlapping buffers are + not allowed. + + Depending on the selected algorithms and encryption mode, the + length of the buffers must be a multiple of the block size. + + Some encryption modes require that 'gcry_cipher_final' is used + before the final data chunk is passed to this function. + + The function returns '0' on success or an error code. + + The OCB mode features integrated padding and must thus be told about +the end of the input data. This is done with: + + -- Function: gcry_error_t gcry_cipher_final (gcry_cipher_hd_t H) + + Set a flag in the context to tell the encrypt and decrypt functions + that their next call will provide the last chunk of data. Only the + first call to this function has an effect and only for modes which + support it. Checking the error is in general not necessary. This + is implemented as a macro. + + OpenPGP (as defined in RFC-4880) requires a special sync operation in +some places. The following function is used for this: + + -- Function: gcry_error_t gcry_cipher_sync (gcry_cipher_hd_t H) + + Perform the OpenPGP sync operation on context H. Note that this is + a no-op unless the context was created with the flag + 'GCRY_CIPHER_ENABLE_SYNC' + + Some of the described functions are implemented as macros utilizing a +catch-all control function. This control function is rarely used +directly but there is nothing which would inhibit it: + + -- Function: gcry_error_t gcry_cipher_ctl (gcry_cipher_hd_t H, int CMD, + void *BUFFER, size_t BUFLEN) + + 'gcry_cipher_ctl' controls various aspects of the cipher module and + specific cipher contexts. Usually some more specialized functions + or macros are used for this purpose. The semantics of the function + and its parameters depends on the the command CMD and the passed + context handle H. Please see the comments in the source code + ('src/global.c') for details. + + -- Function: gcry_error_t gcry_cipher_info (gcry_cipher_hd_t H, int + WHAT, void *BUFFER, size_t *NBYTES) + + 'gcry_cipher_info' is used to retrieve various information about a + cipher context or the cipher module in general. + + 'GCRYCTL_GET_TAGLEN:' + Return the length of the tag for an AE algorithm mode. An + error is returned for modes which do not support a tag. + BUFFER must be given as NULL. On success the result is stored + NBYTES. The taglen is returned in bytes. + + +File: gcrypt.info, Node: General cipher functions, Prev: Working with cipher handles, Up: Symmetric cryptography + +5.4 General cipher functions +============================ + +To work with the algorithms, several functions are available to map +algorithm names to the internal identifiers, as well as ways to retrieve +information about an algorithm or the current cipher context. + + -- Function: gcry_error_t gcry_cipher_algo_info (int ALGO, int WHAT, + void *BUFFER, size_t *NBYTES) + + This function is used to retrieve information on a specific + algorithm. You pass the cipher algorithm ID as ALGO and the type + of information requested as WHAT. The result is either returned as + the return code of the function or copied to the provided BUFFER + whose allocated length must be available in an integer variable + with the address passed in NBYTES. This variable will also receive + the actual used length of the buffer. + + Here is a list of supported codes for WHAT: + + 'GCRYCTL_GET_KEYLEN:' + Return the length of the key. If the algorithm supports + multiple key lengths, the maximum supported value is returned. + The length is returned as number of octets (bytes) and not as + number of bits in NBYTES; BUFFER must be zero. Note that it + is usually better to use the convenience function + 'gcry_cipher_get_algo_keylen'. + + 'GCRYCTL_GET_BLKLEN:' + Return the block length of the algorithm. The length is + returned as a number of octets in NBYTES; BUFFER must be zero. + Note that it is usually better to use the convenience function + 'gcry_cipher_get_algo_blklen'. + + 'GCRYCTL_TEST_ALGO:' + Returns '0' when the specified algorithm is available for use. + BUFFER and NBYTES must be zero. + + -- Function: size_t gcry_cipher_get_algo_keylen (ALGO) + + This function returns length of the key for algorithm ALGO. If the + algorithm supports multiple key lengths, the maximum supported key + length is returned. On error '0' is returned. The key length is + returned as number of octets. + + This is a convenience functions which should be preferred over + 'gcry_cipher_algo_info' because it allows for proper type checking. + + -- Function: size_t gcry_cipher_get_algo_blklen (int ALGO) + + This functions returns the block-length of the algorithm ALGO + counted in octets. On error '0' is returned. + + This is a convenience functions which should be preferred over + 'gcry_cipher_algo_info' because it allows for proper type checking. + + -- Function: const char * gcry_cipher_algo_name (int ALGO) + + 'gcry_cipher_algo_name' returns a string with the name of the + cipher algorithm ALGO. If the algorithm is not known or another + error occurred, the string '"?"' is returned. This function should + not be used to test for the availability of an algorithm. + + -- Function: int gcry_cipher_map_name (const char *NAME) + + 'gcry_cipher_map_name' returns the algorithm identifier for the + cipher algorithm described by the string NAME. If this algorithm + is not available '0' is returned. + + -- Function: int gcry_cipher_mode_from_oid (const char *STRING) + + Return the cipher mode associated with an ASN.1 object identifier. + The object identifier is expected to be in the IETF-style dotted + decimal notation. The function returns '0' for an unknown object + identifier or when no mode is associated with it. + + +File: gcrypt.info, Node: Public Key cryptography, Next: Hashing, Prev: Symmetric cryptography, Up: Top + +6 Public Key cryptography +************************* + +Public key cryptography, also known as asymmetric cryptography, is an +easy way for key management and to provide digital signatures. +Libgcrypt provides two completely different interfaces to public key +cryptography, this chapter explains the one based on S-expressions. + +* Menu: + +* Available algorithms:: Algorithms supported by the library. +* Used S-expressions:: Introduction into the used S-expression. +* Cryptographic Functions:: Functions for performing the cryptographic actions. +* Dedicated ECC Functions:: Dedicated functions for elliptic curves. +* General public-key related Functions:: General functions, not implementing any cryptography. + + +File: gcrypt.info, Node: Available algorithms, Next: Used S-expressions, Up: Public Key cryptography + +6.1 Available algorithms +======================== + +Libgcrypt supports the RSA (Rivest-Shamir-Adleman) algorithms as well as +DSA (Digital Signature Algorithm), Elgamal, ECDSA, ECDH, and EdDSA. + + +File: gcrypt.info, Node: Used S-expressions, Next: Cryptographic Functions, Prev: Available algorithms, Up: Public Key cryptography + +6.2 Used S-expressions +====================== + +Libgcrypt's API for asymmetric cryptography is based on data structures +called S-expressions (see +<http://people.csail.mit.edu/rivest/sexp.html>) and does not work with +contexts/handles as most of the other building blocks of Libgcrypt do. + +The following information are stored in S-expressions: + + * keys + + * plain text data + + * encrypted data + + * signatures + +To describe how Libgcrypt expect keys, we use examples. Note that words +in uppercase indicate parameters whereas lowercase words are literals. + + Note that all MPI (multi-precision-integers) values are expected to +be in 'GCRYMPI_FMT_USG' format. An easy way to create S-expressions is +by using 'gcry_sexp_build' which allows to pass a string with +printf-like escapes to insert MPI values. + +* Menu: + +* RSA key parameters:: Parameters used with an RSA key. +* DSA key parameters:: Parameters used with a DSA key. +* ECC key parameters:: Parameters used with ECC keys. + + +File: gcrypt.info, Node: RSA key parameters, Next: DSA key parameters, Up: Used S-expressions + +6.2.1 RSA key parameters +------------------------ + +An RSA private key is described by this S-expression: + + (private-key + (rsa + (n N-MPI) + (e E-MPI) + (d D-MPI) + (p P-MPI) + (q Q-MPI) + (u U-MPI))) + +An RSA public key is described by this S-expression: + + (public-key + (rsa + (n N-MPI) + (e E-MPI))) + +N-MPI + RSA public modulus n. +E-MPI + RSA public exponent e. +D-MPI + RSA secret exponent d = e^{-1} \bmod (p-1)(q-1). +P-MPI + RSA secret prime p. +Q-MPI + RSA secret prime q with p < q. +U-MPI + Multiplicative inverse u = p^{-1} \bmod q. + + For signing and decryption the parameters (p, q, u) are optional but +greatly improve the performance. Either all of these optional +parameters must be given or none of them. They are mandatory for +gcry_pk_testkey. + + Note that OpenSSL uses slighly different parameters: q < p and u = +q^{-1} \bmod p. To use these parameters you will need to swap the +values and recompute u. Here is example code to do this: + + if (gcry_mpi_cmp (p, q) > 0) + { + gcry_mpi_swap (p, q); + gcry_mpi_invm (u, p, q); + } + + +File: gcrypt.info, Node: DSA key parameters, Next: ECC key parameters, Prev: RSA key parameters, Up: Used S-expressions + +6.2.2 DSA key parameters +------------------------ + +A DSA private key is described by this S-expression: + + (private-key + (dsa + (p P-MPI) + (q Q-MPI) + (g G-MPI) + (y Y-MPI) + (x X-MPI))) + +P-MPI + DSA prime p. +Q-MPI + DSA group order q (which is a prime divisor of p-1). +G-MPI + DSA group generator g. +Y-MPI + DSA public key value y = g^x \bmod p. +X-MPI + DSA secret exponent x. + + The public key is similar with "private-key" replaced by "public-key" +and no X-MPI. + + +File: gcrypt.info, Node: ECC key parameters, Prev: DSA key parameters, Up: Used S-expressions + +6.2.3 ECC key parameters +------------------------ + +An ECC private key is described by this S-expression: + + (private-key + (ecc + (p P-MPI) + (a A-MPI) + (b B-MPI) + (g G-POINT) + (n N-MPI) + (q Q-POINT) + (d D-MPI))) + +P-MPI + Prime specifying the field GF(p). +A-MPI +B-MPI + The two coefficients of the Weierstrass equation y^2 = x^3 + ax + b +G-POINT + Base point g. +N-MPI + Order of g +Q-POINT + The point representing the public key Q = dG. +D-MPI + The private key d + + All point values are encoded in standard format; Libgcrypt does in +general only support uncompressed points, thus the first byte needs to +be '0x04'. However "EdDSA" describes its own compression scheme which +is used by default; the non-standard first byte '0x40' may optionally be +used to explicit flag the use of the algorithm’s native compression +method. + + The public key is similar with "private-key" replaced by "public-key" +and no D-MPI. + + If the domain parameters are well-known, the name of this curve may +be used. For example + + (private-key + (ecc + (curve "NIST P-192") + (q Q-POINT) + (d D-MPI))) + + Note that Q-POINT is optional for a private key. The 'curve' +parameter may be given in any case and is used to replace missing +parameters. + +Currently implemented curves are: + +'Curve25519' +'X25519' +'1.3.6.1.4.1.3029.1.5.1' +'1.3.101.110' + The RFC-8410 255 bit curve, its RFC name, OpenPGP and RFC OIDs. + +'X448' +'1.3.101.111' + The RFC-8410 448 bit curve and its RFC OID. + +'Ed25519' +'1.3.6.1.4.1.11591.15.1' +'1.3.101.112' + The signing variant of the RFC-8410 255 bit curve, its OpenPGP and + RFC OIDs. + +'Ed448' +'1.3.101.113' + The signing variant of the RFC-8410 448 bit curve and its RFC OID. + +'NIST P-192' +'1.2.840.10045.3.1.1' +'nistp192' +'prime192v1' +'secp192r1' + The NIST 192 bit curve, its OID and aliases. + +'NIST P-224' +'1.3.132.0.33' +'nistp224' +'secp224r1' + The NIST 224 bit curve, its OID and aliases. + +'NIST P-256' +'1.2.840.10045.3.1.7' +'nistp256' +'prime256v1' +'secp256r1' + The NIST 256 bit curve, its OID and aliases. + +'NIST P-384' +'1.3.132.0.34' +'nistp384' +'secp384r1' + The NIST 384 bit curve, its OID and aliases. + +'NIST P-521' +'1.3.132.0.35' +'nistp521' +'secp521r1' + The NIST 521 bit curve, its OID and aliases. + +'brainpoolP160r1' +'1.3.36.3.3.2.8.1.1.1' + The Brainpool 160 bit curve and its OID. + +'brainpoolP192r1' +'1.3.36.3.3.2.8.1.1.3' + The Brainpool 192 bit curve and its OID. + +'brainpoolP224r1' +'1.3.36.3.3.2.8.1.1.5' + The Brainpool 224 bit curve and its OID. + +'brainpoolP256r1' +'1.3.36.3.3.2.8.1.1.7' + The Brainpool 256 bit curve and its OID. + +'brainpoolP320r1' +'1.3.36.3.3.2.8.1.1.9' + The Brainpool 320 bit curve and its OID. + +'brainpoolP384r1' +'1.3.36.3.3.2.8.1.1.11' + The Brainpool 384 bit curve and its OID. + +'brainpoolP512r1' +'1.3.36.3.3.2.8.1.1.13' + The Brainpool 512 bit curve and its OID. + + As usual the OIDs may optionally be prefixed with the string 'OID.' +or 'oid.'. + + +File: gcrypt.info, Node: Cryptographic Functions, Next: Dedicated ECC Functions, Prev: Used S-expressions, Up: Public Key cryptography + +6.3 Cryptographic Functions +=========================== + +Some functions operating on S-expressions support 'flags' to influence +the operation. These flags have to be listed in a sub-S-expression +named 'flags'. Flag names are case-sensitive. The following flags are +known: + +'comp' +'nocomp' + If supported by the algorithm and curve the 'comp' flag requests + that points are returned in compact (compressed) representation. + The 'nocomp' flag requests that points are returned with full + coordinates. The default depends on the the algorithm and curve. + The compact representation requires a small overhead before a point + can be used but halves the size of a to be conveyed public key. If + 'comp' is used with the "EdDSA" algorithm the key generation prefix + the public key with a '0x40' byte. + +'pkcs1' + Use PKCS#1 block type 2 padding for encryption, block type 1 + padding for signing. + +'oaep' + Use RSA-OAEP padding for encryption. + +'pss' + Use RSA-PSS padding for signing. + +'eddsa' + Use the EdDSA scheme signing instead of the default ECDSA + algorithm. Note that the EdDSA uses a special form of the public + key. + +'rfc6979' + For DSA and ECDSA use a deterministic scheme for the k parameter. + +'no-blinding' + Do not use a technique called 'blinding', which is used by default + in order to prevent leaking of secret information. Blinding is + only implemented by RSA, but it might be implemented by other + algorithms in the future as well, when necessary. + +'param' + For ECC key generation also return the domain parameters. For ECC + signing and verification override default parameters by provided + domain parameters of the public or private key. + +'transient-key' + This flag is only meaningful for RSA, DSA, and ECC key generation. + If given the key is created using a faster and a somewhat less + secure random number generator. This flag may be used for keys + which are only used for a short time or per-message and do not + require full cryptographic strength. + +'no-keytest' + This flag skips internal failsafe tests to assert that a generated + key is properly working. It currently has an effect only for + standard ECC key generation. It is mostly useful along with + transient-key to achieve fastest ECC key generation. + +'use-x931' + Force the use of the ANSI X9.31 key generation algorithm instead of + the default algorithm. This flag is only meaningful for RSA key + generation and usually not required. Note that this algorithm is + implicitly used if either 'derive-parms' is given or Libgcrypt is + in FIPS mode. + +'use-fips186' + Force the use of the FIPS 186 key generation algorithm instead of + the default algorithm. This flag is only meaningful for DSA and + usually not required. Note that this algorithm is implicitly used + if either 'derive-parms' is given or Libgcrypt is in FIPS mode. As + of now FIPS 186-2 is implemented; after the approval of FIPS 186-3 + the code will be changed to implement 186-3. + +'use-fips186-2' + Force the use of the FIPS 186-2 key generation algorithm instead of + the default algorithm. This algorithm is slightly different from + FIPS 186-3 and allows only 1024 bit keys. This flag is only + meaningful for DSA and only required for FIPS testing backward + compatibility. + +Now that we know the key basics, we can carry on and explain how to +encrypt and decrypt data. In almost all cases the data is a random +session key which is in turn used for the actual encryption of the real +data. There are 2 functions to do this: + + -- Function: gcry_error_t gcry_pk_encrypt (gcry_sexp_t *R_CIPH, + gcry_sexp_t DATA, gcry_sexp_t PKEY) + + Obviously a public key must be provided for encryption. It is + expected as an appropriate S-expression (see above) in PKEY. The + data to be encrypted can either be in the simple old format, which + is a very simple S-expression consisting only of one MPI, or it may + be a more complex S-expression which also allows to specify flags + for operation, like e.g. padding rules. + + If you don't want to let Libgcrypt handle the padding, you must + pass an appropriate MPI using this expression for DATA: + + (data + (flags raw) + (value MPI)) + + This has the same semantics as the old style MPI only way. MPI is + the actual data, already padded appropriate for your protocol. + Most RSA based systems however use PKCS#1 padding and so you can + use this S-expression for DATA: + + (data + (flags pkcs1) + (value BLOCK)) + + Here, the "flags" list has the "pkcs1" flag which let the function + know that it should provide PKCS#1 block type 2 padding. The + actual data to be encrypted is passed as a string of octets in + BLOCK. The function checks that this data actually can be used + with the given key, does the padding and encrypts it. + + If the function could successfully perform the encryption, the + return value will be 0 and a new S-expression with the encrypted + result is allocated and assigned to the variable at the address of + R_CIPH. The caller is responsible to release this value using + 'gcry_sexp_release'. In case of an error, an error code is + returned and R_CIPH will be set to 'NULL'. + + The returned S-expression has this format when used with RSA: + + (enc-val + (rsa + (a A-MPI))) + + Where A-MPI is an MPI with the result of the RSA operation. When + using the Elgamal algorithm, the return value will have this + format: + + (enc-val + (elg + (a A-MPI) + (b B-MPI))) + + Where A-MPI and B-MPI are MPIs with the result of the Elgamal + encryption operation. + + -- Function: gcry_error_t gcry_pk_decrypt (gcry_sexp_t *R_PLAIN, + gcry_sexp_t DATA, gcry_sexp_t SKEY) + + Obviously a private key must be provided for decryption. It is + expected as an appropriate S-expression (see above) in SKEY. The + data to be decrypted must match the format of the result as + returned by 'gcry_pk_encrypt', but should be enlarged with a + 'flags' element: + + (enc-val + (flags) + (elg + (a A-MPI) + (b B-MPI))) + + This function does not remove padding from the data by default. To + let Libgcrypt remove padding, give a hint in 'flags' telling which + padding method was used when encrypting: + + (flags PADDING-METHOD) + + Currently PADDING-METHOD is either 'pkcs1' for PKCS#1 block type 2 + padding, or 'oaep' for RSA-OAEP padding. + + The function returns 0 on success or an error code. The variable + at the address of R_PLAIN will be set to NULL on error or receive + the decrypted value on success. The format of R_PLAIN is a simple + S-expression part (i.e. not a valid one) with just one MPI if + there was no 'flags' element in DATA; if at least an empty 'flags' + is passed in DATA, the format is: + + (value PLAINTEXT) + + Another operation commonly performed using public key cryptography is +signing data. In some sense this is even more important than encryption +because digital signatures are an important instrument for key +management. Libgcrypt supports digital signatures using 2 functions, +similar to the encryption functions: + + -- Function: gcry_error_t gcry_pk_sign (gcry_sexp_t *R_SIG, + gcry_sexp_t DATA, gcry_sexp_t SKEY) + + This function creates a digital signature for DATA using the + private key SKEY and place it into the variable at the address of + R_SIG. DATA may either be the simple old style S-expression with + just one MPI or a modern and more versatile S-expression which + allows to let Libgcrypt handle padding: + + (data + (flags pkcs1) + (hash HASH-ALGO BLOCK)) + + This example requests to sign the data in BLOCK after applying + PKCS#1 block type 1 style padding. HASH-ALGO is a string with the + hash algorithm to be encoded into the signature, this may be any + hash algorithm name as supported by Libgcrypt. Most likely, this + will be "sha256" or "sha1". It is obvious that the length of BLOCK + must match the size of that message digests; the function checks + that this and other constraints are valid. + + If PKCS#1 padding is not required (because the caller does already + provide a padded value), either the old format or better the + following format should be used: + + (data + (flags raw) + (value MPI)) + + Here, the data to be signed is directly given as an MPI. + + For DSA the input data is expected in this format: + + (data + (flags raw) + (value MPI)) + + Here, the data to be signed is directly given as an MPI. It is + expect that this MPI is the the hash value. For the standard DSA + using a MPI is not a problem in regard to leading zeroes because + the hash value is directly used as an MPI. For better standard + conformance it would be better to explicit use a memory string + (like with pkcs1) but that is currently not supported. However, + for deterministic DSA as specified in RFC6979 this can't be used. + Instead the following input is expected. + + (data + (flags rfc6979) + (hash HASH-ALGO BLOCK)) + + Note that the provided hash-algo is used for the internal HMAC; it + should match the hash-algo used to create BLOCK. + + The signature is returned as a newly allocated S-expression in + R_SIG using this format for RSA: + + (sig-val + (rsa + (s S-MPI))) + + Where S-MPI is the result of the RSA sign operation. For DSA the + S-expression returned is: + + (sig-val + (dsa + (r R-MPI) + (s S-MPI))) + + Where R-MPI and S-MPI are the result of the DSA sign operation. + + For Elgamal signing (which is slow, yields large numbers and + probably is not as secure as the other algorithms), the same format + is used with "elg" replacing "dsa"; for ECDSA signing, the same + format is used with "ecdsa" replacing "dsa". + + For the EdDSA algorithm (cf. Ed25515) the required input + parameters are: + + (data + (flags eddsa) + (hash-algo sha512) + (value MESSAGE)) + + Note that the MESSAGE may be of any length; hashing is part of the + algorithm. Using a large data block for MESSAGE is in general not + suggested; in that case the used protocol should better require + that a hash of the message is used as input to the EdDSA algorithm. + Note that for X.509 certificates MESSAGE is the 'tbsCertificate' + part and in CMS MESSAGE is the 'signedAttrs' part; see RFC-8410 and + RFC-8419. + +The operation most commonly used is definitely the verification of a +signature. Libgcrypt provides this function: + + -- Function: gcry_error_t gcry_pk_verify (gcry_sexp_t SIG, + gcry_sexp_t DATA, gcry_sexp_t PKEY) + + This is used to check whether the signature SIG matches the DATA. + The public key PKEY must be provided to perform this verification. + This function is similar in its parameters to 'gcry_pk_sign' with + the exceptions that the public key is used instead of the private + key and that no signature is created but a signature, in a format + as created by 'gcry_pk_sign', is passed to the function in SIG. + + The result is 0 for success (i.e. the data matches the signature), + or an error code where the most relevant code is + 'GCRY_ERR_BAD_SIGNATURE' to indicate that the signature does not + match the provided data. + + +File: gcrypt.info, Node: Dedicated ECC Functions, Next: General public-key related Functions, Prev: Cryptographic Functions, Up: Public Key cryptography + +6.4 Dedicated functions for elliptic curves. +============================================ + +The S-expression based interface is for certain operations on elliptic +curves not optimal. Thus a few special functions are implemented to +support common operations on curves with one of these assigned curve +ids: + +'GCRY_ECC_CURVE25519' +'GCRY_ECC_CURVE448' + + -- Function: unsigned int gcry_ecc_get_algo_keylen (int CURVEID); + + Returns the length in bytes of a point on the curve with the id + CURVEID. 0 is returned for curves which have no assigned id. + + -- Function: gpg_error_t gcry_ecc_mul_point (int CURVEID, + unsigned char *RESULT, const unsigned char *SCALAR, + const unsigned char *POINT) + + This function computes the scalar multiplication on the Montgomery + form of the curve with id CURVEID. If POINT is NULL the base point + of the curve is used. The caller needs to provide a large enough + buffer for RESULT and a valid SCALAR and POINT. + + +File: gcrypt.info, Node: General public-key related Functions, Prev: Dedicated ECC Functions, Up: Public Key cryptography + +6.5 General public-key related Functions +======================================== + +A couple of utility functions are available to retrieve the length of +the key, map algorithm identifiers and perform sanity checks: + + -- Function: const char * gcry_pk_algo_name (int ALGO) + + Map the public key algorithm id ALGO to a string representation of + the algorithm name. For unknown algorithms this functions returns + the string '"?"'. This function should not be used to test for the + availability of an algorithm. + + -- Function: int gcry_pk_map_name (const char *NAME) + + Map the algorithm NAME to a public key algorithm Id. Returns 0 if + the algorithm name is not known. + + -- Function: int gcry_pk_test_algo (int ALGO) + + Return 0 if the public key algorithm ALGO is available for use. + Note that this is implemented as a macro. + + -- Function: unsigned int gcry_pk_get_nbits (gcry_sexp_t KEY) + + Return what is commonly referred as the key length for the given + public or private in KEY. + + -- Function: unsigned char * gcry_pk_get_keygrip (gcry_sexp_t KEY, + unsigned char *ARRAY) + + Return the so called "keygrip" which is the SHA-1 hash of the + public key parameters expressed in a way depended on the algorithm. + ARRAY must either provide space for 20 bytes or be 'NULL'. In the + latter case a newly allocated array of that size is returned. On + success a pointer to the newly allocated space or to ARRAY is + returned. 'NULL' is returned to indicate an error which is most + likely an unknown algorithm or one where a "keygrip" has not yet + been defined. The function accepts public or secret keys in KEY. + + -- Function: gcry_error_t gcry_pk_testkey (gcry_sexp_t KEY) + + Return zero if the private key KEY is 'sane', an error code + otherwise. Note that it is not possible to check the 'saneness' of + a public key. + + -- Function: gcry_error_t gcry_pk_algo_info (int ALGO, int WHAT, + void *BUFFER, size_t *NBYTES) + + Depending on the value of WHAT return various information about the + public key algorithm with the id ALGO. Note that the function + returns '-1' on error and the actual error code must be retrieved + using the function 'gcry_errno'. The currently defined values for + WHAT are: + + 'GCRYCTL_TEST_ALGO:' + Return 0 if the specified algorithm is available for use. + BUFFER must be 'NULL', NBYTES may be passed as 'NULL' or point + to a variable with the required usage of the algorithm. This + may be 0 for "don't care" or the bit-wise OR of these flags: + + 'GCRY_PK_USAGE_SIGN' + Algorithm is usable for signing. + 'GCRY_PK_USAGE_ENCR' + Algorithm is usable for encryption. + + Unless you need to test for the allowed usage, it is in + general better to use the macro gcry_pk_test_algo instead. + + 'GCRYCTL_GET_ALGO_USAGE:' + Return the usage flags for the given algorithm. An invalid + algorithm return 0. Disabled algorithms are ignored here + because we want to know whether the algorithm is at all + capable of a certain usage. + + 'GCRYCTL_GET_ALGO_NPKEY' + Return the number of elements the public key for algorithm + ALGO consist of. Return 0 for an unknown algorithm. + + 'GCRYCTL_GET_ALGO_NSKEY' + Return the number of elements the private key for algorithm + ALGO consist of. Note that this value is always larger than + that of the public key. Return 0 for an unknown algorithm. + + 'GCRYCTL_GET_ALGO_NSIGN' + Return the number of elements a signature created with the + algorithm ALGO consists of. Return 0 for an unknown algorithm + or for an algorithm not capable of creating signatures. + + 'GCRYCTL_GET_ALGO_NENCR' + Return the number of elements a encrypted message created with + the algorithm ALGO consists of. Return 0 for an unknown + algorithm or for an algorithm not capable of encryption. + + Please note that parameters not required should be passed as + 'NULL'. + + -- Function: gcry_error_t gcry_pk_ctl (int CMD, void *BUFFER, + size_t BUFLEN) + + This is a general purpose function to perform certain control + operations. CMD controls what is to be done. The return value is + 0 for success or an error code. Currently supported values for CMD + are: + + 'GCRYCTL_DISABLE_ALGO' + Disable the algorithm given as an algorithm id in BUFFER. + BUFFER must point to an 'int' variable with the algorithm id + and BUFLEN must have the value 'sizeof (int)'. This function + is not thread safe and should thus be used before any other + threads are started. + +Libgcrypt also provides a function to generate public key pairs: + + -- Function: gcry_error_t gcry_pk_genkey (gcry_sexp_t *R_KEY, + gcry_sexp_t PARMS) + + This function create a new public key pair using information given + in the S-expression PARMS and stores the private and the public key + in one new S-expression at the address given by R_KEY. In case of + an error, R_KEY is set to 'NULL'. The return code is 0 for success + or an error code otherwise. + + Here is an example for PARMS to create an 2048 bit RSA key: + + (genkey + (rsa + (nbits 4:2048))) + + To create an Elgamal key, substitute "elg" for "rsa" and to create + a DSA key use "dsa". Valid ranges for the key length depend on the + algorithms; all commonly used key lengths are supported. Currently + supported parameters are: + + 'nbits' + This is always required to specify the length of the key. The + argument is a string with a number in C-notation. The value + should be a multiple of 8. Note that the S-expression syntax + requires that a number is prefixed with its string length; + thus the '4:' in the above example. + + 'curve NAME' + For ECC a named curve may be used instead of giving the number + of requested bits. This allows to request a specific curve to + override a default selection Libgcrypt would have taken if + 'nbits' has been given. The available names are listed with + the description of the ECC public key parameters. + + 'rsa-use-e VALUE' + This is only used with RSA to give a hint for the public + exponent. The VALUE will be used as a base to test for a + usable exponent. Some values are special: + + '0' + Use a secure and fast value. This is currently the + number 41. + '1' + Use a value as required by some crypto policies. This is + currently the number 65537. + '2' + Reserved + '> 2' + Use the given value. + + If this parameter is not used, Libgcrypt uses for historic + reasons 65537. Note that the value must fit into a 32 bit + unsigned variable and that the usual C prefixes are considered + (e.g. 017 gives 15). + + 'qbits N' + This is only meanigful for DSA keys. If it is given the DSA + key is generated with a Q parameyer of size N bits. If it is + not given or zero Q is deduced from NBITS in this way: + '512 <= N <= 1024' + Q = 160 + 'N = 2048' + Q = 224 + 'N = 3072' + Q = 256 + 'N = 7680' + Q = 384 + 'N = 15360' + Q = 512 + Note that in this case only the values for N, as given in the + table, are allowed. When specifying Q all values of N in the + range 512 to 15680 are valid as long as they are multiples of + 8. + + 'domain LIST' + This is only meaningful for DLP algorithms. If specified keys + are generated with domain parameters taken from this list. + The exact format of this parameter depends on the actual + algorithm. It is currently only implemented for DSA using + this format: + + (genkey + (dsa + (domain + (p P-MPI) + (q Q-MPI) + (g Q-MPI)))) + + 'nbits' and 'qbits' may not be specified because they are + derived from the domain parameters. + + 'derive-parms LIST' + This is currently only implemented for RSA and DSA keys. It + is not allowed to use this together with a 'domain' + specification. If given, it is used to derive the keys using + the given parameters. + + If given for an RSA key the X9.31 key generation algorithm is + used even if libgcrypt is not in FIPS mode. If given for a + DSA key, the FIPS 186 algorithm is used even if libgcrypt is + not in FIPS mode. + + (genkey + (rsa + (nbits 4:1024) + (rsa-use-e 1:3) + (derive-parms + (Xp1 #1A1916DDB29B4EB7EB6732E128#) + (Xp2 #192E8AAC41C576C822D93EA433#) + (Xp #D8CD81F035EC57EFE822955149D3BFF70C53520D + 769D6D76646C7A792E16EBD89FE6FC5B605A6493 + 39DFC925A86A4C6D150B71B9EEA02D68885F5009 + B98BD984#) + (Xq1 #1A5CF72EE770DE50CB09ACCEA9#) + (Xq2 #134E4CAA16D2350A21D775C404#) + (Xq #CC1092495D867E64065DEE3E7955F2EBC7D47A2D + 7C9953388F97DDDC3E1CA19C35CA659EDC2FC325 + 6D29C2627479C086A699A49C4C9CEE7EF7BD1B34 + 321DE34A#)))) + + (genkey + (dsa + (nbits 4:1024) + (derive-parms + (seed SEED-MPI)))) + + 'flags FLAGLIST' + This is preferred way to define flags. FLAGLIST may contain + any number of flags. See above for a specification of these + flags. + + Here is an example on how to create a key using curve Ed25519 + with the ECDSA signature algorithm. Note that the use of + ECDSA with that curve is in general not recommended. + (genkey + (ecc + (flags transient-key))) + + 'transient-key' + 'use-x931' + 'use-fips186' + 'use-fips186-2' + These are deprecated ways to set a flag with that name; see + above for a description of each flag. + + The key pair is returned in a format depending on the algorithm. + Both private and public keys are returned in one container and may + be accompanied by some miscellaneous information. + + Here are two examples; the first for Elgamal and the second for + elliptic curve key generation: + + (key-data + (public-key + (elg + (p P-MPI) + (g G-MPI) + (y Y-MPI))) + (private-key + (elg + (p P-MPI) + (g G-MPI) + (y Y-MPI) + (x X-MPI))) + (misc-key-info + (pm1-factors N1 N2 ... NN)) + + (key-data + (public-key + (ecc + (curve Ed25519) + (flags eddsa) + (q Q-VALUE))) + (private-key + (ecc + (curve Ed25519) + (flags eddsa) + (q Q-VALUE) + (d D-VALUE)))) + + As you can see, some of the information is duplicated, but this + provides an easy way to extract either the public or the private + key. Note that the order of the elements is not defined, e.g. the + private key may be stored before the public key. N1 N2 ... NN is a + list of prime numbers used to composite P-MPI; this is in general + not a very useful information and only available if the key + generation algorithm provides them. + +Future versions of Libgcrypt will have extended versions of the public +key interfaced which will take an additional context to allow for +pre-computations, special operations, and other optimization. As a +first step a new function is introduced to help using the ECC algorithms +in new ways: + + -- Function: gcry_error_t gcry_pubkey_get_sexp (gcry_sexp_t *R_SEXP, + int MODE, gcry_ctx_t CTX) + + Return an S-expression representing the context CTX. Depending on + the state of that context, the S-expression may either be a public + key, a private key or any other object used with public key + operations. On success 0 is returned and a new S-expression is + stored at R_SEXP; on error an error code is returned and NULL is + stored at R_SEXP. MODE must be one of: + + '0' + Decide what to return depending on the context. For example + if the private key parameter is available a private key is + returned, if not a public key is returned. + + 'GCRY_PK_GET_PUBKEY' + Return the public key even if the context has the private key + parameter. + + 'GCRY_PK_GET_SECKEY' + Return the private key or the error 'GPG_ERR_NO_SECKEY' if it + is not possible. + + As of now this function supports only certain ECC operations + because a context object is right now only defined for ECC. Over + time this function will be extended to cover more algorithms. + + +File: gcrypt.info, Node: Hashing, Next: Message Authentication Codes, Prev: Public Key cryptography, Up: Top + +7 Hashing +********* + +Libgcrypt provides an easy and consistent to use interface for hashing. +Hashing is buffered and several hash algorithms can be updated at once. +It is possible to compute a HMAC using the same routines. The +programming model follows an open/process/close paradigm and is in that +similar to other building blocks provided by Libgcrypt. + + For convenience reasons, a few cyclic redundancy check value +operations are also supported. + +* Menu: + +* Available hash algorithms:: List of hash algorithms supported by the library. +* Working with hash algorithms:: List of functions related to hashing. + + +File: gcrypt.info, Node: Available hash algorithms, Next: Working with hash algorithms, Up: Hashing + +7.1 Available hash algorithms +============================= + +'GCRY_MD_NONE' + This is not a real algorithm but used by some functions as an error + return value. This constant is guaranteed to have the value '0'. + +'GCRY_MD_SHA1' + This is the SHA-1 algorithm which yields a message digest of 20 + bytes. Note that SHA-1 begins to show some weaknesses and it is + suggested to fade out its use if strong cryptographic properties + are required. + +'GCRY_MD_RMD160' + This is the 160 bit version of the RIPE message digest + (RIPE-MD-160). Like SHA-1 it also yields a digest of 20 bytes. + This algorithm share a lot of design properties with SHA-1 and thus + it is advisable not to use it for new protocols. + +'GCRY_MD_MD5' + This is the well known MD5 algorithm, which yields a message digest + of 16 bytes. Note that the MD5 algorithm has severe weaknesses, + for example it is easy to compute two messages yielding the same + hash (collision attack). The use of this algorithm is only + justified for non-cryptographic application. + +'GCRY_MD_MD4' + This is the MD4 algorithm, which yields a message digest of 16 + bytes. This algorithm has severe weaknesses and should not be + used. + +'GCRY_MD_MD2' + This is an reserved identifier for MD-2; there is no implementation + yet. This algorithm has severe weaknesses and should not be used. + +'GCRY_MD_TIGER' + This is the TIGER/192 algorithm which yields a message digest of 24 + bytes. Actually this is a variant of TIGER with a different output + print order as used by GnuPG up to version 1.3.2. + +'GCRY_MD_TIGER1' + This is the TIGER variant as used by the NESSIE project. It uses + the most commonly used output print order. + +'GCRY_MD_TIGER2' + This is another variant of TIGER with a different padding scheme. + +'GCRY_MD_HAVAL' + This is an reserved value for the HAVAL algorithm with 5 passes and + 160 bit. It yields a message digest of 20 bytes. Note that there + is no implementation yet available. + +'GCRY_MD_SHA224' + This is the SHA-224 algorithm which yields a message digest of 28 + bytes. See Change Notice 1 for FIPS 180-2 for the specification. + +'GCRY_MD_SHA256' + This is the SHA-256 algorithm which yields a message digest of 32 + bytes. See FIPS 180-2 for the specification. + +'GCRY_MD_SHA384' + This is the SHA-384 algorithm which yields a message digest of 48 + bytes. See FIPS 180-2 for the specification. + +'GCRY_MD_SHA512' + This is the SHA-512 algorithm which yields a message digest of 64 + bytes. See FIPS 180-2 for the specification. + +'GCRY_MD_SHA512_224' + This is the SHA-512/224 algorithm which yields a message digest of + 28 bytes. See FIPS 180-4 for the specification. + +'GCRY_MD_SHA512_256' + This is the SHA-512/256 algorithm which yields a message digest of + 32 bytes. See FIPS 180-4 for the specification. + +'GCRY_MD_SHA3_224' + This is the SHA3-224 algorithm which yields a message digest of 28 + bytes. See FIPS 202 for the specification. + +'GCRY_MD_SHA3_256' + This is the SHA3-256 algorithm which yields a message digest of 32 + bytes. See FIPS 202 for the specification. + +'GCRY_MD_SHA3_384' + This is the SHA3-384 algorithm which yields a message digest of 48 + bytes. See FIPS 202 for the specification. + +'GCRY_MD_SHA3_512' + This is the SHA3-512 algorithm which yields a message digest of 64 + bytes. See FIPS 202 for the specification. + +'GCRY_MD_SHAKE128' + This is the SHAKE128 extendable-output function (XOF) algorithm + with 128 bit security strength. See FIPS 202 for the + specification. + +'GCRY_MD_SHAKE256' + This is the SHAKE256 extendable-output function (XOF) algorithm + with 256 bit security strength. See FIPS 202 for the + specification. + +'GCRY_MD_CRC32' + This is the ISO 3309 and ITU-T V.42 cyclic redundancy check. It + yields an output of 4 bytes. Note that this is not a hash + algorithm in the cryptographic sense. + +'GCRY_MD_CRC32_RFC1510' + This is the above cyclic redundancy check function, as modified by + RFC 1510. It yields an output of 4 bytes. Note that this is not a + hash algorithm in the cryptographic sense. + +'GCRY_MD_CRC24_RFC2440' + This is the OpenPGP cyclic redundancy check function. It yields an + output of 3 bytes. Note that this is not a hash algorithm in the + cryptographic sense. + +'GCRY_MD_WHIRLPOOL' + This is the Whirlpool algorithm which yields a message digest of 64 + bytes. + +'GCRY_MD_GOSTR3411_94' + This is the hash algorithm described in GOST R 34.11-94 which + yields a message digest of 32 bytes. + +'GCRY_MD_STRIBOG256' + This is the 256-bit version of hash algorithm described in GOST R + 34.11-2012 which yields a message digest of 32 bytes. + +'GCRY_MD_STRIBOG512' + This is the 512-bit version of hash algorithm described in GOST R + 34.11-2012 which yields a message digest of 64 bytes. + +'GCRY_MD_BLAKE2B_512' + This is the BLAKE2b-512 algorithm which yields a message digest of + 64 bytes. See RFC 7693 for the specification. + +'GCRY_MD_BLAKE2B_384' + This is the BLAKE2b-384 algorithm which yields a message digest of + 48 bytes. See RFC 7693 for the specification. + +'GCRY_MD_BLAKE2B_256' + This is the BLAKE2b-256 algorithm which yields a message digest of + 32 bytes. See RFC 7693 for the specification. + +'GCRY_MD_BLAKE2B_160' + This is the BLAKE2b-160 algorithm which yields a message digest of + 20 bytes. See RFC 7693 for the specification. + +'GCRY_MD_BLAKE2S_256' + This is the BLAKE2s-256 algorithm which yields a message digest of + 32 bytes. See RFC 7693 for the specification. + +'GCRY_MD_BLAKE2S_224' + This is the BLAKE2s-224 algorithm which yields a message digest of + 28 bytes. See RFC 7693 for the specification. + +'GCRY_MD_BLAKE2S_160' + This is the BLAKE2s-160 algorithm which yields a message digest of + 20 bytes. See RFC 7693 for the specification. + +'GCRY_MD_BLAKE2S_128' + This is the BLAKE2s-128 algorithm which yields a message digest of + 16 bytes. See RFC 7693 for the specification. + +'GCRY_MD_SM3' + This is the SM3 algorithm which yields a message digest of 32 + bytes. + + +File: gcrypt.info, Node: Working with hash algorithms, Prev: Available hash algorithms, Up: Hashing + +7.2 Working with hash algorithms +================================ + +To use most of these function it is necessary to create a context; this +is done using: + + -- Function: gcry_error_t gcry_md_open (gcry_md_hd_t *HD, int ALGO, + unsigned int FLAGS) + + Create a message digest object for algorithm ALGO. FLAGS may be + given as an bitwise OR of constants described below. ALGO may be + given as '0' if the algorithms to use are later set using + 'gcry_md_enable'. HD is guaranteed to either receive a valid + handle or NULL. + + For a list of supported algorithms, see *note Available hash + algorithms::. + + The flags allowed for MODE are: + + 'GCRY_MD_FLAG_SECURE' + Allocate all buffers and the resulting digest in "secure + memory". Use this is the hashed data is highly confidential. + + 'GCRY_MD_FLAG_HMAC' + Turn the algorithm into a HMAC message authentication + algorithm. This only works if just one algorithm is enabled + for the handle and that algorithm is not an extendable-output + function. Note that the function 'gcry_md_setkey' must be + used to set the MAC key. The size of the MAC is equal to the + message digest of the underlying hash algorithm. If you want + CBC message authentication codes based on a cipher, see *note + Working with cipher handles::. + + 'GCRY_MD_FLAG_BUGEMU1' + Versions of Libgcrypt before 1.6.0 had a bug in the Whirlpool + code which led to a wrong result for certain input sizes and + write patterns. Using this flag emulates that bug. This may + for example be useful for applications which use Whirlpool as + part of their key generation. It is strongly suggested to use + this flag only if really needed and if possible to the data + should be re-processed using the regular Whirlpool algorithm. + + Note that this flag works for the entire hash context. If + needed arises it may be used to enable bug emulation for other + hash algorithms. Thus you should not use this flag for a + multi-algorithm hash context. + + You may use the function 'gcry_md_is_enabled' to later check + whether an algorithm has been enabled. + + If you want to calculate several hash algorithms at the same time, +you have to use the following function right after the 'gcry_md_open': + + -- Function: gcry_error_t gcry_md_enable (gcry_md_hd_t H, int ALGO) + + Add the message digest algorithm ALGO to the digest object + described by handle H. Duplicated enabling of algorithms is + detected and ignored. + + If the flag 'GCRY_MD_FLAG_HMAC' was used, the key for the MAC must be +set using the function: + + -- Function: gcry_error_t gcry_md_setkey (gcry_md_hd_t H, const void + *KEY, size_t KEYLEN) + + For use with the HMAC feature or BLAKE2 keyed hash, set the MAC key + to the value of KEY of length KEYLEN bytes. For HMAC, there is no + restriction on the length of the key. For keyed BLAKE2b hash, + length of the key must be 64 bytes or less. For keyed BLAKE2s + hash, length of the key must be 32 bytes or less. + + After you are done with the hash calculation, you should release the +resources by using: + + -- Function: void gcry_md_close (gcry_md_hd_t H) + + Release all resources of hash context H. H should not be used + after a call to this function. A 'NULL' passed as H is ignored. + The function also zeroises all sensitive information associated + with this handle. + + Often you have to do several hash operations using the same +algorithm. To avoid the overhead of creating and releasing context, a +reset function is provided: + + -- Function: void gcry_md_reset (gcry_md_hd_t H) + + Reset the current context to its initial state. This is + effectively identical to a close followed by an open and enabling + all currently active algorithms. + + Often it is necessary to start hashing some data and then continue to +hash different data. To avoid hashing the same data several times +(which might not even be possible if the data is received from a pipe), +a snapshot of the current hash context can be taken and turned into a +new context: + + -- Function: gcry_error_t gcry_md_copy (gcry_md_hd_t *HANDLE_DST, + gcry_md_hd_t HANDLE_SRC) + + Create a new digest object as an exact copy of the object described + by handle HANDLE_SRC and store it in HANDLE_DST. The context is + not reset and you can continue to hash data using this context and + independently using the original context. + + Now that we have prepared everything to calculate hashes, it is time +to see how it is actually done. There are two ways for this, one to +update the hash with a block of memory and one macro to update the hash +by just one character. Both methods can be used on the same hash +context. + + -- Function: void gcry_md_write (gcry_md_hd_t H, const void *BUFFER, + size_t LENGTH) + + Pass LENGTH bytes of the data in BUFFER to the digest object with + handle H to update the digest values. This function should be used + for large blocks of data. If this function is used after the + context has been finalized, it will keep on pushing the data + through the algorithm specific transform function and change the + context; however the results are not meaningful and this feature is + only available to mitigate timing attacks. + + -- Function: void gcry_md_putc (gcry_md_hd_t H, int C) + + Pass the byte in C to the digest object with handle H to update the + digest value. This is an efficient function, implemented as a + macro to buffer the data before an actual update. + + The semantics of the hash functions do not provide for reading out +intermediate message digests because the calculation must be finalized +first. This finalization may for example include the number of bytes +hashed in the message digest or some padding. + + -- Function: void gcry_md_final (gcry_md_hd_t H) + + Finalize the message digest calculation. This is not really needed + because 'gcry_md_read' and 'gcry_md_extract' do this implicitly. + After this has been done no further updates (by means of + 'gcry_md_write' or 'gcry_md_putc' should be done; However, to + mitigate timing attacks it is sometimes useful to keep on updating + the context after having stored away the actual digest. Only the + first call to this function has an effect. It is implemented as a + macro. + + The way to read out the calculated message digest is by using the +function: + + -- Function: unsigned char * gcry_md_read (gcry_md_hd_t H, int ALGO) + + 'gcry_md_read' returns the message digest after finalizing the + calculation. This function may be used as often as required but it + will always return the same value for one handle. The returned + message digest is allocated within the message context and + therefore valid until the handle is released or reset-ed (using + 'gcry_md_close' or 'gcry_md_reset' or it has been updated as a + mitigation measure against timing attacks. ALGO may be given as 0 + to return the only enabled message digest or it may specify one of + the enabled algorithms. The function does return 'NULL' if the + requested algorithm has not been enabled. + + The way to read output of extendable-output function is by using the +function: + + -- Function: gpg_err_code_t gcry_md_extract (gcry_md_hd_t H, int ALGO, + void *BUFFER, size_t LENGTH) + + 'gcry_mac_read' returns output from extendable-output function. + This function may be used as often as required to generate more + output byte stream from the algorithm. Function extracts the new + output bytes to BUFFER of the length LENGTH. Buffer will be fully + populated with new output. ALGO may be given as 0 to return the + only enabled message digest or it may specify one of the enabled + algorithms. The function does return non-zero value if the + requested algorithm has not been enabled. + + Because it is often necessary to get the message digest of blocks of +memory, two fast convenience function are available for this task: + + -- Function: gpg_err_code_t gcry_md_hash_buffers ( int ALGO, + unsigned int FLAGS, void *DIGEST, const gcry_buffer_t *IOV, + int IOVCNT ) + + 'gcry_md_hash_buffers' is a shortcut function to calculate a + message digest from several buffers. This function does not + require a context and immediately returns the message digest of the + data described by IOV and IOVCNT. DIGEST must be allocated by the + caller, large enough to hold the message digest yielded by the the + specified algorithm ALGO. This required size may be obtained by + using the function 'gcry_md_get_algo_dlen'. + + IOV is an array of buffer descriptions with IOVCNT items. The + caller should zero out the structures in this array and for each + array item set the fields '.data' to the address of the data to be + hashed, '.len' to number of bytes to be hashed. If .OFF is also + set, the data is taken starting at .OFF bytes from the begin of the + buffer. The field '.size' is not used. + + The only supported flag value for FLAGS is GCRY_MD_FLAG_HMAC which + turns this function into a HMAC function; the first item in IOV is + then used as the key. + + On success the function returns 0 and stores the resulting hash or + MAC at DIGEST. + + -- Function: void gcry_md_hash_buffer (int ALGO, void *DIGEST, const + void *BUFFER, size_t LENGTH); + + 'gcry_md_hash_buffer' is a shortcut function to calculate a message + digest of a buffer. This function does not require a context and + immediately returns the message digest of the LENGTH bytes at + BUFFER. DIGEST must be allocated by the caller, large enough to + hold the message digest yielded by the the specified algorithm + ALGO. This required size may be obtained by using the function + 'gcry_md_get_algo_dlen'. + + Note that in contrast to 'gcry_md_hash_buffers' this function will + abort the process if an unavailable algorithm is used. + + Hash algorithms are identified by internal algorithm numbers (see +'gcry_md_open' for a list). However, in most applications they are used +by names, so two functions are available to map between string +representations and hash algorithm identifiers. + + -- Function: const char * gcry_md_algo_name (int ALGO) + + Map the digest algorithm id ALGO to a string representation of the + algorithm name. For unknown algorithms this function returns the + string '"?"'. This function should not be used to test for the + availability of an algorithm. + + -- Function: int gcry_md_map_name (const char *NAME) + + Map the algorithm with NAME to a digest algorithm identifier. + Returns 0 if the algorithm name is not known. Names representing + ASN.1 object identifiers are recognized if the IETF dotted format + is used and the OID is prefixed with either "'oid.'" or "'OID.'". + For a list of supported OIDs, see the source code at 'cipher/md.c'. + This function should not be used to test for the availability of an + algorithm. + + -- Function: gcry_error_t gcry_md_get_asnoid (int ALGO, void *BUFFER, + size_t *LENGTH) + + Return an DER encoded ASN.1 OID for the algorithm ALGO in the user + allocated BUFFER. LENGTH must point to variable with the available + size of BUFFER and receives after return the actual size of the + returned OID. The returned error code may be 'GPG_ERR_TOO_SHORT' if + the provided buffer is to short to receive the OID; it is possible + to call the function with 'NULL' for BUFFER to have it only return + the required size. The function returns 0 on success. + + To test whether an algorithm is actually available for use, the +following macro should be used: + + -- Function: gcry_error_t gcry_md_test_algo (int ALGO) + + The macro returns 0 if the algorithm ALGO is available for use. + + If the length of a message digest is not known, it can be retrieved +using the following function: + + -- Function: unsigned int gcry_md_get_algo_dlen (int ALGO) + + Retrieve the length in bytes of the digest yielded by algorithm + ALGO. This is often used prior to 'gcry_md_read' to allocate + sufficient memory for the digest. + + In some situations it might be hard to remember the algorithm used +for the ongoing hashing. The following function might be used to get +that information: + + -- Function: int gcry_md_get_algo (gcry_md_hd_t H) + + Retrieve the algorithm used with the handle H. Note that this does + not work reliable if more than one algorithm is enabled in H. + + The following macro might also be useful: + + -- Function: int gcry_md_is_secure (gcry_md_hd_t H) + + This function returns true when the digest object H is allocated in + "secure memory"; i.e. H was created with the + 'GCRY_MD_FLAG_SECURE'. + + -- Function: int gcry_md_is_enabled (gcry_md_hd_t H, int ALGO) + + This function returns true when the algorithm ALGO has been enabled + for the digest object H. + + Tracking bugs related to hashing is often a cumbersome task which +requires to add a lot of printf statements into the code. Libgcrypt +provides an easy way to avoid this. The actual data hashed can be +written to files on request. + + -- Function: void gcry_md_debug (gcry_md_hd_t H, const char *SUFFIX) + + Enable debugging for the digest object with handle H. This creates + files named 'dbgmd-<n>.<string>' while doing the actual hashing. + SUFFIX is the string part in the filename. The number is a counter + incremented for each new hashing. The data in the file is the raw + data as passed to 'gcry_md_write' or 'gcry_md_putc'. If 'NULL' is + used for SUFFIX, the debugging is stopped and the file closed. + This is only rarely required because 'gcry_md_close' implicitly + stops debugging. + + +File: gcrypt.info, Node: Message Authentication Codes, Next: Key Derivation, Prev: Hashing, Up: Top + +8 Message Authentication Codes +****************************** + +Libgcrypt provides an easy and consistent to use interface for +generating Message Authentication Codes (MAC). MAC generation is +buffered and interface similar to the one used with hash algorithms. +The programming model follows an open/process/close paradigm and is in +that similar to other building blocks provided by Libgcrypt. + +* Menu: + +* Available MAC algorithms:: List of MAC algorithms supported by the library. +* Working with MAC algorithms:: List of functions related to MAC algorithms. + + +File: gcrypt.info, Node: Available MAC algorithms, Next: Working with MAC algorithms, Up: Message Authentication Codes + +8.1 Available MAC algorithms +============================ + +'GCRY_MAC_NONE' + This is not a real algorithm but used by some functions as an error + return value. This constant is guaranteed to have the value '0'. + +'GCRY_MAC_HMAC_SHA256' + This is keyed-hash message authentication code (HMAC) message + authentication algorithm based on the SHA-256 hash algorithm. + +'GCRY_MAC_HMAC_SHA224' + This is HMAC message authentication algorithm based on the SHA-224 + hash algorithm. + +'GCRY_MAC_HMAC_SHA512' + This is HMAC message authentication algorithm based on the SHA-512 + hash algorithm. + +'GCRY_MAC_HMAC_SHA384' + This is HMAC message authentication algorithm based on the SHA-384 + hash algorithm. + +'GCRY_MAC_HMAC_SHA3_256' + This is HMAC message authentication algorithm based on the SHA3-256 + hash algorithm. + +'GCRY_MAC_HMAC_SHA3_224' + This is HMAC message authentication algorithm based on the SHA3-224 + hash algorithm. + +'GCRY_MAC_HMAC_SHA3_512' + This is HMAC message authentication algorithm based on the SHA3-512 + hash algorithm. + +'GCRY_MAC_HMAC_SHA3_384' + This is HMAC message authentication algorithm based on the SHA3-384 + hash algorithm. + +'GCRY_MAC_HMAC_SHA512_224' + This is HMAC message authentication algorithm based on the + SHA-512/224 hash algorithm. + +'GCRY_MAC_HMAC_SHA512_256' + This is HMAC message authentication algorithm based on the + SHA-512/256 hash algorithm. + +'GCRY_MAC_HMAC_SHA1' + This is HMAC message authentication algorithm based on the SHA-1 + hash algorithm. + +'GCRY_MAC_HMAC_MD5' + This is HMAC message authentication algorithm based on the MD5 hash + algorithm. + +'GCRY_MAC_HMAC_MD4' + This is HMAC message authentication algorithm based on the MD4 hash + algorithm. + +'GCRY_MAC_HMAC_RMD160' + This is HMAC message authentication algorithm based on the + RIPE-MD-160 hash algorithm. + +'GCRY_MAC_HMAC_WHIRLPOOL' + This is HMAC message authentication algorithm based on the + WHIRLPOOL hash algorithm. + +'GCRY_MAC_HMAC_GOSTR3411_94' + This is HMAC message authentication algorithm based on the GOST R + 34.11-94 hash algorithm. + +'GCRY_MAC_HMAC_STRIBOG256' + This is HMAC message authentication algorithm based on the 256-bit + hash algorithm described in GOST R 34.11-2012. + +'GCRY_MAC_HMAC_STRIBOG512' + This is HMAC message authentication algorithm based on the 512-bit + hash algorithm described in GOST R 34.11-2012. + +'GCRY_MAC_HMAC_BLAKE2B_512' + This is HMAC message authentication algorithm based on the + BLAKE2b-512 hash algorithm. + +'GCRY_MAC_HMAC_BLAKE2B_384' + This is HMAC message authentication algorithm based on the + BLAKE2b-384 hash algorithm. + +'GCRY_MAC_HMAC_BLAKE2B_256' + This is HMAC message authentication algorithm based on the + BLAKE2b-256 hash algorithm. + +'GCRY_MAC_HMAC_BLAKE2B_160' + This is HMAC message authentication algorithm based on the + BLAKE2b-160 hash algorithm. + +'GCRY_MAC_HMAC_BLAKE2S_256' + This is HMAC message authentication algorithm based on the + BLAKE2s-256 hash algorithm. + +'GCRY_MAC_HMAC_BLAKE2S_224' + This is HMAC message authentication algorithm based on the + BLAKE2s-224 hash algorithm. + +'GCRY_MAC_HMAC_BLAKE2S_160' + This is HMAC message authentication algorithm based on the + BLAKE2s-160 hash algorithm. + +'GCRY_MAC_HMAC_BLAKE2S_128' + This is HMAC message authentication algorithm based on the + BLAKE2s-128 hash algorithm. + +'GCRY_MAC_HMAC_SM3' + This is HMAC message authentication algorithm based on the SM3 hash + algorithm. + +'GCRY_MAC_CMAC_AES' + This is CMAC (Cipher-based MAC) message authentication algorithm + based on the AES block cipher algorithm. + +'GCRY_MAC_CMAC_3DES' + This is CMAC message authentication algorithm based on the + three-key EDE Triple-DES block cipher algorithm. + +'GCRY_MAC_CMAC_CAMELLIA' + This is CMAC message authentication algorithm based on the Camellia + block cipher algorithm. + +'GCRY_MAC_CMAC_CAST5' + This is CMAC message authentication algorithm based on the + CAST128-5 block cipher algorithm. + +'GCRY_MAC_CMAC_BLOWFISH' + This is CMAC message authentication algorithm based on the Blowfish + block cipher algorithm. + +'GCRY_MAC_CMAC_TWOFISH' + This is CMAC message authentication algorithm based on the Twofish + block cipher algorithm. + +'GCRY_MAC_CMAC_SERPENT' + This is CMAC message authentication algorithm based on the Serpent + block cipher algorithm. + +'GCRY_MAC_CMAC_SEED' + This is CMAC message authentication algorithm based on the SEED + block cipher algorithm. + +'GCRY_MAC_CMAC_RFC2268' + This is CMAC message authentication algorithm based on the Ron's + Cipher 2 block cipher algorithm. + +'GCRY_MAC_CMAC_IDEA' + This is CMAC message authentication algorithm based on the IDEA + block cipher algorithm. + +'GCRY_MAC_CMAC_GOST28147' + This is CMAC message authentication algorithm based on the GOST + 28147-89 block cipher algorithm. + +'GCRY_MAC_CMAC_SM4' + This is CMAC message authentication algorithm based on the SM4 + block cipher algorithm. + +'GCRY_MAC_GMAC_AES' + This is GMAC (GCM mode based MAC) message authentication algorithm + based on the AES block cipher algorithm. + +'GCRY_MAC_GMAC_CAMELLIA' + This is GMAC message authentication algorithm based on the Camellia + block cipher algorithm. + +'GCRY_MAC_GMAC_TWOFISH' + This is GMAC message authentication algorithm based on the Twofish + block cipher algorithm. + +'GCRY_MAC_GMAC_SERPENT' + This is GMAC message authentication algorithm based on the Serpent + block cipher algorithm. + +'GCRY_MAC_GMAC_SEED' + This is GMAC message authentication algorithm based on the SEED + block cipher algorithm. + +'GCRY_MAC_POLY1305' + This is plain Poly1305 message authentication algorithm, used with + one-time key. + +'GCRY_MAC_POLY1305_AES' + This is Poly1305-AES message authentication algorithm, used with + key and one-time nonce. + +'GCRY_MAC_POLY1305_CAMELLIA' + This is Poly1305-Camellia message authentication algorithm, used + with key and one-time nonce. + +'GCRY_MAC_POLY1305_TWOFISH' + This is Poly1305-Twofish message authentication algorithm, used + with key and one-time nonce. + +'GCRY_MAC_POLY1305_SERPENT' + This is Poly1305-Serpent message authentication algorithm, used + with key and one-time nonce. + +'GCRY_MAC_POLY1305_SEED' + This is Poly1305-SEED message authentication algorithm, used with + key and one-time nonce. + +'GCRY_MAC_GOST28147_IMIT' + This is MAC construction defined in GOST 28147-89 (see RFC 5830 + Section 8). + + +File: gcrypt.info, Node: Working with MAC algorithms, Prev: Available MAC algorithms, Up: Message Authentication Codes + +8.2 Working with MAC algorithms +=============================== + +To use most of these function it is necessary to create a context; this +is done using: + + -- Function: gcry_error_t gcry_mac_open (gcry_mac_hd_t *HD, int ALGO, + unsigned int FLAGS, gcry_ctx_t CTX) + + Create a MAC object for algorithm ALGO. FLAGS may be given as an + bitwise OR of constants described below. HD is guaranteed to + either receive a valid handle or NULL. CTX is context object to + associate MAC object with. CTX maybe set to NULL. + + For a list of supported algorithms, see *note Available MAC + algorithms::. + + The flags allowed for MODE are: + + 'GCRY_MAC_FLAG_SECURE' + Allocate all buffers and the resulting MAC in "secure memory". + Use this if the MAC data is highly confidential. + + In order to use a handle for performing MAC algorithm operations, a +'key' has to be set first: + + -- Function: gcry_error_t gcry_mac_setkey (gcry_mac_hd_t H, const void + *KEY, size_t KEYLEN) + + Set the MAC key to the value of KEY of length KEYLEN bytes. With + HMAC algorithms, there is no restriction on the length of the key. + With CMAC algorithms, the length of the key is restricted to those + supported by the underlying block cipher. + + GMAC algorithms and Poly1305-with-cipher algorithms need +initialization vector to be set, which can be performed with function: + + -- Function: gcry_error_t gcry_mac_setiv (gcry_mac_hd_t H, const void + *IV, size_t IVLEN) + + Set the IV to the value of IV of length IVLEN bytes. + + After you are done with the MAC calculation, you should release the +resources by using: + + -- Function: void gcry_mac_close (gcry_mac_hd_t H) + + Release all resources of MAC context H. H should not be used after + a call to this function. A 'NULL' passed as H is ignored. The + function also clears all sensitive information associated with this + handle. + + Often you have to do several MAC operations using the same algorithm. +To avoid the overhead of creating and releasing context, a reset +function is provided: + + -- Function: gcry_error_t gcry_mac_reset (gcry_mac_hd_t H) + + Reset the current context to its initial state. This is + effectively identical to a close followed by an open and setting + same key. + + Note that gcry_mac_reset is implemented as a macro. + + Now that we have prepared everything to calculate MAC, it is time to +see how it is actually done. + + -- Function: gcry_error_t gcry_mac_write (gcry_mac_hd_t H, const void + *BUFFER, size_t LENGTH) + + Pass LENGTH bytes of the data in BUFFER to the MAC object with + handle H to update the MAC values. If this function is used after + the context has been finalized, it will keep on pushing the data + through the algorithm specific transform function and thereby + change the context; however the results are not meaningful and this + feature is only available to mitigate timing attacks. + + The way to read out the calculated MAC is by using the function: + + -- Function: gcry_error_t gcry_mac_read (gcry_mac_hd_t H, void *BUFFER, + size_t *LENGTH) + + 'gcry_mac_read' returns the MAC after finalizing the calculation. + Function copies the resulting MAC value to BUFFER of the length + LENGTH. If LENGTH is larger than length of resulting MAC value, + then length of MAC is returned through LENGTH. + + To compare existing MAC value with recalculated MAC, one is to use +the function: + + -- Function: gcry_error_t gcry_mac_verify (gcry_mac_hd_t H, void + *BUFFER, size_t LENGTH) + + 'gcry_mac_verify' finalizes MAC calculation and compares result + with LENGTH bytes of data in BUFFER. Error code 'GPG_ERR_CHECKSUM' + is returned if the MAC value in the buffer BUFFER does not match + the MAC calculated in object H. + + In some situations it might be hard to remember the algorithm used +for the MAC calculation. The following function might be used to get +that information: + + -- Function: int gcry_mac_get_algo (gcry_mac_hd_t H) + + Retrieve the algorithm used with the handle H. + + MAC algorithms are identified by internal algorithm numbers (see +'gcry_mac_open' for a list). However, in most applications they are +used by names, so two functions are available to map between string +representations and MAC algorithm identifiers. + + -- Function: const char * gcry_mac_algo_name (int ALGO) + + Map the MAC algorithm id ALGO to a string representation of the + algorithm name. For unknown algorithms this function returns the + string '"?"'. This function should not be used to test for the + availability of an algorithm. + + -- Function: int gcry_mac_map_name (const char *NAME) + + Map the algorithm with NAME to a MAC algorithm identifier. Returns + 0 if the algorithm name is not known. This function should not be + used to test for the availability of an algorithm. + + To test whether an algorithm is actually available for use, the +following macro should be used: + + -- Function: gcry_error_t gcry_mac_test_algo (int ALGO) + + The macro returns 0 if the MAC algorithm ALGO is available for use. + + If the length of a message digest is not known, it can be retrieved +using the following function: + + -- Function: unsigned int gcry_mac_get_algo_maclen (int ALGO) + + Retrieve the length in bytes of the MAC yielded by algorithm ALGO. + This is often used prior to 'gcry_mac_read' to allocate sufficient + memory for the MAC value. On error '0' is returned. + + -- Function: unsigned int gcry_mac_get_algo_keylen (ALGO) + + This function returns length of the key for MAC algorithm ALGO. If + the algorithm supports multiple key lengths, the default supported + key length is returned. On error '0' is returned. The key length + is returned as number of octets. + + +File: gcrypt.info, Node: Key Derivation, Next: Random Numbers, Prev: Message Authentication Codes, Up: Top + +9 Key Derivation +**************** + +Libgcypt provides a general purpose function to derive keys from +strings. + + -- Function: gpg_error_t gcry_kdf_derive ( const void *PASSPHRASE, + size_t PASSPHRASELEN, int ALGO, int SUBALGO, const void *SALT, + size_t SALTLEN, unsigned long ITERATIONS, size_t KEYSIZE, + void *KEYBUFFER ) + + Derive a key from a passphrase. KEYSIZE gives the requested size + of the keys in octets. KEYBUFFER is a caller provided buffer + filled on success with the derived key. The input passphrase is + taken from PASSPHRASE which is an arbitrary memory buffer of + PASSPHRASELEN octets. ALGO specifies the KDF algorithm to use; see + below. SUBALGO specifies an algorithm used internally by the KDF + algorithms; this is usually a hash algorithm but certain KDF + algorithms may use it differently. SALT is a salt of length + SALTLEN octets, as needed by most KDF algorithms. ITERATIONS is a + positive integer parameter to most KDFs. + + On success 0 is returned; on failure an error code. + + Currently supported KDFs (parameter ALGO): + + 'GCRY_KDF_SIMPLE_S2K' + The OpenPGP simple S2K algorithm (cf. RFC4880). Its use is + strongly deprecated. SALT and ITERATIONS are not needed and + may be passed as 'NULL'/'0'. + + 'GCRY_KDF_SALTED_S2K' + The OpenPGP salted S2K algorithm (cf. RFC4880). Usually not + used. ITERATIONS is not needed and may be passed as '0'. + SALTLEN must be given as 8. + + 'GCRY_KDF_ITERSALTED_S2K' + The OpenPGP iterated+salted S2K algorithm (cf. RFC4880). + This is the default for most OpenPGP applications. SALTLEN + must be given as 8. Note that OpenPGP defines a special + encoding of the ITERATIONS; however this function takes the + plain decoded iteration count. + + 'GCRY_KDF_PBKDF2' + The PKCS#5 Passphrase Based Key Derivation Function number 2. + + 'GCRY_KDF_SCRYPT' + The SCRYPT Key Derivation Function. The subalgorithm is used + to specify the CPU/memory cost parameter N, and the number of + iterations is used for the parallelization parameter p. The + block size is fixed at 8 in the current implementation. + + +File: gcrypt.info, Node: Random Numbers, Next: S-expressions, Prev: Key Derivation, Up: Top + +10 Random Numbers +***************** + +* Menu: + +* Quality of random numbers:: Libgcrypt uses different quality levels. +* Retrieving random numbers:: How to retrieve random numbers. + + +File: gcrypt.info, Node: Quality of random numbers, Next: Retrieving random numbers, Up: Random Numbers + +10.1 Quality of random numbers +============================== + +Libgcypt offers random numbers of different quality levels: + + -- Data type: gcry_random_level_t + The constants for the random quality levels are of this enum type. + +'GCRY_WEAK_RANDOM' + For all functions, except for 'gcry_mpi_randomize', this level maps + to GCRY_STRONG_RANDOM. If you do not want this, consider using + 'gcry_create_nonce'. +'GCRY_STRONG_RANDOM' + Use this level for session keys and similar purposes. +'GCRY_VERY_STRONG_RANDOM' + Use this level for long term key material. + + +File: gcrypt.info, Node: Retrieving random numbers, Prev: Quality of random numbers, Up: Random Numbers + +10.2 Retrieving random numbers +============================== + + -- Function: void gcry_randomize (unsigned char *BUFFER, size_t LENGTH, + enum gcry_random_level LEVEL) + + Fill BUFFER with LENGTH random bytes using a random quality as + defined by LEVEL. + + -- Function: void * gcry_random_bytes (size_t NBYTES, enum + gcry_random_level LEVEL) + + Convenience function to allocate a memory block consisting of + NBYTES fresh random bytes using a random quality as defined by + LEVEL. + + -- Function: void * gcry_random_bytes_secure (size_t NBYTES, enum + gcry_random_level LEVEL) + + Convenience function to allocate a memory block consisting of + NBYTES fresh random bytes using a random quality as defined by + LEVEL. This function differs from 'gcry_random_bytes' in that the + returned buffer is allocated in a "secure" area of the memory. + + -- Function: void gcry_create_nonce (unsigned char *BUFFER, size_t + LENGTH) + + Fill BUFFER with LENGTH unpredictable bytes. This is commonly + called a nonce and may also be used for initialization vectors and + padding. This is an extra function nearly independent of the other + random function for 3 reasons: It better protects the regular + random generator's internal state, provides better performance and + does not drain the precious entropy pool. + + +File: gcrypt.info, Node: S-expressions, Next: MPI library, Prev: Random Numbers, Up: Top + +11 S-expressions +**************** + +S-expressions are used by the public key functions to pass complex data +structures around. These LISP like objects are used by some +cryptographic protocols (cf. RFC-2692) and Libgcrypt provides functions +to parse and construct them. For detailed information, see 'Ron Rivest, +code and description of S-expressions, +<http://theory.lcs.mit.edu/~rivest/sexp.html>'. + +* Menu: + +* Data types for S-expressions:: Data types related with S-expressions. +* Working with S-expressions:: How to work with S-expressions. + + +File: gcrypt.info, Node: Data types for S-expressions, Next: Working with S-expressions, Up: S-expressions + +11.1 Data types for S-expressions +================================= + + -- Data type: gcry_sexp_t + The 'gcry_sexp_t' type describes an object with the Libgcrypt + internal representation of an S-expression. + + +File: gcrypt.info, Node: Working with S-expressions, Prev: Data types for S-expressions, Up: S-expressions + +11.2 Working with S-expressions +=============================== + +There are several functions to create an Libgcrypt S-expression object +from its external representation or from a string template. There is +also a function to convert the internal representation back into one of +the external formats: + + -- Function: gcry_error_t gcry_sexp_new (gcry_sexp_t *R_SEXP, + const void *BUFFER, size_t LENGTH, int AUTODETECT) + + This is the generic function to create an new S-expression object + from its external representation in BUFFER of LENGTH bytes. On + success the result is stored at the address given by R_SEXP. With + AUTODETECT set to 0, the data in BUFFER is expected to be in + canonized format, with AUTODETECT set to 1 the parses any of the + defined external formats. If BUFFER does not hold a valid + S-expression an error code is returned and R_SEXP set to 'NULL'. + Note that the caller is responsible for releasing the newly + allocated S-expression using 'gcry_sexp_release'. + + -- Function: gcry_error_t gcry_sexp_create (gcry_sexp_t *R_SEXP, + void *BUFFER, size_t LENGTH, int AUTODETECT, + void (*FREEFNC)(void*)) + + This function is identical to 'gcry_sexp_new' but has an extra + argument FREEFNC, which, when not set to 'NULL', is expected to be + a function to release the BUFFER; most likely the standard 'free' + function is used for this argument. This has the effect of + transferring the ownership of BUFFER to the created object in + R_SEXP. The advantage of using this function is that Libgcrypt + might decide to directly use the provided buffer and thus avoid + extra copying. + + -- Function: gcry_error_t gcry_sexp_sscan (gcry_sexp_t *R_SEXP, + size_t *ERROFF, const char *BUFFER, size_t LENGTH) + + This is another variant of the above functions. It behaves nearly + identical but provides an ERROFF argument which will receive the + offset into the buffer where the parsing stopped on error. + + -- Function: gcry_error_t gcry_sexp_build (gcry_sexp_t *R_SEXP, + size_t *ERROFF, const char *FORMAT, ...) + + This function creates an internal S-expression from the string + template FORMAT and stores it at the address of R_SEXP. If there + is a parsing error, the function returns an appropriate error code + and stores the offset into FORMAT where the parsing stopped in + ERROFF. The function supports a couple of printf-like formatting + characters and expects arguments for some of these escape sequences + right after FORMAT. The following format characters are defined: + + '%m' + The next argument is expected to be of type 'gcry_mpi_t' and a + copy of its value is inserted into the resulting S-expression. + The MPI is stored as a signed integer. + '%M' + The next argument is expected to be of type 'gcry_mpi_t' and a + copy of its value is inserted into the resulting S-expression. + The MPI is stored as an unsigned integer. + '%s' + The next argument is expected to be of type 'char *' and that + string is inserted into the resulting S-expression. + '%d' + The next argument is expected to be of type 'int' and its + value is inserted into the resulting S-expression. + '%u' + The next argument is expected to be of type 'unsigned int' and + its value is inserted into the resulting S-expression. + '%b' + The next argument is expected to be of type 'int' directly + followed by an argument of type 'char *'. This represents a + buffer of given length to be inserted into the resulting + S-expression. + '%S' + The next argument is expected to be of type 'gcry_sexp_t' and + a copy of that S-expression is embedded in the resulting + S-expression. The argument needs to be a regular + S-expression, starting with a parenthesis. + + No other format characters are defined and would return an error. + Note that the format character '%%' does not exists, because a + percent sign is not a valid character in an S-expression. + + -- Function: void gcry_sexp_release (gcry_sexp_t SEXP) + + Release the S-expression object SEXP. If the S-expression is + stored in secure memory it explicitly zeroises that memory; note + that this is done in addition to the zeroisation always done when + freeing secure memory. + +The next 2 functions are used to convert the internal representation +back into a regular external S-expression format and to show the +structure for debugging. + + -- Function: size_t gcry_sexp_sprint (gcry_sexp_t SEXP, int MODE, + char *BUFFER, size_t MAXLENGTH) + + Copies the S-expression object SEXP into BUFFER using the format + specified in MODE. MAXLENGTH must be set to the allocated length + of BUFFER. The function returns the actual length of valid bytes + put into BUFFER or 0 if the provided buffer is too short. Passing + 'NULL' for BUFFER returns the required length for BUFFER. For + convenience reasons an extra byte with value 0 is appended to the + buffer. + + The following formats are supported: + + 'GCRYSEXP_FMT_DEFAULT' + Returns a convenient external S-expression representation. + + 'GCRYSEXP_FMT_CANON' + Return the S-expression in canonical format. + + 'GCRYSEXP_FMT_BASE64' + Not currently supported. + + 'GCRYSEXP_FMT_ADVANCED' + Returns the S-expression in advanced format. + + -- Function: void gcry_sexp_dump (gcry_sexp_t SEXP) + + Dumps SEXP in a format suitable for debugging to Libgcrypt's + logging stream. + +Often canonical encoding is used in the external representation. The +following function can be used to check for valid encoding and to learn +the length of the S-expression. + + -- Function: size_t gcry_sexp_canon_len (const unsigned char *BUFFER, + size_t LENGTH, size_t *ERROFF, int *ERRCODE) + + Scan the canonical encoded BUFFER with implicit length values and + return the actual length this S-expression uses. For a valid + S-expression it should never return 0. If LENGTH is not 0, the + maximum length to scan is given; this can be used for syntax checks + of data passed from outside. ERRCODE and ERROFF may both be passed + as 'NULL'. + +There are functions to parse S-expressions and retrieve elements: + + -- Function: gcry_sexp_t gcry_sexp_find_token (const gcry_sexp_t LIST, + const char *TOKEN, size_t TOKLEN) + + Scan the S-expression for a sublist with a type (the car of the + list) matching the string TOKEN. If TOKLEN is not 0, the token is + assumed to be raw memory of this length. The function returns a + newly allocated S-expression consisting of the found sublist or + 'NULL' when not found. + + -- Function: int gcry_sexp_length (const gcry_sexp_t LIST) + + Return the length of the LIST. For a valid S-expression this + should be at least 1. + + -- Function: gcry_sexp_t gcry_sexp_nth (const gcry_sexp_t LIST, + int NUMBER) + + Create and return a new S-expression from the element with index + NUMBER in LIST. Note that the first element has the index 0. If + there is no such element, 'NULL' is returned. + + -- Function: gcry_sexp_t gcry_sexp_car (const gcry_sexp_t LIST) + + Create and return a new S-expression from the first element in + LIST; this is called the "type" and should always exist per + S-expression specification and in general be a string. 'NULL' is + returned in case of a problem. + + -- Function: gcry_sexp_t gcry_sexp_cdr (const gcry_sexp_t LIST) + + Create and return a new list form all elements except for the first + one. Note that this function may return an invalid S-expression + because it is not guaranteed, that the type exists and is a string. + However, for parsing a complex S-expression it might be useful for + intermediate lists. Returns 'NULL' on error. + + -- Function: const char * gcry_sexp_nth_data (const gcry_sexp_t LIST, + int NUMBER, size_t *DATALEN) + + This function is used to get data from a LIST. A pointer to the + actual data with index NUMBER is returned and the length of this + data will be stored to DATALEN. If there is no data at the given + index or the index represents another list, 'NULL' is returned. + *Caution:* The returned pointer is valid as long as LIST is not + modified or released. + + Here is an example on how to extract and print the surname (Meier) + from the S-expression '(Name Otto Meier (address Burgplatz 3))': + + size_t len; + const char *name; + + name = gcry_sexp_nth_data (list, 2, &len); + printf ("my name is %.*s\n", (int)len, name); + + -- Function: void * gcry_sexp_nth_buffer (const gcry_sexp_t LIST, + int NUMBER, size_t *RLENGTH) + + This function is used to get data from a LIST. A malloced buffer + with the actual data at list index NUMBER is returned and the + length of this buffer will be stored to RLENGTH. If there is no + data at the given index or the index represents another list, + 'NULL' is returned. The caller must release the result using + 'gcry_free'. + + Here is an example on how to extract and print the CRC value from + the S-expression '(hash crc32 #23ed00d7)': + + size_t len; + char *value; + + value = gcry_sexp_nth_buffer (list, 2, &len); + if (value) + fwrite (value, len, 1, stdout); + gcry_free (value); + + -- Function: char * gcry_sexp_nth_string (gcry_sexp_t LIST, int NUMBER) + + This function is used to get and convert data from a LIST. The + data is assumed to be a Nul terminated string. The caller must + release this returned value using 'gcry_free'. If there is no data + at the given index, the index represents a list or the value can't + be converted to a string, 'NULL' is returned. + + -- Function: gcry_mpi_t gcry_sexp_nth_mpi (gcry_sexp_t LIST, + int NUMBER, int MPIFMT) + + This function is used to get and convert data from a LIST. This + data is assumed to be an MPI stored in the format described by + MPIFMT and returned as a standard Libgcrypt MPI. The caller must + release this returned value using 'gcry_mpi_release'. If there is + no data at the given index, the index represents a list or the + value can't be converted to an MPI, 'NULL' is returned. If you use + this function to parse results of a public key function, you most + likely want to use 'GCRYMPI_FMT_USG'. + + -- Function: gpg_error_t gcry_sexp_extract_param ( gcry_sexp_t SEXP, + const char *PATH, const char *LIST, ...) + + Extract parameters from an S-expression using a list of parameter + names. The names of these parameters are specified in LIST. White + space between the parameter names are ignored. Some special + characters and character sequences may be given to control the + conversion: + + '+' + Switch to unsigned integer format (GCRYMPI_FMT_USG). This is + the default mode. + '-' + Switch to standard signed format (GCRYMPI_FMT_STD). + '/' + Switch to opaque MPI format. The resulting MPIs may not be + used for computations; see 'gcry_mpi_get_opaque' for details. + '&' + Switch to buffer descriptor mode. See below for details. + '%s' + Switch to string mode. The expected argument is the address + of a 'char *' variable; the caller must release that value. + If the parameter was marked optional and is not found, NULL is + stored. + '%#s' + Switch to multi string mode. The expected argument is the + address of a 'char *' variable; the caller must release that + value. If the parameter was marked optional and is not found, + NULL is stored. A multi string takes all values, assumes they + are strings and concatenates them using a space as delimiter. + In case a value is actually another list this is not further + parsed but a '()' is inserted in place of that sublist. + '%u' + Switch to unsigned integer mode. The expected argument is + address of a 'unsigned int' variable. + '%lu' + Switch to unsigned long integer mode. The expected argument + is address of a 'unsigned long' variable. + '%d' + Switch to signed integer mode. The expected argument is + address of a 'int' variable. + '%ld' + Switch to signed long integer mode. The expected argument is + address of a 'long' variable. + '%zu' + Switch to size_t mode. The expected argument is address of a + 'size_t' variable. + '?' + If immediately following a parameter letter (no white space + allowed), that parameter is considered optional. + + In general parameter names are single letters. To use a string for + a parameter name, enclose the name in single quotes. + + Unless in buffer descriptor mode for each parameter name a pointer + to an 'gcry_mpi_t' variable is expected that must be set to 'NULL' + prior to invoking this function, and finally a 'NULL' is expected. + For example + + gcry_sexp_extract_param (key, NULL, "n/x+e d-'foo'", + &mpi_n, &mpi_x, &mpi_e, &mpi_d, &mpi_foo, NULL) + + stores the parameter 'n' from KEY as an unsigned MPI into MPI_N, + the parameter 'x' as an opaque MPI into MPI_X, the parameters 'e' + and 'd' again as an unsigned MPI into MPI_E and MPI_D and finally + the parameter 'foo' as a signed MPI into MPI_FOO. + + PATH is an optional string used to locate a token. The exclamation + mark separated tokens are used via 'gcry_sexp_find_token' to find a + start point inside the S-expression. + + In buffer descriptor mode a pointer to a 'gcry_buffer_t' descriptor + is expected instead of a pointer to an MPI. The caller may use two + different operation modes here: If the DATA field of the provided + descriptor is 'NULL', the function allocates a new buffer and + stores it at DATA; the other fields are set accordingly with OFF + set to 0. If DATA is not 'NULL', the function assumes that the + DATA, SIZE, and OFF fields specify a buffer where to but the value + of the respective parameter; on return the LEN field receives the + number of bytes copied to that buffer; in case the buffer is too + small, the function immediately returns with an error code (and LEN + is set to 0). + + The function returns 0 on success. On error an error code is + returned, all passed MPIs that might have been allocated up to this + point are deallocated and set to 'NULL', and all passed buffers are + either truncated if the caller supplied the buffer, or deallocated + if the function allocated the buffer. + + +File: gcrypt.info, Node: MPI library, Next: Prime numbers, Prev: S-expressions, Up: Top + +12 MPI library +************** + +* Menu: + +* Data types:: MPI related data types. +* Basic functions:: First steps with MPI numbers. +* MPI formats:: External representation of MPIs. +* Calculations:: Performing MPI calculations. +* Comparisons:: How to compare MPI values. +* Bit manipulations:: How to access single bits of MPI values. +* EC functions:: Elliptic curve related functions. +* Miscellaneous:: Miscellaneous MPI functions. + +Public key cryptography is based on mathematics with large numbers. To +implement the public key functions, a library for handling these large +numbers is required. Because of the general usefulness of such a +library, its interface is exposed by Libgcrypt. In the context of +Libgcrypt and in most other applications, these large numbers are called +MPIs (multi-precision-integers). + + +File: gcrypt.info, Node: Data types, Next: Basic functions, Up: MPI library + +12.1 Data types +=============== + + -- Data type: gcry_mpi_t + This type represents an object to hold an MPI. + + -- Data type: gcry_mpi_point_t + This type represents an object to hold a point for elliptic curve + math. + + +File: gcrypt.info, Node: Basic functions, Next: MPI formats, Prev: Data types, Up: MPI library + +12.2 Basic functions +==================== + +To work with MPIs, storage must be allocated and released for the +numbers. This can be done with one of these functions: + + -- Function: gcry_mpi_t gcry_mpi_new (unsigned int NBITS) + + Allocate a new MPI object, initialize it to 0 and initially + allocate enough memory for a number of at least NBITS. This + pre-allocation is only a small performance issue and not actually + necessary because Libgcrypt automatically re-allocates the required + memory. + + -- Function: gcry_mpi_t gcry_mpi_snew (unsigned int NBITS) + + This is identical to 'gcry_mpi_new' but allocates the MPI in the so + called "secure memory" which in turn will take care that all + derived values will also be stored in this "secure memory". Use + this for highly confidential data like private key parameters. + + -- Function: gcry_mpi_t gcry_mpi_copy (const gcry_mpi_t A) + + Create a new MPI as the exact copy of A but with the constant and + immutable flags cleared. + + -- Function: void gcry_mpi_release (gcry_mpi_t A) + + Release the MPI A and free all associated resources. Passing + 'NULL' is allowed and ignored. When a MPI stored in the "secure + memory" is released, that memory gets wiped out immediately. + +The simplest operations are used to assign a new value to an MPI: + + -- Function: gcry_mpi_t gcry_mpi_set (gcry_mpi_t W, const gcry_mpi_t U) + + Assign the value of U to W and return W. If 'NULL' is passed for + W, a new MPI is allocated, set to the value of U and returned. + + -- Function: gcry_mpi_t gcry_mpi_set_ui (gcry_mpi_t W, unsigned long U) + + Assign the value of U to W and return W. If 'NULL' is passed for + W, a new MPI is allocated, set to the value of U and returned. + This function takes an 'unsigned int' as type for U and thus it is + only possible to set W to small values (usually up to the word size + of the CPU). + + -- Function: gcry_error_t gcry_mpi_get_ui (unsigned int *W, + gcry_mpi_t U) + + If U is not negative and small enough to be stored in an 'unsigned + int' variable, store its value at W. If the value does not fit or + is negative return GPG_ERR_ERANGE and do not change the value + stored at W. Note that this function returns an 'unsigned int' so + that this value can immediately be used with the bit test + functions. This is in contrast to the other "_ui" functions which + allow for values up to an 'unsigned long'. + + -- Function: void gcry_mpi_swap (gcry_mpi_t A, gcry_mpi_t B) + + Swap the values of A and B. + + -- Function: void gcry_mpi_snatch (gcry_mpi_t W, const gcry_mpi_t U) + + Set U into W and release U. If W is 'NULL' only U will be + released. + + -- Function: void gcry_mpi_neg (gcry_mpi_t W, gcry_mpi_t U) + + Set the sign of W to the negative of U. + + -- Function: void gcry_mpi_abs (gcry_mpi_t W) + + Clear the sign of W. + + +File: gcrypt.info, Node: MPI formats, Next: Calculations, Prev: Basic functions, Up: MPI library + +12.3 MPI formats +================ + +The following functions are used to convert between an external +representation of an MPI and the internal one of Libgcrypt. + + -- Function: gcry_error_t gcry_mpi_scan (gcry_mpi_t *R_MPI, + enum gcry_mpi_format FORMAT, const unsigned char *BUFFER, + size_t BUFLEN, size_t *NSCANNED) + + Convert the external representation of an integer stored in BUFFER + with a length of BUFLEN into a newly created MPI returned which + will be stored at the address of R_MPI. For certain formats the + length argument is not required and should be passed as '0'. A + BUFLEN larger than 16 MiByte will be rejected. After a successful + operation the variable NSCANNED receives the number of bytes + actually scanned unless NSCANNED was given as 'NULL'. FORMAT + describes the format of the MPI as stored in BUFFER: + + 'GCRYMPI_FMT_STD' + 2-complement stored without a length header. Note that + 'gcry_mpi_print' stores a '0' as a string of zero length. + + 'GCRYMPI_FMT_PGP' + As used by OpenPGP (only defined as unsigned). This is + basically 'GCRYMPI_FMT_STD' with a 2 byte big endian length + header. A length header indicating a length of more than + 16384 is not allowed. + + 'GCRYMPI_FMT_SSH' + As used in the Secure Shell protocol. This is + 'GCRYMPI_FMT_STD' with a 4 byte big endian header. + + 'GCRYMPI_FMT_HEX' + Stored as a string with each byte of the MPI encoded as 2 hex + digits. Negative numbers are prefix with a minus sign and in + addition the high bit is always zero to make clear that an + explicit sign ist used. When using this format, BUFLEN must + be zero. + + 'GCRYMPI_FMT_USG' + Simple unsigned integer. + + Note that all of the above formats store the integer in big-endian + format (MSB first). + + -- Function: gcry_error_t gcry_mpi_print (enum gcry_mpi_format FORMAT, + unsigned char *BUFFER, size_t BUFLEN, size_t *NWRITTEN, + const gcry_mpi_t A) + + Convert the MPI A into an external representation described by + FORMAT (see above) and store it in the provided BUFFER which has a + usable length of at least the BUFLEN bytes. If NWRITTEN is not + NULL, it will receive the number of bytes actually stored in BUFFER + after a successful operation. + + -- Function: gcry_error_t gcry_mpi_aprint (enum gcry_mpi_format FORMAT, + unsigned char **BUFFER, size_t *NBYTES, const gcry_mpi_t A) + + Convert the MPI A into an external representation described by + FORMAT (see above) and store it in a newly allocated buffer which + address will be stored in the variable BUFFER points to. The + number of bytes stored in this buffer will be stored in the + variable NBYTES points to, unless NBYTES is 'NULL'. + + Even if NBYTES is zero, the function allocates at least one byte + and store a zero there. Thus with formats 'GCRYMPI_FMT_STD' and + 'GCRYMPI_FMT_USG' the caller may safely set a returned length of 0 + to 1 to represent a zero as a 1 byte string. + + -- Function: void gcry_mpi_dump (const gcry_mpi_t A) + + Dump the value of A in a format suitable for debugging to + Libgcrypt's logging stream. Note that one leading space but no + trailing space or linefeed will be printed. It is okay to pass + 'NULL' for A. + + +File: gcrypt.info, Node: Calculations, Next: Comparisons, Prev: MPI formats, Up: MPI library + +12.4 Calculations +================= + +Basic arithmetic operations: + + -- Function: void gcry_mpi_add (gcry_mpi_t W, gcry_mpi_t U, + gcry_mpi_t V) + + W = U + V. + + -- Function: void gcry_mpi_add_ui (gcry_mpi_t W, gcry_mpi_t U, + unsigned long V) + + W = U + V. Note that V is an unsigned integer. + + -- Function: void gcry_mpi_addm (gcry_mpi_t W, gcry_mpi_t U, + gcry_mpi_t V, gcry_mpi_t M) + + W = U + V \bmod M. + + -- Function: void gcry_mpi_sub (gcry_mpi_t W, gcry_mpi_t U, + gcry_mpi_t V) + + W = U - V. + + -- Function: void gcry_mpi_sub_ui (gcry_mpi_t W, gcry_mpi_t U, + unsigned long V) + + W = U - V. V is an unsigned integer. + + -- Function: void gcry_mpi_subm (gcry_mpi_t W, gcry_mpi_t U, + gcry_mpi_t V, gcry_mpi_t M) + + W = U - V \bmod M. + + -- Function: void gcry_mpi_mul (gcry_mpi_t W, gcry_mpi_t U, + gcry_mpi_t V) + + W = U * V. + + -- Function: void gcry_mpi_mul_ui (gcry_mpi_t W, gcry_mpi_t U, + unsigned long V) + + W = U * V. V is an unsigned integer. + + -- Function: void gcry_mpi_mulm (gcry_mpi_t W, gcry_mpi_t U, + gcry_mpi_t V, gcry_mpi_t M) + + W = U * V \bmod M. + + -- Function: void gcry_mpi_mul_2exp (gcry_mpi_t W, gcry_mpi_t U, + unsigned long E) + + W = U * 2^e. + + -- Function: void gcry_mpi_div (gcry_mpi_t Q, gcry_mpi_t R, + gcry_mpi_t DIVIDEND, gcry_mpi_t DIVISOR, int ROUND) + + Q = DIVIDEND / DIVISOR, R = DIVIDEND \bmod DIVISOR. Q and R may be + passed as 'NULL'. ROUND is either negative for floored division + (rounds towards the next lower integer) or zero for truncated + division (rounds towards zero). + + -- Function: void gcry_mpi_mod (gcry_mpi_t R, gcry_mpi_t DIVIDEND, + gcry_mpi_t DIVISOR) + + R = DIVIDEND \bmod DIVISOR. + + -- Function: void gcry_mpi_powm (gcry_mpi_t W, const gcry_mpi_t B, + const gcry_mpi_t E, const gcry_mpi_t M) + + W = B^e \bmod M. + + -- Function: int gcry_mpi_gcd (gcry_mpi_t G, gcry_mpi_t A, + gcry_mpi_t B) + + Set G to the greatest common divisor of A and B. Return true if + the G is 1. + + -- Function: int gcry_mpi_invm (gcry_mpi_t X, gcry_mpi_t A, + gcry_mpi_t M) + + Set X to the multiplicative inverse of A \bmod M. Return true if + the inverse exists. + + +File: gcrypt.info, Node: Comparisons, Next: Bit manipulations, Prev: Calculations, Up: MPI library + +12.5 Comparisons +================ + +The next 2 functions are used to compare MPIs: + + -- Function: int gcry_mpi_cmp (const gcry_mpi_t U, const gcry_mpi_t V) + + Compare the multi-precision-integers number U and V returning 0 for + equality, a positive value for U > V and a negative for U < V. If + both numbers are opaque values (cf, gcry_mpi_set_opaque) the + comparison is done by checking the bit sizes using memcmp. If only + one number is an opaque value, the opaque value is less than the + other number. + + -- Function: int gcry_mpi_cmp_ui (const gcry_mpi_t U, unsigned long V) + + Compare the multi-precision-integers number U with the unsigned + integer V returning 0 for equality, a positive value for U > V and + a negative for U < V. + + -- Function: int gcry_mpi_is_neg (const gcry_mpi_t A) + + Return 1 if A is less than zero; return 0 if zero or positive. + + +File: gcrypt.info, Node: Bit manipulations, Next: EC functions, Prev: Comparisons, Up: MPI library + +12.6 Bit manipulations +====================== + +There are a couple of functions to get information on arbitrary bits in +an MPI and to set or clear them: + + -- Function: unsigned int gcry_mpi_get_nbits (gcry_mpi_t A) + + Return the number of bits required to represent A. + + -- Function: int gcry_mpi_test_bit (gcry_mpi_t A, unsigned int N) + + Return true if bit number N (counting from 0) is set in A. + + -- Function: void gcry_mpi_set_bit (gcry_mpi_t A, unsigned int N) + + Set bit number N in A. + + -- Function: void gcry_mpi_clear_bit (gcry_mpi_t A, unsigned int N) + + Clear bit number N in A. + + -- Function: void gcry_mpi_set_highbit (gcry_mpi_t A, unsigned int N) + + Set bit number N in A and clear all bits greater than N. + + -- Function: void gcry_mpi_clear_highbit (gcry_mpi_t A, unsigned int N) + + Clear bit number N in A and all bits greater than N. + + -- Function: void gcry_mpi_rshift (gcry_mpi_t X, gcry_mpi_t A, + unsigned int N) + + Shift the value of A by N bits to the right and store the result in + X. + + -- Function: void gcry_mpi_lshift (gcry_mpi_t X, gcry_mpi_t A, + unsigned int N) + + Shift the value of A by N bits to the left and store the result in + X. + + +File: gcrypt.info, Node: EC functions, Next: Miscellaneous, Prev: Bit manipulations, Up: MPI library + +12.7 EC functions +================= + +Libgcrypt provides an API to access low level functions used by its +elliptic curve implementation. These functions allow to implement +elliptic curve methods for which no explicit support is available. + + -- Function: gcry_mpi_point_t gcry_mpi_point_new (unsigned int NBITS) + + Allocate a new point object, initialize it to 0, and allocate + enough memory for a points of at least NBITS. This pre-allocation + yields only a small performance win and is not really necessary + because Libgcrypt automatically re-allocates the required memory. + Using 0 for NBITS is usually the right thing to do. + + -- Function: void gcry_mpi_point_release (gcry_mpi_point_t POINT) + + Release POINT and free all associated resources. Passing 'NULL' is + allowed and ignored. + + -- Function: gcry_mpi_point_t gcry_mpi_point_copy + (gcry_mpi_point_t POINT) + + Allocate and return a new point object and initialize it with + POINT. If POINT is NULL the function is identical to + 'gcry_mpi_point_new(0)'. + + -- Function: void gcry_mpi_point_get (gcry_mpi_t X, gcry_mpi_t Y, + gcry_mpi_t Z, gcry_mpi_point_t POINT) + + Store the projective coordinates from POINT into the MPIs X, Y, and + Z. If a coordinate is not required, 'NULL' may be used for X, Y, + or Z. + + -- Function: void gcry_mpi_point_snatch_get (gcry_mpi_t X, + gcry_mpi_t Y, gcry_mpi_t Z, gcry_mpi_point_t POINT) + + Store the projective coordinates from POINT into the MPIs X, Y, and + Z. If a coordinate is not required, 'NULL' may be used for X, Y, + or Z. The object POINT is then released. Using this function + instead of 'gcry_mpi_point_get' and 'gcry_mpi_point_release' has + the advantage of avoiding some extra memory allocations and copies. + + -- Function: gcry_mpi_point_t gcry_mpi_point_set ( + gcry_mpi_point_t POINT, gcry_mpi_t X, gcry_mpi_t Y, + gcry_mpi_t Z) + + Store the projective coordinates from X, Y, and Z into POINT. If a + coordinate is given as 'NULL', the value 0 is used. If 'NULL' is + used for POINT a new point object is allocated and returned. + Returns POINT or the newly allocated point object. + + -- Function: gcry_mpi_point_t gcry_mpi_point_snatch_set ( + gcry_mpi_point_t POINT, gcry_mpi_t X, gcry_mpi_t Y, + gcry_mpi_t Z) + + Store the projective coordinates from X, Y, and Z into POINT. If a + coordinate is given as 'NULL', the value 0 is used. If 'NULL' is + used for POINT a new point object is allocated and returned. The + MPIs X, Y, and Z are released. Using this function instead of + 'gcry_mpi_point_set' and 3 calls to 'gcry_mpi_release' has the + advantage of avoiding some extra memory allocations and copies. + Returns POINT or the newly allocated point object. + + -- Function: gpg_error_t gcry_mpi_ec_new (gcry_ctx_t *R_CTX, + gcry_sexp_t KEYPARAM, const char *CURVENAME) + + Allocate a new context for elliptic curve operations. If KEYPARAM + is given it specifies the parameters of the curve (*note + ecc_keyparam::). If CURVENAME is given in addition to KEYPARAM and + the key parameters do not include a named curve reference, the + string CURVENAME is used to fill in missing parameters. If only + CURVENAME is given, the context is initialized for this named + curve. + + If a parameter specifying a point (e.g. 'g' or 'q') is not found, + the parser looks for a non-encoded point by appending '.x', '.y', + and '.z' to the parameter name and looking them all up to create a + point. A parameter with the suffix '.z' is optional and defaults + to 1. + + On success the function returns 0 and stores the new context object + at R_CTX; this object eventually needs to be released (*note + gcry_ctx_release::). On error the function stores 'NULL' at R_CTX + and returns an error code. + + -- Function: gcry_mpi_t gcry_mpi_ec_get_mpi ( const char *NAME, + gcry_ctx_t CTX, int COPY) + + Return the MPI with NAME from the context CTX. If not found 'NULL' + is returned. If the returned MPI may later be modified, it is + suggested to pass '1' to COPY, so that the function guarantees that + a modifiable copy of the MPI is returned. If '0' is used for COPY, + this function may return a constant flagged MPI. In any case + 'gcry_mpi_release' needs to be called to release the result. For + valid names *note ecc_keyparam::. If the public key 'q' is + requested but only the private key 'd' is available, 'q' will be + recomputed on the fly. If a point parameter is requested it is + returned as an uncompressed encoded point unless these special + names are used: + Q@EDDSA + Return an EdDSA style compressed point. This is only + supported for Twisted Edwards curves. + + -- Function: gcry_mpi_point_t gcry_mpi_ec_get_point ( const char *NAME, + gcry_ctx_t CTX, int COPY) + + Return the point with NAME from the context CTX. If not found + 'NULL' is returned. If the returned MPI may later be modified, it + is suggested to pass '1' to COPY, so that the function guarantees + that a modifiable copy of the MPI is returned. If '0' is used for + COPY, this function may return a constant flagged point. In any + case 'gcry_mpi_point_release' needs to be called to release the + result. If the public key 'q' is requested but only the private + key 'd' is available, 'q' will be recomputed on the fly. + + -- Function: gpg_error_t gcry_mpi_ec_set_mpi ( const char *NAME, + gcry_mpi_t NEWVALUE, gcry_ctx_t CTX) + + Store the MPI NEWVALUE at NAME into the context CTX. On success + '0' is returned; on error an error code. Valid names are the MPI + parameters of an elliptic curve (*note ecc_keyparam::). + + -- Function: gpg_error_t gcry_mpi_ec_set_point ( const char *NAME, + gcry_mpi_point_t NEWVALUE, gcry_ctx_t CTX) + + Store the point NEWVALUE at NAME into the context CTX. On success + '0' is returned; on error an error code. Valid names are the point + parameters of an elliptic curve (*note ecc_keyparam::). + + -- Function: gpg_err_code_t gcry_mpi_ec_decode_point ( + mpi_point_t RESULT, gcry_mpi_t VALUE, gcry_ctx_t CTX) + + Decode the point given as an MPI in VALUE and store at RESULT. To + decide which encoding is used the function takes a context CTX + which can be created with 'gcry_mpi_ec_new'. If 'NULL' is given + for the context the function assumes a 0x04 prefixed uncompressed + encoding. On error an error code is returned and RESULT might be + changed. + + -- Function: int gcry_mpi_ec_get_affine ( gcry_mpi_t X, gcry_mpi_t Y, + gcry_mpi_point_t POINT, gcry_ctx_t CTX) + + Compute the affine coordinates from the projective coordinates in + POINT and store them into X and Y. If one coordinate is not + required, 'NULL' may be passed to X or Y. CTX is the context + object which has been created using 'gcry_mpi_ec_new'. Returns 0 + on success or not 0 if POINT is at infinity. + + Note that you can use 'gcry_mpi_ec_set_point' with the value + 'GCRYMPI_CONST_ONE' for Z to convert affine coordinates back into + projective coordinates. + + -- Function: void gcry_mpi_ec_dup ( gcry_mpi_point_t W, + gcry_mpi_point_t U, gcry_ctx_t CTX) + + Double the point U of the elliptic curve described by CTX and store + the result into W. + + -- Function: void gcry_mpi_ec_add ( gcry_mpi_point_t W, + gcry_mpi_point_t U, gcry_mpi_point_t V, gcry_ctx_t CTX) + + Add the points U and V of the elliptic curve described by CTX and + store the result into W. + + -- Function: void gcry_mpi_ec_sub ( gcry_mpi_point_t W, + gcry_mpi_point_t U, gcry_mpi_point_t V, gcry_ctx_t CTX) + + Subtracts the point V from the point U of the elliptic curve + described by CTX and store the result into W. Only Twisted Edwards + curves are supported for now. + + -- Function: void gcry_mpi_ec_mul ( gcry_mpi_point_t W, gcry_mpi_t N, + gcry_mpi_point_t U, gcry_ctx_t CTX) + + Multiply the point U of the elliptic curve described by CTX by N + and store the result into W. + + -- Function: int gcry_mpi_ec_curve_point ( gcry_mpi_point_t POINT, + gcry_ctx_t CTX) + + Return true if POINT is on the elliptic curve described by CTX. + + +File: gcrypt.info, Node: Miscellaneous, Prev: EC functions, Up: MPI library + +12.8 Miscellaneous +================== + +An MPI data type is allowed to be "misused" to store an arbitrary value. +Two functions implement this kludge: + + -- Function: gcry_mpi_t gcry_mpi_set_opaque (gcry_mpi_t A, void *P, + unsigned int NBITS) + + Store NBITS of the value P points to in A and mark A as an opaque + value (i.e. an value that can't be used for any math calculation + and is only used to store an arbitrary bit pattern in A). + Ownership of P is taken by this function and thus the user may not + use dereference the passed value anymore. It is required that them + memory referenced by P has been allocated in a way that 'gcry_free' + is able to release it. + + WARNING: Never use an opaque MPI for actual math operations. The + only valid functions are gcry_mpi_get_opaque and gcry_mpi_release. + Use gcry_mpi_scan to convert a string of arbitrary bytes into an + MPI. + + -- Function: gcry_mpi_t gcry_mpi_set_opaque_copy (gcry_mpi_t A, + const void *P, unsigned int NBITS) + + Same as 'gcry_mpi_set_opaque' but ownership of P is not taken + instead a copy of P is used. + + -- Function: void * gcry_mpi_get_opaque (gcry_mpi_t A, + unsigned int *NBITS) + + Return a pointer to an opaque value stored in A and return its size + in NBITS. Note that the returned pointer is still owned by A and + that the function should never be used for an non-opaque MPI. + + Each MPI has an associated set of flags for special purposes. The +currently defined flags are: + +'GCRYMPI_FLAG_SECURE' + Setting this flag converts A into an MPI stored in "secure memory". + Clearing this flag is not allowed. +'GCRYMPI_FLAG_OPAQUE' + This is an internal flag, indicating the an opaque valuue and not + an integer is stored. This is an read-only flag; it may not be set + or cleared. +'GCRYMPI_FLAG_IMMUTABLE' + If this flag is set, the MPI is marked as immutable. Setting or + changing the value of that MPI is ignored and an error message is + logged. The flag is sometimes useful for debugging. +'GCRYMPI_FLAG_CONST' + If this flag is set, the MPI is marked as a constant and as + immutable Setting or changing the value of that MPI is ignored and + an error message is logged. Such an MPI will never be deallocated + and may thus be used without copying. Note that using + gcry_mpi_copy will return a copy of that constant with this and the + immutable flag cleared. A few commonly used constants are + pre-defined and accessible using the macros 'GCRYMPI_CONST_ONE', + 'GCRYMPI_CONST_TWO', 'GCRYMPI_CONST_THREE', 'GCRYMPI_CONST_FOUR', + and 'GCRYMPI_CONST_EIGHT'. +'GCRYMPI_FLAG_USER1' +'GCRYMPI_FLAG_USER2' +'GCRYMPI_FLAG_USER3' +'GCRYMPI_FLAG_USER4' + These flags are reserved for use by the application. + + -- Function: void gcry_mpi_set_flag (gcry_mpi_t A, + enum gcry_mpi_flag FLAG) + + Set the FLAG for the MPI A. The only allowed flags are + 'GCRYMPI_FLAG_SECURE', 'GCRYMPI_FLAG_IMMUTABLE', and + 'GCRYMPI_FLAG_CONST'. + + -- Function: void gcry_mpi_clear_flag (gcry_mpi_t A, + enum gcry_mpi_flag FLAG) + + Clear FLAG for the multi-precision-integers A. The only allowed + flag is 'GCRYMPI_FLAG_IMMUTABLE' but only if 'GCRYMPI_FLAG_CONST' + is not set. If 'GCRYMPI_FLAG_CONST' is set, clearing + 'GCRYMPI_FLAG_IMMUTABLE' will simply be ignored. + o + -- Function: int gcry_mpi_get_flag (gcry_mpi_t A, + enum gcry_mpi_flag FLAG) + + Return true if FLAG is set for A. + + To put a random value into an MPI, the following convenience function +may be used: + + -- Function: void gcry_mpi_randomize (gcry_mpi_t W, unsigned int NBITS, + enum gcry_random_level LEVEL) + + Set the multi-precision-integers W to a random non-negative number + of NBITS, using random data quality of level LEVEL. In case NBITS + is not a multiple of a byte, NBITS is rounded up to the next byte + boundary. When using a LEVEL of 'GCRY_WEAK_RANDOM' this function + makes use of 'gcry_create_nonce'. + + +File: gcrypt.info, Node: Prime numbers, Next: Utilities, Prev: MPI library, Up: Top + +13 Prime numbers +**************** + +* Menu: + +* Generation:: Generation of new prime numbers. +* Checking:: Checking if a given number is prime. + + +File: gcrypt.info, Node: Generation, Next: Checking, Up: Prime numbers + +13.1 Generation +=============== + + -- Function: gcry_error_t gcry_prime_generate (gcry_mpi_t + *PRIME,unsigned int PRIME_BITS, unsigned int FACTOR_BITS, + gcry_mpi_t **FACTORS, gcry_prime_check_func_t CB_FUNC, void + *CB_ARG, gcry_random_level_t RANDOM_LEVEL, unsigned int FLAGS) + + Generate a new prime number of PRIME_BITS bits and store it in + PRIME. If FACTOR_BITS is non-zero, one of the prime factors of + (PRIME - 1) / 2 must be FACTOR_BITS bits long. If FACTORS is + non-zero, allocate a new, 'NULL'-terminated array holding the prime + factors and store it in FACTORS. FLAGS might be used to influence + the prime number generation process. + + -- Function: gcry_error_t gcry_prime_group_generator (gcry_mpi_t *R_G, + gcry_mpi_t PRIME, gcry_mpi_t *FACTORS, gcry_mpi_t START_G) + + Find a generator for PRIME where the factorization of (PRIME-1) is + in the 'NULL' terminated array FACTORS. Return the generator as a + newly allocated MPI in R_G. If START_G is not NULL, use this as + the start for the search. + + -- Function: void gcry_prime_release_factors (gcry_mpi_t *FACTORS) + + Convenience function to release the FACTORS array. + + +File: gcrypt.info, Node: Checking, Prev: Generation, Up: Prime numbers + +13.2 Checking +============= + + -- Function: gcry_error_t gcry_prime_check (gcry_mpi_t P, unsigned int + FLAGS) + + Check whether the number P is prime. Returns zero in case P is + indeed a prime, returns 'GPG_ERR_NO_PRIME' in case P is not a prime + and a different error code in case something went horribly wrong. + + +File: gcrypt.info, Node: Utilities, Next: Tools, Prev: Prime numbers, Up: Top + +14 Utilities +************ + +* Menu: + +* Memory allocation:: Functions related with memory allocation. +* Context management:: Functions related with context management. +* Buffer description:: A data type to describe buffers. +* Config reporting:: How to return Libgcrypt's configuration. + + +File: gcrypt.info, Node: Memory allocation, Next: Context management, Up: Utilities + +14.1 Memory allocation +====================== + + -- Function: void * gcry_malloc (size_t N) + + This function tries to allocate N bytes of memory. On success it + returns a pointer to the memory area, in an out-of-core condition, + it returns NULL. + + -- Function: void * gcry_malloc_secure (size_t N) + Like 'gcry_malloc', but uses secure memory. + + -- Function: void * gcry_calloc (size_t N, size_t M) + + This function allocates a cleared block of memory (i.e. + initialized with zero bytes) long enough to contain a vector of N + elements, each of size M bytes. On success it returns a pointer to + the memory block; in an out-of-core condition, it returns NULL. + + -- Function: void * gcry_calloc_secure (size_t N, size_t M) + Like 'gcry_calloc', but uses secure memory. + + -- Function: void * gcry_realloc (void *P, size_t N) + + This function tries to resize the memory area pointed to by P to N + bytes. On success it returns a pointer to the new memory area, in + an out-of-core condition, it returns NULL. Depending on whether the + memory pointed to by P is secure memory or not, gcry_realloc tries + to use secure memory as well. + + -- Function: void gcry_free (void *P) + Release the memory area pointed to by P. + + +File: gcrypt.info, Node: Context management, Next: Buffer description, Prev: Memory allocation, Up: Utilities + +14.2 Context management +======================= + +Some function make use of a context object. As of now there are only a +few math functions. However, future versions of Libgcrypt may make more +use of this context object. + + -- Data type: gcry_ctx_t + This type is used to refer to the general purpose context object. + + -- Function: void gcry_ctx_release (gcry_ctx_t CTX) + Release the context object CTX and all associated resources. A + 'NULL' passed as CTX is ignored. + + +File: gcrypt.info, Node: Buffer description, Next: Config reporting, Prev: Context management, Up: Utilities + +14.3 Buffer description +======================= + +To help hashing non-contiguous areas of memory a general purpose data +type is defined: + + -- Data type: gcry_buffer_t + This type is a structure to describe a buffer. The user should + make sure that this structure is initialized to zero. The + available fields of this structure are: + + '.size' + This is either 0 for no information available or indicates the + allocated length of the buffer. + '.off' + This is the offset into the buffer. + '.len' + This is the valid length of the buffer starting at '.off'. + '.data' + This is the address of the buffer. + + +File: gcrypt.info, Node: Config reporting, Prev: Buffer description, Up: Utilities + +14.4 How to return Libgcrypt's configuration. +============================================= + +Although 'GCRYCTL_PRINT_CONFIG' can be used to print configuration +options, it is sometimes necessary to check them in a program. This can +be accomplished by using this function: + + -- Function: char * gcry_get_config (int MODE, const char *WHAT) + + This function returns a malloced string with colon delimited + configure options. With a value of 0 for MODE this string + resembles the output of 'GCRYCTL_PRINT_CONFIG'. However, if WHAT + is not NULL, only the line where the first field (e.g. "cpu-arch") + matches WHAT is returned. + + Other values than 0 for MODE are not defined. The caller shall + free the string using 'gcry_free'. On error NULL is returned and + ERRNO is set; if a value for WHAT is unknow ERRNO will be set to 0. + + +File: gcrypt.info, Node: Tools, Next: Configuration, Prev: Utilities, Up: Top + +15 Tools +******** + +* Menu: + +* hmac256:: A standalone HMAC-SHA-256 implementation + + +File: gcrypt.info, Node: hmac256, Up: Tools + +15.1 A HMAC-SHA-256 tool +======================== + +This is a standalone HMAC-SHA-256 implementation used to compute an +HMAC-SHA-256 message authentication code. The tool has originally been +developed as a second implementation for Libgcrypt to allow comparing +against the primary implementation and to be used for internal +consistency checks. It should not be used for sensitive data because no +mechanisms to clear the stack etc are used. + + The code has been written in a highly portable manner and requires +only a few standard definitions to be provided in a config.h file. + +'hmac256' is commonly invoked as + + hmac256 "This is my key" foo.txt + +This compute the MAC on the file 'foo.txt' using the key given on the +command line. + +'hmac256' understands these options: + +'--binary' + Print the MAC as a binary string. The default is to print the MAC + encoded has lower case hex digits. + +'--version' + Print version of the program and exit. + + +File: gcrypt.info, Node: Configuration, Next: Architecture, Prev: Tools, Up: Top + +16 Configuration files and environment variables +************************************************ + +This chapter describes which files and environment variables can be used +to change the behaviour of Libgcrypt. + +The environment variables considered by Libgcrypt are: + +'GCRYPT_BARRETT' + By setting this variable to any value a different algorithm for + modular reduction is used for ECC. + +'GCRYPT_RNDUNIX_DBG' +'GCRYPT_RNDUNIX_DBGALL' + These two environment variables are used to enable debug output for + the rndunix entropy gatherer, which is used on systems lacking a + /dev/random device. The value of 'GCRYPT_RNDUNIX_DBG' is a file + name or '-' for stdout. Debug output is the written to this file. + By setting 'GCRYPT_RNDUNIX_DBGALL' to any value the debug output + will be more verbose. + +'GCRYPT_RNDW32_NOPERF' + Setting this environment variable on Windows to any value disables + the use of performance data ('HKEY_PERFORMANCE_DATA') as source for + entropy. On some older Windows systems this could help to speed up + the creation of random numbers but also decreases the amount of + data used to init the random number generator. + +'GCRYPT_RNDW32_DBG' + Setting the value of this variable to a positive integer logs + information about the Windows entropy gatherer using the standard + log interface. + +'HOME' + This is used to locate the socket to connect to the EGD random + daemon. The EGD can be used on system without a /dev/random to + speed up the random number generator. It is not needed on the + majority of today's operating systems and support for EGD requires + the use of a configure option at build time. + +The files which Libgcrypt uses to retrieve system information and the +files which can be created by the user to modify Libgcrypt's behavior +are: + +'/etc/gcrypt/hwf.deny' + This file can be used to disable the use of hardware based + optimizations, *note hardware features::. + +'/etc/gcrypt/random.conf' + This file can be used to globally change parameters of the random + generator. The file is a simple text file where empty lines and + lines with the first non white-space character being '#' are + ignored. Supported options are + + 'disable-jent' + Disable the use of the jitter based entropy generator. + + 'only-urandom' + Always use the non-blocking /dev/urandom or the respective + system call instead of the blocking /dev/random. If Libgcrypt + is used early in the boot process of the system, this option + should only be used if the system also supports the getrandom + system call. + +'/etc/gcrypt/fips_enabled' +'/proc/sys/crypto/fips_enabled' + On Linux these files are used to enable FIPS mode, *note enabling + fips mode::. + +'/proc/cpuinfo' +'/proc/self/auxv' + On Linux running on the ARM architecture, these files are used to + read hardware capabilities of the CPU. + + +File: gcrypt.info, Node: Architecture, Next: Self-Tests, Prev: Configuration, Up: Top + +17 Architecture +*************** + +This chapter describes the internal architecture of Libgcrypt. + + Libgcrypt is a function library written in ISO C-90. Any compliant +compiler should be able to build Libgcrypt as long as the target is +either a POSIX platform or compatible to the API used by Windows NT. +Provisions have been take so that the library can be directly used from +C++ applications; however building with a C++ compiler is not supported. + + Building Libgcrypt is done by using the common './configure && make' +approach. The configure command is included in the source distribution +and as a portable shell script it works on any Unix-alike system. The +result of running the configure script are a C header file ('config.h'), +customized Makefiles, the setup of symbolic links and a few other +things. After that the make tool builds and optionally installs the +library and the documentation. See the files 'INSTALL' and 'README' in +the source distribution on how to do this. + + Libgcrypt is developed using a Subversion(1) repository. Although +all released versions are tagged in this repository, they should not be +used to build production versions of Libgcrypt. Instead released +tarballs should be used. These tarballs are available from several +places with the master copy at 'ftp://ftp.gnupg.org/gcrypt/libgcrypt/'. +Announcements of new releases are posted to the +'gnupg-announce@gnupg.org' mailing list(2). + + + +Figure 17.1: Libgcrypt subsystems + + Libgcrypt consists of several subsystems (*note Figure 17.1: +fig:subsystems.) and all these subsystems provide a public API; this +includes the helper subsystems like the one for S-expressions. The API +style depends on the subsystem; in general an open-use-close approach is +implemented. The open returns a handle to a context used for all +further operations on this handle, several functions may then be used on +this handle and a final close function releases all resources associated +with the handle. + +* Menu: + +* Public-Key Subsystem Architecture:: About public keys. +* Symmetric Encryption Subsystem Architecture:: About standard ciphers. +* Hashing and MACing Subsystem Architecture:: About hashing. +* Multi-Precision-Integer Subsystem Architecture:: About big integers. +* Prime-Number-Generator Subsystem Architecture:: About prime numbers. +* Random-Number Subsystem Architecture:: About random stuff. + + ---------- Footnotes ---------- + + (1) A version control system available for many platforms + + (2) See <http://www.gnupg.org/documentation/mailing-lists.en.html> +for details. + + +File: gcrypt.info, Node: Public-Key Subsystem Architecture, Next: Symmetric Encryption Subsystem Architecture, Up: Architecture + +17.1 Public-Key Architecture +============================ + +Because public key cryptography is almost always used to process small +amounts of data (hash values or session keys), the interface is not +implemented using the open-use-close paradigm, but with single +self-contained functions. Due to the wide variety of parameters +required by different algorithms S-expressions, as flexible way to +convey these parameters, are used. There is a set of helper functions +to work with these S-expressions. + + Aside of functions to register new algorithms, map algorithms names +to algorithms identifiers and to lookup properties of a key, the +following main functions are available: + +'gcry_pk_encrypt' + Encrypt data using a public key. + +'gcry_pk_decrypt' + Decrypt data using a private key. + +'gcry_pk_sign' + Sign data using a private key. + +'gcry_pk_verify' + Verify that a signature matches the data. + +'gcry_pk_testkey' + Perform a consistency over a public or private key. + +'gcry_pk_genkey' + Create a new public/private key pair. + + All these functions lookup the module implementing the algorithm and +pass the actual work to that module. The parsing of the S-expression +input and the construction of S-expression for the return values is done +by the high level code ('cipher/pubkey.c'). Thus the internal interface +between the algorithm modules and the high level functions passes data +in a custom format. + + By default Libgcrypt uses a blinding technique for RSA decryption to +mitigate real world timing attacks over a network: Instead of using the +RSA decryption directly, a blinded value y = x r^{e} \bmod n is +decrypted and the unblinded value x' = y' r^{-1} \bmod n returned. The +blinding value r is a random value with the size of the modulus n and +generated with 'GCRY_WEAK_RANDOM' random level. + + The algorithm used for RSA and DSA key generation depends on whether +Libgcrypt is operated in standard or in FIPS mode. In standard mode an +algorithm based on the Lim-Lee prime number generator is used. In FIPS +mode RSA keys are generated as specified in ANSI X9.31 (1998) and DSA +keys as specified in FIPS 186-2. + + +File: gcrypt.info, Node: Symmetric Encryption Subsystem Architecture, Next: Hashing and MACing Subsystem Architecture, Prev: Public-Key Subsystem Architecture, Up: Architecture + +17.2 Symmetric Encryption Subsystem Architecture +================================================ + +The interface to work with symmetric encryption algorithms is made up of +functions from the 'gcry_cipher_' name space. The implementation +follows the open-use-close paradigm and uses registered algorithm +modules for the actual work. Unless a module implements optimized +cipher mode implementations, the high level code ('cipher/cipher.c') +implements the modes and calls the core algorithm functions to process +each block. + + The most important functions are: + +'gcry_cipher_open' + Create a new instance to encrypt or decrypt using a specified + algorithm and mode. + +'gcry_cipher_close' + Release an instance. + +'gcry_cipher_setkey' + Set a key to be used for encryption or decryption. + +'gcry_cipher_setiv' + Set an initialization vector to be used for encryption or + decryption. + +'gcry_cipher_encrypt' +'gcry_cipher_decrypt' + Encrypt or decrypt data. These functions may be called with + arbitrary amounts of data and as often as needed to encrypt or + decrypt all data. + + There is no strict alignment requirements for data, but the best + performance can be archived if data is aligned to cacheline + boundary. + + There are also functions to query properties of algorithms or +context, like block length, key length, map names or to enable features +like padding methods. + + +File: gcrypt.info, Node: Hashing and MACing Subsystem Architecture, Next: Multi-Precision-Integer Subsystem Architecture, Prev: Symmetric Encryption Subsystem Architecture, Up: Architecture + +17.3 Hashing and MACing Subsystem Architecture +============================================== + +The interface to work with message digests and CRC algorithms is made up +of functions from the 'gcry_md_' name space. The implementation follows +the open-use-close paradigm and uses registered algorithm modules for +the actual work. Although CRC algorithms are not considered +cryptographic hash algorithms, they share enough properties so that it +makes sense to handle them in the same way. It is possible to use +several algorithms at once with one context and thus compute them all on +the same data. + + The most important functions are: + +'gcry_md_open' + Create a new message digest instance and optionally enable one + algorithm. A flag may be used to turn the message digest algorithm + into a HMAC algorithm. + +'gcry_md_enable' + Enable an additional algorithm for the instance. + +'gcry_md_setkey' + Set the key for the MAC. + +'gcry_md_write' + Pass more data for computing the message digest to an instance. + + There is no strict alignment requirements for data, but the best + performance can be archived if data is aligned to cacheline + boundary. + +'gcry_md_putc' + Buffered version of 'gcry_md_write' implemented as a macro. + +'gcry_md_read' + Finalize the computation of the message digest or HMAC and return + the result. + +'gcry_md_close' + Release an instance + +'gcry_md_hash_buffer' + Convenience function to directly compute a message digest over a + memory buffer without the need to create an instance first. + + There are also functions to query properties of algorithms or the +instance, like enabled algorithms, digest length, map algorithm names. +it is also possible to reset an instance or to copy the current state of +an instance at any time. Debug functions to write the hashed data to +files are available as well. + + +File: gcrypt.info, Node: Multi-Precision-Integer Subsystem Architecture, Next: Prime-Number-Generator Subsystem Architecture, Prev: Hashing and MACing Subsystem Architecture, Up: Architecture + +17.4 Multi-Precision-Integer Subsystem Architecture +=================================================== + +The implementation of Libgcrypt's big integer computation code is based +on an old release of GNU Multi-Precision Library (GMP). The decision not +to use the GMP library directly was due to stalled development at that +time and due to security requirements which could not be provided by the +code in GMP. As GMP does, Libgcrypt provides high performance assembler +implementations of low level code for several CPUS to gain much better +performance than with a generic C implementation. + +Major features of Libgcrypt's multi-precision-integer code compared to +GMP are: + + * Avoidance of stack based allocations to allow protection against + swapping out of sensitive data and for easy zeroing of sensitive + intermediate results. + + * Optional use of secure memory and tracking of its use so that + results are also put into secure memory. + + * MPIs are identified by a handle (implemented as a pointer) to give + better control over allocations and to augment them with extra + properties like opaque data. + + * Removal of unnecessary code to reduce complexity. + + * Functions specialized for public key cryptography. + + +File: gcrypt.info, Node: Prime-Number-Generator Subsystem Architecture, Next: Random-Number Subsystem Architecture, Prev: Multi-Precision-Integer Subsystem Architecture, Up: Architecture + +17.5 Prime-Number-Generator Subsystem Architecture +================================================== + +Libgcrypt provides an interface to its prime number generator. These +functions make use of the internal prime number generator which is +required for the generation for public key key pairs. The plain prime +checking function is exported as well. + + The generation of random prime numbers is based on the Lim and Lee +algorithm to create practically save primes.(1) This algorithm creates +a pool of smaller primes, select a few of them to create candidate +primes of the form 2 * p_0 * p_1 * ... * p_n + 1, tests the candidate +for primality and permutates the pool until a prime has been found. It +is possible to clamp one of the small primes to a certain size to help +DSA style algorithms. Because most of the small primes in the pool are +not used for the resulting prime number, they are saved for later use +(see 'save_pool_prime' and 'get_pool_prime' in 'cipher/primegen.c'). +The prime generator optionally supports the finding of an appropriate +generator. + +The primality test works in three steps: + + 1. The standard sieve algorithm using the primes up to 4999 is used as + a quick first check. + + 2. A Fermat test filters out almost all non-primes. + + 3. A 5 round Rabin-Miller test is finally used. The first round uses + a witness of 2, whereas the next rounds use a random witness. + + To support the generation of RSA and DSA keys in FIPS mode according +to X9.31 and FIPS 186-2, Libgcrypt implements two additional prime +generation functions: '_gcry_derive_x931_prime' and +'_gcry_generate_fips186_2_prime'. These functions are internal and not +available through the public API. + + ---------- Footnotes ---------- + + (1) Chae Hoon Lim and Pil Joong Lee. A key recovery attack on +discrete log-based schemes using a prime order subgroup. In Burton S. +Kaliski Jr., editor, Advances in Cryptology: Crypto '97, pages +249Â-263, Berlin / Heidelberg / New York, 1997. Springer-Verlag. +Described on page 260. + + +File: gcrypt.info, Node: Random-Number Subsystem Architecture, Prev: Prime-Number-Generator Subsystem Architecture, Up: Architecture + +17.6 Random-Number Subsystem Architecture +========================================= + +Libgcrypt provides 3 levels or random quality: The level +'GCRY_VERY_STRONG_RANDOM' usually used for key generation, the level +'GCRY_STRONG_RANDOM' for all other strong random requirements and the +function 'gcry_create_nonce' which is used for weaker usages like +nonces. There is also a level 'GCRY_WEAK_RANDOM' which in general maps +to 'GCRY_STRONG_RANDOM' except when used with the function +'gcry_mpi_randomize', where it randomizes an multi-precision-integer +using the 'gcry_create_nonce' function. + +There are two distinct random generators available: + + * The Continuously Seeded Pseudo Random Number Generator (CSPRNG), + which is based on the classic GnuPG derived big pool + implementation. Implemented in 'random/random-csprng.c' and used + by default. + * A FIPS approved ANSI X9.31 PRNG using AES with a 128 bit key. + Implemented in 'random/random-fips.c' and used if Libgcrypt is in + FIPS mode. + +Both generators make use of so-called entropy gathering modules: + +rndlinux + Uses the operating system provided '/dev/random' and '/dev/urandom' + devices. The '/dev/gcrypt/random.conf' config option + 'only-urandom' can be used to inhibit the use of the blocking + '/dev/random' device. + +rndunix + Runs several operating system commands to collect entropy from + sources like virtual machine and process statistics. It is a kind + of poor-man's '/dev/random' implementation. It is not available in + FIPS mode. + +rndegd + Uses the operating system provided Entropy Gathering Daemon (EGD). + The EGD basically uses the same algorithms as rndunix does. + However as a system daemon it keeps on running and thus can serve + several processes requiring entropy input and does not waste + collected entropy if the application does not need all the + collected entropy. It is not available in FIPS mode. + +rndw32 + Targeted for the Microsoft Windows OS. It uses certain properties + of that system and is the only gathering module available for that + OS. + +rndhw + Extra module to collect additional entropy by utilizing a hardware + random number generator. As of now the supported hardware RNG is + the Padlock engine of VIA (Centaur) CPUs and x86 CPUs with the + RDRAND instruction. It is not available in FIPS mode. + +rndjent + Extra module to collect additional entropy using a CPU jitter based + approach. This is only used on X86 hardware where the RDTSC opcode + is available. The '/dev/gcrypt/random.conf' config option + 'disable-jent' can be used to inhibit the use of this module. + +* Menu: + +* CSPRNG Description:: Description of the CSPRNG. +* FIPS PRNG Description:: Description of the FIPS X9.31 PRNG. + + +File: gcrypt.info, Node: CSPRNG Description, Next: FIPS PRNG Description, Up: Random-Number Subsystem Architecture + +17.6.1 Description of the CSPRNG +-------------------------------- + +This random number generator is loosely modelled after the one described +in Peter Gutmann's paper: "Software Generation of Practically Strong +Random Numbers".(1) + + A pool of 600 bytes is used and mixed using the core SHA-1 hash +transform function. Several extra features are used to make the robust +against a wide variety of attacks and to protect against failures of +subsystems. The state of the generator may be saved to a file and +initially seed form a file. + + Depending on how Libgcrypt was build the generator is able to select +the best working entropy gathering module. It makes use of the slow and +fast collection methods and requires the pool to initially seeded form +the slow gatherer or a seed file. An entropy estimation is used to mix +in enough data from the gather modules before returning the actual +random output. Process fork detection and protection is implemented. + + The implementation of the nonce generator (for 'gcry_create_nonce') +is a straightforward repeated hash design: A 28 byte buffer is initially +seeded with the PID and the time in seconds in the first 20 bytes and +with 8 bytes of random taken from the 'GCRY_STRONG_RANDOM' generator. +Random numbers are then created by hashing all the 28 bytes with SHA-1 +and saving that again in the first 20 bytes. The hash is also returned +as result. + + ---------- Footnotes ---------- + + (1) Also described in chapter 6 of his book "Cryptographic Security +Architecture", New York, 2004, ISBN 0-387-95387-6. + + +File: gcrypt.info, Node: FIPS PRNG Description, Prev: CSPRNG Description, Up: Random-Number Subsystem Architecture + +17.6.2 Description of the FIPS X9.31 PRNG +----------------------------------------- + +The core of this deterministic random number generator is implemented +according to the document "NIST-Recommended Random Number Generator +Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES +Algorithms", dated 2005-01-31. This implementation uses the AES +variant. + + The generator is based on contexts to utilize the same core functions +for all random levels as required by the high-level interface. All +random generators return their data in 128 bit blocks. If the caller +requests less bits, the extra bits are not used. The key for each +generator is only set once at the first time a generator context is +used. The seed value is set along with the key and again after 1000 +output blocks. + + On Unix like systems the 'GCRY_VERY_STRONG_RANDOM' and +'GCRY_STRONG_RANDOM' generators are keyed and seeded using the rndlinux +module with the '/dev/random' device. Thus these generators may block +until the OS kernel has collected enough entropy. When used with +Microsoft Windows the rndw32 module is used instead. + + The generator used for 'gcry_create_nonce' is keyed and seeded from +the 'GCRY_STRONG_RANDOM' generator. Thus is may also block if the +'GCRY_STRONG_RANDOM' generator has not yet been used before and thus +gets initialized on the first use by 'gcry_create_nonce'. This special +treatment is justified by the weaker requirements for a nonce generator +and to save precious kernel entropy for use by the "real" random +generators. + + A self-test facility uses a separate context to check the +functionality of the core X9.31 functions using a known answers test. +During runtime each output block is compared to the previous one to +detect a stuck generator. + + The DT value for the generator is made up of the current time down to +microseconds (if available) and a free running 64 bit counter. When +used with the test context the DT value is taken from the context and +incremented on each use. + + +File: gcrypt.info, Node: Self-Tests, Next: FIPS Mode, Prev: Architecture, Up: Top + +Appendix A Description of the Self-Tests +**************************************** + +In addition to the build time regression test suite, Libgcrypt +implements self-tests to be performed at runtime. Which self-tests are +actually used depends on the mode Libgcrypt is used in. In standard +mode a limited set of self-tests is run at the time an algorithm is +first used. Note that not all algorithms feature a self-test in +standard mode. The 'GCRYCTL_SELFTEST' control command may be used to +run all implemented self-tests at any time; this will even run more +tests than those run in FIPS mode. + + If any of the self-tests fails, the library immediately returns an +error code to the caller. If Libgcrypt is in FIPS mode the self-tests +will be performed within the "Self-Test" state and any failure puts the +library into the "Error" state. + +A.1 Power-Up Tests +================== + +Power-up tests are only performed if Libgcrypt is in FIPS mode. + +A.1.1 Symmetric Cipher Algorithm Power-Up Tests +----------------------------------------------- + +The following symmetric encryption algorithm tests are run during +power-up: + +3DES + To test the 3DES 3-key EDE encryption in ECB mode these tests are + run: + 1. A known answer test is run on a 64 bit test vector processed + by 64 rounds of Single-DES block encryption and decryption + using a key changed with each round. + 2. A known answer test is run on a 64 bit test vector processed + by 16 rounds of 2-key and 3-key Triple-DES block encryption + and decryptions using a key changed with each round. + 3. 10 known answer tests using 3-key Triple-DES EDE encryption, + comparing the ciphertext to the known value, then running a + decryption and comparing it to the initial plaintext. + ('cipher/des.c:selftest') + +AES-128 + A known answer tests is run using one test vector and one test key + with AES in ECB mode. ('cipher/rijndael.c:selftest_basic_128') + +AES-192 + A known answer tests is run using one test vector and one test key + with AES in ECB mode. ('cipher/rijndael.c:selftest_basic_192') + +AES-256 + A known answer tests is run using one test vector and one test key + with AES in ECB mode. ('cipher/rijndael.c:selftest_basic_256') + +A.1.2 Hash Algorithm Power-Up Tests +----------------------------------- + +The following hash algorithm tests are run during power-up: + +SHA-1 + A known answer test using the string '"abc"' is run. + ('cipher/sha1.c:selftests_sha1') +SHA-224 + A known answer test using the string '"abc"' is run. + ('cipher/sha256.c:selftests_sha224') +SHA-256 + A known answer test using the string '"abc"' is run. + ('cipher/sha256.c:selftests_sha256') +SHA-384 + A known answer test using the string '"abc"' is run. + ('cipher/sha512.c:selftests_sha384') +SHA-512 + A known answer test using the string '"abc"' is run. + ('cipher/sha512.c:selftests_sha512') + +A.1.3 MAC Algorithm Power-Up Tests +---------------------------------- + +The following MAC algorithm tests are run during power-up: + +HMAC SHA-1 + A known answer test using 9 byte of data and a 64 byte key is run. + ('cipher/hmac-tests.c:selftests_sha1') +HMAC SHA-224 + A known answer test using 28 byte of data and a 4 byte key is run. + ('cipher/hmac-tests.c:selftests_sha224') +HMAC SHA-256 + A known answer test using 28 byte of data and a 4 byte key is run. + ('cipher/hmac-tests.c:selftests_sha256') +HMAC SHA-384 + A known answer test using 28 byte of data and a 4 byte key is run. + ('cipher/hmac-tests.c:selftests_sha384') +HMAC SHA-512 + A known answer test using 28 byte of data and a 4 byte key is run. + ('cipher/hmac-tests.c:selftests_sha512') + +A.1.4 Random Number Power-Up Test +--------------------------------- + +The DRNG is tested during power-up this way: + + 1. Requesting one block of random using the public interface to check + general working and the duplicated block detection. + 2. 3 know answer tests using pre-defined keys, seed and initial DT + values. For each test 3 blocks of 16 bytes are requested and + compared to the expected result. The DT value is incremented for + each block. + +A.1.5 Public Key Algorithm Power-Up Tests +----------------------------------------- + +The public key algorithms are tested during power-up: + +RSA + A pre-defined 1024 bit RSA key is used and these tests are run in + turn: + 1. Conversion of S-expression to internal format. + ('cipher/rsa.c:selftests_rsa') + 2. Private key consistency check. ('cipher/rsa.c:selftests_rsa') + 3. A pre-defined 20 byte value is signed with PKCS#1 padding for + SHA-1. The result is verified using the public key against + the original data and against modified data. + ('cipher/rsa.c:selftest_sign_1024') + 4. A 1000 bit random value is encrypted and checked that it does + not match the original random value. The encrypted result is + then decrypted and checked that it matches the original random + value. ('cipher/rsa.c:selftest_encr_1024') + +DSA + A pre-defined 1024 bit DSA key is used and these tests are run in + turn: + 1. Conversion of S-expression to internal format. + ('cipher/dsa.c:selftests_dsa') + 2. Private key consistency check. ('cipher/dsa.c:selftests_dsa') + 3. A pre-defined 20 byte value is signed with PKCS#1 padding for + SHA-1. The result is verified using the public key against + the original data and against modified data. + ('cipher/dsa.c:selftest_sign_1024') + +A.1.6 Integrity Power-Up Tests +------------------------------ + +The integrity of the Libgcrypt is tested during power-up but only if +checking has been enabled at build time. The check works by computing a +HMAC SHA-256 checksum over the file used to load Libgcrypt into memory. +That checksum is compared against a checksum stored in a file of the +same name but with a single dot as a prefix and a suffix of '.hmac'. + +A.1.7 Critical Functions Power-Up Tests +--------------------------------------- + +The 3DES weak key detection is tested during power-up by calling the +detection function with keys taken from a table listening all weak keys. +The table itself is protected using a SHA-1 hash. +('cipher/des.c:selftest') + +A.2 Conditional Tests +===================== + +The conditional tests are performed if a certain condition is met. This +may occur at any time; the library does not necessary enter the +"Self-Test" state to run these tests but will transit to the "Error" +state if a test failed. + +A.2.1 Key-Pair Generation Tests +------------------------------- + +After an asymmetric key-pair has been generated, Libgcrypt runs a +pair-wise consistency tests on the generated key. On failure the +generated key is not used, an error code is returned and, if in FIPS +mode, the library is put into the "Error" state. + +RSA + The test uses a random number 64 bits less the size of the modulus + as plaintext and runs an encryption and decryption operation in + turn. The encrypted value is checked to not match the plaintext + and the result of the decryption is checked to match the plaintext. + + A new random number of the same size is generated, signed and + verified to test the correctness of the signing operation. As a + second signing test, the signature is modified by incrementing its + value and then verified with the expected result that the + verification fails. ('cipher/rsa.c:test_keys') +DSA + The test uses a random number of the size of the Q parameter to + create a signature and then checks that the signature verifies. As + a second signing test, the data is modified by incrementing its + value and then verified against the signature with the expected + result that the verification fails. ('cipher/dsa.c:test_keys') + +A.2.2 Software Load Tests +------------------------- + +No code is loaded at runtime. + +A.2.3 Manual Key Entry Tests +---------------------------- + +A manual key entry feature is not implemented in Libgcrypt. + +A.2.4 Continuous RNG Tests +-------------------------- + +The continuous random number test is only used in FIPS mode. The RNG +generates blocks of 128 bit size; the first block generated per context +is saved in the context and another block is generated to be returned to +the caller. Each block is compared against the saved block and then +stored in the context. If a duplicated block is detected an error is +signaled and the library is put into the "Fatal-Error" state. +('random/random-fips.c:x931_aes_driver') + +A.3 Application Requested Tests +=============================== + +The application may requests tests at any time by means of the +'GCRYCTL_SELFTEST' control command. Note that using these tests is not +FIPS conform: Although Libgcrypt rejects all application requests for +services while running self-tests, it does not ensure that no other +operations of Libgcrypt are still being executed. Thus, in FIPS mode an +application requesting self-tests needs to power-cycle Libgcrypt +instead. + + When self-tests are requested, Libgcrypt runs all the tests it does +during power-up as well as a few extra checks as described below. + +A.3.1 Symmetric Cipher Algorithm Tests +-------------------------------------- + +The following symmetric encryption algorithm tests are run in addition +to the power-up tests: + +AES-128 + A known answer tests with test vectors taken from NIST SP800-38a + and using the high level functions is run for block modes CFB and + OFB. + +A.3.2 Hash Algorithm Tests +-------------------------- + +The following hash algorithm tests are run in addition to the power-up +tests: + +SHA-1 +SHA-224 +SHA-256 + 1. A known answer test using a 56 byte string is run. + 2. A known answer test using a string of one million letters "a" + is run. + ('cipher/sha1.c:selftests_sha1', + 'cipher/sha256.c:selftests_sha224', + 'cipher/sha256.c:selftests_sha256') +SHA-384 +SHA-512 + 1. A known answer test using a 112 byte string is run. + 2. A known answer test using a string of one million letters "a" + is run. + ('cipher/sha512.c:selftests_sha384', + 'cipher/sha512.c:selftests_sha512') + +A.3.3 MAC Algorithm Tests +------------------------- + +The following MAC algorithm tests are run in addition to the power-up +tests: + +HMAC SHA-1 + 1. A known answer test using 9 byte of data and a 20 byte key is + run. + 2. A known answer test using 9 byte of data and a 100 byte key is + run. + 3. A known answer test using 9 byte of data and a 49 byte key is + run. + ('cipher/hmac-tests.c:selftests_sha1') +HMAC SHA-224 +HMAC SHA-256 +HMAC SHA-384 +HMAC SHA-512 + 1. A known answer test using 9 byte of data and a 20 byte key is + run. + 2. A known answer test using 50 byte of data and a 20 byte key is + run. + 3. A known answer test using 50 byte of data and a 26 byte key is + run. + 4. A known answer test using 54 byte of data and a 131 byte key + is run. + 5. A known answer test using 152 byte of data and a 131 byte key + is run. + ('cipher/hmac-tests.c:selftests_sha224', + 'cipher/hmac-tests.c:selftests_sha256', + 'cipher/hmac-tests.c:selftests_sha384', + 'cipher/hmac-tests.c:selftests_sha512') + + +File: gcrypt.info, Node: FIPS Mode, Next: Library Copying, Prev: Self-Tests, Up: Top + +Appendix B Description of the FIPS Mode +*************************************** + +This appendix gives detailed information pertaining to the FIPS mode. +In particular, the changes to the standard mode and the finite state +machine are described. The self-tests required in this mode are +described in the appendix on self-tests. + +B.1 Restrictions in FIPS Mode +============================= + +If Libgcrypt is used in FIPS mode these restrictions are effective: + + * The cryptographic algorithms are restricted to this list: + + GCRY_CIPHER_3DES + 3 key EDE Triple-DES symmetric encryption. + GCRY_CIPHER_AES128 + AES 128 bit symmetric encryption. + GCRY_CIPHER_AES192 + AES 192 bit symmetric encryption. + GCRY_CIPHER_AES256 + AES 256 bit symmetric encryption. + GCRY_MD_SHA1 + SHA-1 message digest. + GCRY_MD_SHA224 + SHA-224 message digest. + GCRY_MD_SHA256 + SHA-256 message digest. + GCRY_MD_SHA384 + SHA-384 message digest. + GCRY_MD_SHA512 + SHA-512 message digest. + GCRY_MD_SHA1,GCRY_MD_FLAG_HMAC + HMAC using a SHA-1 message digest. + GCRY_MD_SHA224,GCRY_MD_FLAG_HMAC + HMAC using a SHA-224 message digest. + GCRY_MD_SHA256,GCRY_MD_FLAG_HMAC + HMAC using a SHA-256 message digest. + GCRY_MD_SHA384,GCRY_MD_FLAG_HMAC + HMAC using a SHA-384 message digest. + GCRY_MD_SHA512,GCRY_MD_FLAG_HMAC + HMAC using a SHA-512 message digest. + GCRY_PK_RSA + RSA encryption and signing. + GCRY_PK_DSA + DSA signing. + + Note that the CRC algorithms are not considered cryptographic + algorithms and thus are in addition available. + + * RSA key generation refuses to create a key with a keysize of less + than 1024 bits. + + * DSA key generation refuses to create a key with a keysize other + than 1024 bits. + + * The 'transient-key' flag for RSA and DSA key generation is ignored. + + * Support for the VIA Padlock engine is disabled. + + * FIPS mode may only be used on systems with a /dev/random device. + Switching into FIPS mode on other systems will fail at runtime. + + * Saving and loading a random seed file is ignored. + + * An X9.31 style random number generator is used in place of the + large-pool-CSPRNG generator. + + * The command 'GCRYCTL_ENABLE_QUICK_RANDOM' is ignored. + + * Message digest debugging is disabled. + + * All debug output related to cryptographic data is suppressed. + + * On-the-fly self-tests are not performed, instead self-tests are run + before entering operational state. + + * The function 'gcry_set_allocation_handler' may not be used. If it + is used Libgcrypt disables FIPS mode unless Enforced FIPS mode is + enabled, in which case Libgcrypt will enter the error state. + + * The digest algorithm MD5 may not be used. If it is used Libgcrypt + disables FIPS mode unless Enforced FIPS mode is enabled, in which + case Libgcrypt will enter the error state. + + * In Enforced FIPS mode the command 'GCRYCTL_DISABLE_SECMEM' is + ignored. In standard FIPS mode it disables FIPS mode. + + * A handler set by 'gcry_set_outofcore_handler' is ignored. + * A handler set by 'gcry_set_fatalerror_handler' is ignored. + + Note that when we speak about disabling FIPS mode, it merely means +that the function 'gcry_fips_mode_active' returns false; it does not +mean that any non FIPS algorithms are allowed. + +B.2 FIPS Finite State Machine +============================= + +The FIPS mode of libgcrypt implements a finite state machine (FSM) using +8 states (*note Table B.1: tbl:fips-states.) and checks at runtime that +only valid transitions (*note Table B.2: tbl:fips-state-transitions.) +may happen. + + + +Figure B.1: FIPS mode state diagram + +States used by the FIPS FSM: + +Power-Off + Libgcrypt is not runtime linked to another application. This + usually means that the library is not loaded into main memory. + This state is documentation only. + +Power-On + Libgcrypt is loaded into memory and API calls may be made. + Compiler introduced constructor functions may be run. Note that + Libgcrypt does not implement any arbitrary constructor functions to + be called by the operating system + +Init + The Libgcrypt initialization functions are performed and the + library has not yet run any self-test. + +Self-Test + Libgcrypt is performing self-tests. + +Operational + Libgcrypt is in the operational state and all interfaces may be + used. + +Error + Libgrypt is in the error state. When calling any FIPS relevant + interfaces they either return an error ('GPG_ERR_NOT_OPERATIONAL') + or put Libgcrypt into the Fatal-Error state and won't return. + +Fatal-Error + Libgcrypt is in a non-recoverable error state and will + automatically transit into the Shutdown state. + +Shutdown + Libgcrypt is about to be terminated and removed from the memory. + The application may at this point still running cleanup handlers. + +Table B.1: FIPS mode states + +The valid state transitions (*note Figure B.1: fig:fips-fsm.) are: +'1' + Power-Off to Power-On is implicitly done by the OS loading + Libgcrypt as a shared library and having it linked to an + application. + +'2' + Power-On to Init is triggered by the application calling the + Libgcrypt initialization function 'gcry_check_version'. + +'3' + Init to Self-Test is either triggered by a dedicated API call or + implicit by invoking a libgrypt service controlled by the FSM. + +'4' + Self-Test to Operational is triggered after all self-tests passed + successfully. + +'5' + Operational to Shutdown is an artificial state without any direct + action in Libgcrypt. When reaching the Shutdown state the library + is deinitialized and can't return to any other state again. + +'6' + Shutdown to Power-off is the process of removing Libgcrypt from the + computer's memory. For obvious reasons the Power-Off state can't + be represented within Libgcrypt and thus this transition is for + documentation only. + +'7' + Operational to Error is triggered if Libgcrypt detected an + application error which can't be returned to the caller but still + allows Libgcrypt to properly run. In the Error state all FIPS + relevant interfaces return an error code. + +'8' + Error to Shutdown is similar to the Operational to Shutdown + transition (5). + +'9' + Error to Fatal-Error is triggered if Libgrypt detects an fatal + error while already being in Error state. + +'10' + Fatal-Error to Shutdown is automatically entered by Libgcrypt after + having reported the error. + +'11' + Power-On to Shutdown is an artificial state to document that + Libgcrypt has not ye been initialized but the process is about to + terminate. + +'12' + Power-On to Fatal-Error will be triggered if certain Libgcrypt + functions are used without having reached the Init state. + +'13' + Self-Test to Fatal-Error is triggered by severe errors in Libgcrypt + while running self-tests. + +'14' + Self-Test to Error is triggered by a failed self-test. + +'15' + Operational to Fatal-Error is triggered if Libcrypt encountered a + non-recoverable error. + +'16' + Operational to Self-Test is triggered if the application requested + to run the self-tests again. + +'17' + Error to Self-Test is triggered if the application has requested to + run self-tests to get to get back into operational state after an + error. + +'18' + Init to Error is triggered by errors in the initialization code. + +'19' + Init to Fatal-Error is triggered by non-recoverable errors in the + initialization code. + +'20' + Error to Error is triggered by errors while already in the Error + state. + +Table B.2: FIPS mode state transitions + +B.3 FIPS Miscellaneous Information +================================== + +Libgcrypt does not do any key management on itself; the application +needs to care about it. Keys which are passed to Libgcrypt should be +allocated in secure memory as available with the functions +'gcry_malloc_secure' and 'gcry_calloc_secure'. By calling 'gcry_free' +on this memory, the memory and thus the keys are overwritten with zero +bytes before releasing the memory. + + For use with the random number generator, Libgcrypt generates 3 +internal keys which are stored in the encryption contexts used by the +RNG. These keys are stored in secure memory for the lifetime of the +process. Application are required to use 'GCRYCTL_TERM_SECMEM' before +process termination. This will zero out the entire secure memory and +thus also the encryption contexts with these keys. + + +File: gcrypt.info, Node: Library Copying, Next: Copying, Prev: FIPS Mode, Up: Top + +GNU Lesser General Public License +********************************* + + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + [This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence the + version number 2.1.] + +Preamble +======== + +The licenses for most software are designed to take away your freedom to +share and change it. By contrast, the GNU General Public Licenses are +intended to guarantee your freedom to share and change free software--to +make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software--typically libraries--of the Free Software +Foundation and other authors who decide to use it. You can use it too, +but we suggest you first think carefully about whether this license or +the ordinary General Public License is the better strategy to use in any +particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of it +in new free programs; and that you are informed that you can do these +things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link other code with the library, you must provide +complete object files to the recipients, so that they can relink them +with the library after making changes to the library and recompiling it. +And you must show them these terms so they know their rights. + + We protect your rights with a two-step method: (1) we copyright the +library, and (2) we offer you this license, which gives you legal +permission to copy, distribute and/or modify the library. + + To protect each distributor, we want to make it very clear that there +is no warranty for the free library. Also, if the library is modified +by someone else and passed on, the recipients should know that what they +have is not the original version, so that the original author's +reputation will not be affected by problems that might be introduced by +others. + + Finally, software patents pose a constant threat to the existence of +any free program. We wish to make sure that a company cannot +effectively restrict the users of a free program by obtaining a +restrictive license from a patent holder. Therefore, we insist that any +patent license obtained for a version of the library must be consistent +with the full freedom of use specified in this license. + + Most GNU software, including some libraries, is covered by the +ordinary GNU General Public License. This license, the GNU Lesser +General Public License, applies to certain designated libraries, and is +quite different from the ordinary General Public License. We use this +license for certain libraries in order to permit linking those libraries +into non-free programs. + + When a program is linked with a library, whether statically or using +a shared library, the combination of the two is legally speaking a +combined work, a derivative of the original library. The ordinary +General Public License therefore permits such linking only if the entire +combination fits its criteria of freedom. The Lesser General Public +License permits more lax criteria for linking other code with the +library. + + We call this license the "Lesser" General Public License because it +does _Less_ to protect the user's freedom than the ordinary General +Public License. It also provides other free software developers Less of +an advantage over competing non-free programs. These disadvantages are +the reason we use the ordinary General Public License for many +libraries. However, the Lesser license provides advantages in certain +special circumstances. + + For example, on rare occasions, there may be a special need to +encourage the widest possible use of a certain library, so that it +becomes a de-facto standard. To achieve this, non-free programs must be +allowed to use the library. A more frequent case is that a free library +does the same job as widely used non-free libraries. In this case, +there is little to gain by limiting the free library to free software +only, so we use the Lesser General Public License. + + In other cases, permission to use a particular library in non-free +programs enables a greater number of people to use a large body of free +software. For example, permission to use the GNU C Library in non-free +programs enables many more people to use the whole GNU operating system, +as well as its variant, the GNU/Linux operating system. + + Although the Lesser General Public License is Less protective of the +users' freedom, it does ensure that the user of a program that is linked +with the Library has the freedom and the wherewithal to run that program +using a modified version of the Library. + + The precise terms and conditions for copying, distribution and +modification follow. Pay close attention to the difference between a +"work based on the library" and a "work that uses the library". The +former contains code derived from the library, whereas the latter must +be combined with the library in order to run. + + GNU LESSER GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License Agreement applies to any software library or other + program which contains a notice placed by the copyright holder or + other authorized party saying it may be distributed under the terms + of this Lesser General Public License (also called "this License"). + Each licensee is addressed as "you". + + A "library" means a collection of software functions and/or data + prepared so as to be conveniently linked with application programs + (which use some of those functions and data) to form executables. + + The "Library", below, refers to any such software library or work + which has been distributed under these terms. A "work based on the + Library" means either the Library or any derivative work under + copyright law: that is to say, a work containing the Library or a + portion of it, either verbatim or with modifications and/or + translated straightforwardly into another language. (Hereinafter, + translation is included without limitation in the term + "modification".) + + "Source code" for a work means the preferred form of the work for + making modifications to it. For a library, complete source code + means all the source code for all modules it contains, plus any + associated interface definition files, plus the scripts used to + control compilation and installation of the library. + + Activities other than copying, distribution and modification are + not covered by this License; they are outside its scope. The act + of running a program using the Library is not restricted, and + output from such a program is covered only if its contents + constitute a work based on the Library (independent of the use of + the Library in a tool for writing it). Whether that is true + depends on what the Library does and what the program that uses the + Library does. + + 1. You may copy and distribute verbatim copies of the Library's + complete source code as you receive it, in any medium, provided + that you conspicuously and appropriately publish on each copy an + appropriate copyright notice and disclaimer of warranty; keep + intact all the notices that refer to this License and to the + absence of any warranty; and distribute a copy of this License + along with the Library. + + You may charge a fee for the physical act of transferring a copy, + and you may at your option offer warranty protection in exchange + for a fee. + + 2. You may modify your copy or copies of the Library or any portion of + it, thus forming a work based on the Library, and copy and + distribute such modifications or work under the terms of Section 1 + above, provided that you also meet all of these conditions: + + a. The modified work must itself be a software library. + + b. You must cause the files modified to carry prominent notices + stating that you changed the files and the date of any change. + + c. You must cause the whole of the work to be licensed at no + charge to all third parties under the terms of this License. + + d. If a facility in the modified Library refers to a function or + a table of data to be supplied by an application program that + uses the facility, other than as an argument passed when the + facility is invoked, then you must make a good faith effort to + ensure that, in the event an application does not supply such + function or table, the facility still operates, and performs + whatever part of its purpose remains meaningful. + + (For example, a function in a library to compute square roots + has a purpose that is entirely well-defined independent of the + application. Therefore, Subsection 2d requires that any + application-supplied function or table used by this function + must be optional: if the application does not supply it, the + square root function must still compute square roots.) + + These requirements apply to the modified work as a whole. If + identifiable sections of that work are not derived from the + Library, and can be reasonably considered independent and separate + works in themselves, then this License, and its terms, do not apply + to those sections when you distribute them as separate works. But + when you distribute the same sections as part of a whole which is a + work based on the Library, the distribution of the whole must be on + the terms of this License, whose permissions for other licensees + extend to the entire whole, and thus to each and every part + regardless of who wrote it. + + Thus, it is not the intent of this section to claim rights or + contest your rights to work written entirely by you; rather, the + intent is to exercise the right to control the distribution of + derivative or collective works based on the Library. + + In addition, mere aggregation of another work not based on the + Library with the Library (or with a work based on the Library) on a + volume of a storage or distribution medium does not bring the other + work under the scope of this License. + + 3. You may opt to apply the terms of the ordinary GNU General Public + License instead of this License to a given copy of the Library. To + do this, you must alter all the notices that refer to this License, + so that they refer to the ordinary GNU General Public License, + version 2, instead of to this License. (If a newer version than + version 2 of the ordinary GNU General Public License has appeared, + then you can specify that version instead if you wish.) Do not + make any other change in these notices. + + Once this change is made in a given copy, it is irreversible for + that copy, so the ordinary GNU General Public License applies to + all subsequent copies and derivative works made from that copy. + + This option is useful when you wish to copy part of the code of the + Library into a program that is not a library. + + 4. You may copy and distribute the Library (or a portion or derivative + of it, under Section 2) in object code or executable form under the + terms of Sections 1 and 2 above provided that you accompany it with + the complete corresponding machine-readable source code, which must + be distributed under the terms of Sections 1 and 2 above on a + medium customarily used for software interchange. + + If distribution of object code is made by offering access to copy + from a designated place, then offering equivalent access to copy + the source code from the same place satisfies the requirement to + distribute the source code, even though third parties are not + compelled to copy the source along with the object code. + + 5. A program that contains no derivative of any portion of the + Library, but is designed to work with the Library by being compiled + or linked with it, is called a "work that uses the Library". Such + a work, in isolation, is not a derivative work of the Library, and + therefore falls outside the scope of this License. + + However, linking a "work that uses the Library" with the Library + creates an executable that is a derivative of the Library (because + it contains portions of the Library), rather than a "work that uses + the library". The executable is therefore covered by this License. + Section 6 states terms for distribution of such executables. + + When a "work that uses the Library" uses material from a header + file that is part of the Library, the object code for the work may + be a derivative work of the Library even though the source code is + not. Whether this is true is especially significant if the work + can be linked without the Library, or if the work is itself a + library. The threshold for this to be true is not precisely + defined by law. + + If such an object file uses only numerical parameters, data + structure layouts and accessors, and small macros and small inline + functions (ten lines or less in length), then the use of the object + file is unrestricted, regardless of whether it is legally a + derivative work. (Executables containing this object code plus + portions of the Library will still fall under Section 6.) + + Otherwise, if the work is a derivative of the Library, you may + distribute the object code for the work under the terms of Section + 6. Any executables containing that work also fall under Section 6, + whether or not they are linked directly with the Library itself. + + 6. As an exception to the Sections above, you may also combine or link + a "work that uses the Library" with the Library to produce a work + containing portions of the Library, and distribute that work under + terms of your choice, provided that the terms permit modification + of the work for the customer's own use and reverse engineering for + debugging such modifications. + + You must give prominent notice with each copy of the work that the + Library is used in it and that the Library and its use are covered + by this License. You must supply a copy of this License. If the + work during execution displays copyright notices, you must include + the copyright notice for the Library among them, as well as a + reference directing the user to the copy of this License. Also, + you must do one of these things: + + a. Accompany the work with the complete corresponding + machine-readable source code for the Library including + whatever changes were used in the work (which must be + distributed under Sections 1 and 2 above); and, if the work is + an executable linked with the Library, with the complete + machine-readable "work that uses the Library", as object code + and/or source code, so that the user can modify the Library + and then relink to produce a modified executable containing + the modified Library. (It is understood that the user who + changes the contents of definitions files in the Library will + not necessarily be able to recompile the application to use + the modified definitions.) + + b. Use a suitable shared library mechanism for linking with the + Library. A suitable mechanism is one that (1) uses at run + time a copy of the library already present on the user's + computer system, rather than copying library functions into + the executable, and (2) will operate properly with a modified + version of the library, if the user installs one, as long as + the modified version is interface-compatible with the version + that the work was made with. + + c. Accompany the work with a written offer, valid for at least + three years, to give the same user the materials specified in + Subsection 6a, above, for a charge no more than the cost of + performing this distribution. + + d. If distribution of the work is made by offering access to copy + from a designated place, offer equivalent access to copy the + above specified materials from the same place. + + e. Verify that the user has already received a copy of these + materials or that you have already sent this user a copy. + + For an executable, the required form of the "work that uses the + Library" must include any data and utility programs needed for + reproducing the executable from it. However, as a special + exception, the materials to be distributed need not include + anything that is normally distributed (in either source or binary + form) with the major components (compiler, kernel, and so on) of + the operating system on which the executable runs, unless that + component itself accompanies the executable. + + It may happen that this requirement contradicts the license + restrictions of other proprietary libraries that do not normally + accompany the operating system. Such a contradiction means you + cannot use both them and the Library together in an executable that + you distribute. + + 7. You may place library facilities that are a work based on the + Library side-by-side in a single library together with other + library facilities not covered by this License, and distribute such + a combined library, provided that the separate distribution of the + work based on the Library and of the other library facilities is + otherwise permitted, and provided that you do these two things: + + a. Accompany the combined library with a copy of the same work + based on the Library, uncombined with any other library + facilities. This must be distributed under the terms of the + Sections above. + + b. Give prominent notice with the combined library of the fact + that part of it is a work based on the Library, and explaining + where to find the accompanying uncombined form of the same + work. + + 8. You may not copy, modify, sublicense, link with, or distribute the + Library except as expressly provided under this License. Any + attempt otherwise to copy, modify, sublicense, link with, or + distribute the Library is void, and will automatically terminate + your rights under this License. However, parties who have received + copies, or rights, from you under this License will not have their + licenses terminated so long as such parties remain in full + compliance. + + 9. You are not required to accept this License, since you have not + signed it. However, nothing else grants you permission to modify + or distribute the Library or its derivative works. These actions + are prohibited by law if you do not accept this License. + Therefore, by modifying or distributing the Library (or any work + based on the Library), you indicate your acceptance of this License + to do so, and all its terms and conditions for copying, + distributing or modifying the Library or works based on it. + + 10. Each time you redistribute the Library (or any work based on the + Library), the recipient automatically receives a license from the + original licensor to copy, distribute, link with or modify the + Library subject to these terms and conditions. You may not impose + any further restrictions on the recipients' exercise of the rights + granted herein. You are not responsible for enforcing compliance + by third parties with this License. + + 11. If, as a consequence of a court judgment or allegation of patent + infringement or for any other reason (not limited to patent + issues), conditions are imposed on you (whether by court order, + agreement or otherwise) that contradict the conditions of this + License, they do not excuse you from the conditions of this + License. If you cannot distribute so as to satisfy simultaneously + your obligations under this License and any other pertinent + obligations, then as a consequence you may not distribute the + Library at all. For example, if a patent license would not permit + royalty-free redistribution of the Library by all those who receive + copies directly or indirectly through you, then the only way you + could satisfy both it and this License would be to refrain entirely + from distribution of the Library. + + If any portion of this section is held invalid or unenforceable + under any particular circumstance, the balance of the section is + intended to apply, and the section as a whole is intended to apply + in other circumstances. + + It is not the purpose of this section to induce you to infringe any + patents or other property right claims or to contest validity of + any such claims; this section has the sole purpose of protecting + the integrity of the free software distribution system which is + implemented by public license practices. Many people have made + generous contributions to the wide range of software distributed + through that system in reliance on consistent application of that + system; it is up to the author/donor to decide if he or she is + willing to distribute software through any other system and a + licensee cannot impose that choice. + + This section is intended to make thoroughly clear what is believed + to be a consequence of the rest of this License. + + 12. If the distribution and/or use of the Library is restricted in + certain countries either by patents or by copyrighted interfaces, + the original copyright holder who places the Library under this + License may add an explicit geographical distribution limitation + excluding those countries, so that distribution is permitted only + in or among countries not thus excluded. In such case, this + License incorporates the limitation as if written in the body of + this License. + + 13. The Free Software Foundation may publish revised and/or new + versions of the Lesser General Public License from time to time. + Such new versions will be similar in spirit to the present version, + but may differ in detail to address new problems or concerns. + + Each version is given a distinguishing version number. If the + Library specifies a version number of this License which applies to + it and "any later version", you have the option of following the + terms and conditions either of that version or of any later version + published by the Free Software Foundation. If the Library does not + specify a license version number, you may choose any version ever + published by the Free Software Foundation. + + 14. If you wish to incorporate parts of the Library into other free + programs whose distribution conditions are incompatible with these, + write to the author to ask for permission. For software which is + copyrighted by the Free Software Foundation, write to the Free + Software Foundation; we sometimes make exceptions for this. Our + decision will be guided by the two goals of preserving the free + status of all derivatives of our free software and of promoting the + sharing and reuse of software generally. + + NO WARRANTY + + 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO + WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE + LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS + AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY + OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT + LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND + PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE + DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR + OR CORRECTION. + + 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN + WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY + MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE + LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, + INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR + INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF + DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU + OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY + OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN + ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + +How to Apply These Terms to Your New Libraries +============================================== + +If you develop a new library, and you want it to be of the greatest +possible use to the public, we recommend making it free software that +everyone can redistribute and change. You can do so by permitting +redistribution under these terms (or, alternatively, under the terms of +the ordinary General Public License). + + To apply these terms, attach the following notices to the library. +It is safest to attach them to the start of each source file to most +effectively convey the exclusion of warranty; and each file should have +at least the "copyright" line and a pointer to where the full notice is +found. + + ONE LINE TO GIVE THE LIBRARY'S NAME AND AN IDEA OF WHAT IT DOES. + Copyright (C) YEAR NAME OF AUTHOR + + This library is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as published by + the Free Software Foundation; either version 2.1 of the License, or (at + your option) any later version. + + This library is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, + USA. + + Also add information on how to contact you by electronic and paper +mail. + + You should also get your employer (if you work as a programmer) or +your school, if any, to sign a "copyright disclaimer" for the library, +if necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the library + `Frob' (a library for tweaking knobs) written by James Random Hacker. + + SIGNATURE OF TY COON, 1 April 1990 + Ty Coon, President of Vice + + That's all there is to it! + + +File: gcrypt.info, Node: Copying, Next: Figures and Tables, Prev: Library Copying, Up: Top + +GNU General Public License +************************** + + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +Preamble +======== + +The licenses for most software are designed to take away your freedom to +share and change it. By contrast, the GNU General Public License is +intended to guarantee your freedom to share and change free software--to +make sure the software is free for all its users. This General Public +License applies to most of the Free Software Foundation's software and +to any other program whose authors commit to using it. (Some other Free +Software Foundation software is covered by the GNU Library General +Public License instead.) You can apply it to your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it if +you want it, that you can change the software or use pieces of it in new +free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, +and (2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 1. This License applies to any program or other work which contains a + notice placed by the copyright holder saying it may be distributed + under the terms of this General Public License. The "Program", + below, refers to any such program or work, and a "work based on the + Program" means either the Program or any derivative work under + copyright law: that is to say, a work containing the Program or a + portion of it, either verbatim or with modifications and/or + translated into another language. (Hereinafter, translation is + included without limitation in the term "modification".) Each + licensee is addressed as "you". + + Activities other than copying, distribution and modification are + not covered by this License; they are outside its scope. The act + of running the Program is not restricted, and the output from the + Program is covered only if its contents constitute a work based on + the Program (independent of having been made by running the + Program). Whether that is true depends on what the Program does. + + 2. You may copy and distribute verbatim copies of the Program's source + code as you receive it, in any medium, provided that you + conspicuously and appropriately publish on each copy an appropriate + copyright notice and disclaimer of warranty; keep intact all the + notices that refer to this License and to the absence of any + warranty; and give any other recipients of the Program a copy of + this License along with the Program. + + You may charge a fee for the physical act of transferring a copy, + and you may at your option offer warranty protection in exchange + for a fee. + + 3. You may modify your copy or copies of the Program or any portion of + it, thus forming a work based on the Program, and copy and + distribute such modifications or work under the terms of Section 1 + above, provided that you also meet all of these conditions: + + a. You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b. You must cause any work that you distribute or publish, that + in whole or in part contains or is derived from the Program or + any part thereof, to be licensed as a whole at no charge to + all third parties under the terms of this License. + + c. If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display + an announcement including an appropriate copyright notice and + a notice that there is no warranty (or else, saying that you + provide a warranty) and that users may redistribute the + program under these conditions, and telling the user how to + view a copy of this License. (Exception: if the Program + itself is interactive but does not normally print such an + announcement, your work based on the Program is not required + to print an announcement.) + + These requirements apply to the modified work as a whole. If + identifiable sections of that work are not derived from the + Program, and can be reasonably considered independent and separate + works in themselves, then this License, and its terms, do not apply + to those sections when you distribute them as separate works. But + when you distribute the same sections as part of a whole which is a + work based on the Program, the distribution of the whole must be on + the terms of this License, whose permissions for other licensees + extend to the entire whole, and thus to each and every part + regardless of who wrote it. + + Thus, it is not the intent of this section to claim rights or + contest your rights to work written entirely by you; rather, the + intent is to exercise the right to control the distribution of + derivative or collective works based on the Program. + + In addition, mere aggregation of another work not based on the + Program with the Program (or with a work based on the Program) on a + volume of a storage or distribution medium does not bring the other + work under the scope of this License. + + 4. You may copy and distribute the Program (or a work based on it, + under Section 2) in object code or executable form under the terms + of Sections 1 and 2 above provided that you also do one of the + following: + + a. Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of + Sections 1 and 2 above on a medium customarily used for + software interchange; or, + + b. Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a + medium customarily used for software interchange; or, + + c. Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with + such an offer, in accord with Subsection b above.) + + The source code for a work means the preferred form of the work for + making modifications to it. For an executable work, complete + source code means all the source code for all modules it contains, + plus any associated interface definition files, plus the scripts + used to control compilation and installation of the executable. + However, as a special exception, the source code distributed need + not include anything that is normally distributed (in either source + or binary form) with the major components (compiler, kernel, and so + on) of the operating system on which the executable runs, unless + that component itself accompanies the executable. + + If distribution of executable or object code is made by offering + access to copy from a designated place, then offering equivalent + access to copy the source code from the same place counts as + distribution of the source code, even though third parties are not + compelled to copy the source along with the object code. + + 5. You may not copy, modify, sublicense, or distribute the Program + except as expressly provided under this License. Any attempt + otherwise to copy, modify, sublicense or distribute the Program is + void, and will automatically terminate your rights under this + License. However, parties who have received copies, or rights, + from you under this License will not have their licenses terminated + so long as such parties remain in full compliance. + + 6. You are not required to accept this License, since you have not + signed it. However, nothing else grants you permission to modify + or distribute the Program or its derivative works. These actions + are prohibited by law if you do not accept this License. + Therefore, by modifying or distributing the Program (or any work + based on the Program), you indicate your acceptance of this License + to do so, and all its terms and conditions for copying, + distributing or modifying the Program or works based on it. + + 7. Each time you redistribute the Program (or any work based on the + Program), the recipient automatically receives a license from the + original licensor to copy, distribute or modify the Program subject + to these terms and conditions. You may not impose any further + restrictions on the recipients' exercise of the rights granted + herein. You are not responsible for enforcing compliance by third + parties to this License. + + 8. If, as a consequence of a court judgment or allegation of patent + infringement or for any other reason (not limited to patent + issues), conditions are imposed on you (whether by court order, + agreement or otherwise) that contradict the conditions of this + License, they do not excuse you from the conditions of this + License. If you cannot distribute so as to satisfy simultaneously + your obligations under this License and any other pertinent + obligations, then as a consequence you may not distribute the + Program at all. For example, if a patent license would not permit + royalty-free redistribution of the Program by all those who receive + copies directly or indirectly through you, then the only way you + could satisfy both it and this License would be to refrain entirely + from distribution of the Program. + + If any portion of this section is held invalid or unenforceable + under any particular circumstance, the balance of the section is + intended to apply and the section as a whole is intended to apply + in other circumstances. + + It is not the purpose of this section to induce you to infringe any + patents or other property right claims or to contest validity of + any such claims; this section has the sole purpose of protecting + the integrity of the free software distribution system, which is + implemented by public license practices. Many people have made + generous contributions to the wide range of software distributed + through that system in reliance on consistent application of that + system; it is up to the author/donor to decide if he or she is + willing to distribute software through any other system and a + licensee cannot impose that choice. + + This section is intended to make thoroughly clear what is believed + to be a consequence of the rest of this License. + + 9. If the distribution and/or use of the Program is restricted in + certain countries either by patents or by copyrighted interfaces, + the original copyright holder who places the Program under this + License may add an explicit geographical distribution limitation + excluding those countries, so that distribution is permitted only + in or among countries not thus excluded. In such case, this + License incorporates the limitation as if written in the body of + this License. + + 10. The Free Software Foundation may publish revised and/or new + versions of the General Public License from time to time. Such new + versions will be similar in spirit to the present version, but may + differ in detail to address new problems or concerns. + + Each version is given a distinguishing version number. If the + Program specifies a version number of this License which applies to + it and "any later version", you have the option of following the + terms and conditions either of that version or of any later version + published by the Free Software Foundation. If the Program does not + specify a version number of this License, you may choose any + version ever published by the Free Software Foundation. + + 11. If you wish to incorporate parts of the Program into other free + programs whose distribution conditions are different, write to the + author to ask for permission. For software which is copyrighted by + the Free Software Foundation, write to the Free Software + Foundation; we sometimes make exceptions for this. Our decision + will be guided by the two goals of preserving the free status of + all derivatives of our free software and of promoting the sharing + and reuse of software generally. + + NO WARRANTY + + 12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO + WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE + LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS + AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY + OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT + LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND + PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE + DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR + OR CORRECTION. + + 13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN + WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY + MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE + LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, + INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR + INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF + DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU + OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY + OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN + ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + +How to Apply These Terms to Your New Programs +============================================= + +If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these +terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least the +"copyright" line and a pointer to where the full notice is found. + + ONE LINE TO GIVE THE PROGRAM'S NAME AND AN IDEA OF WHAT IT DOES. + Copyright (C) 19YY NAME OF AUTHOR + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License along + with this program; if not, write to the Free Software Foundation, Inc., + 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. + + Also add information on how to contact you by electronic and paper +mail. + + If the program is interactive, make it output a short notice like +this when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details + type `show w'. This is free software, and you are welcome + to redistribute it under certain conditions; type `show c' + for details. + + The hypothetical commands 'show w' and 'show c' should show the +appropriate parts of the General Public License. Of course, the +commands you use may be called something other than 'show w' and 'show +c'; they could even be mouse-clicks or menu items--whatever suits your +program. + + You should also get your employer (if you work as a programmer) or +your school, if any, to sign a "copyright disclaimer" for the program, +if necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright + interest in the program `Gnomovision' + (which makes passes at compilers) written + by James Hacker. + + SIGNATURE OF TY COON, 1 April 1989 + Ty Coon, President of Vice + + This General Public License does not permit incorporating your +program into proprietary programs. If your program is a subroutine +library, you may consider it more useful to permit linking proprietary +applications with the library. If this is what you want to do, use the +GNU Library General Public License instead of this License. + + +File: gcrypt.info, Node: Figures and Tables, Next: Concept Index, Prev: Copying, Up: Top + +List of Figures and Tables +************************** + +* Menu: + +* Figure 17.1: fig:subsystems. Libgcrypt subsystems +* Figure B.1: fig:fips-fsm. FIPS mode state diagram + +* Menu: + +* Table B.1: tbl:fips-states. FIPS mode states +* Table B.2: tbl:fips-state-transitions. FIPS mode state transitions + + +File: gcrypt.info, Node: Concept Index, Next: Function and Data Index, Prev: Figures and Tables, Up: Top + +Concept Index +************* + + +* Menu: + +* /etc/gcrypt/fips_enabled: Configuration. (line 69) +* /etc/gcrypt/hwf.deny: Configuration. (line 48) +* /etc/gcrypt/random.conf: Configuration. (line 52) +* /proc/cpuinfo: Configuration. (line 74) +* /proc/self/auxv: Configuration. (line 74) +* 3DES: Available ciphers. (line 14) +* Advanced Encryption Standard: Available ciphers. (line 35) +* AES: Available ciphers. (line 35) +* AES-Wrap mode: Available cipher modes. + (line 35) +* Arcfour: Available ciphers. (line 52) +* BLAKE2b-512, BLAKE2b-384, BLAKE2b-256, BLAKE2b-160: Available hash algorithms. + (line 6) +* BLAKE2s-256, BLAKE2s-224, BLAKE2s-160, BLAKE2s-128: Available hash algorithms. + (line 6) +* Blowfish: Available ciphers. (line 22) +* bug emulation: Working with hash algorithms. + (line 38) +* Camellia: Available ciphers. (line 77) +* CAST5: Available ciphers. (line 19) +* CBC, Cipher Block Chaining mode: Available cipher modes. + (line 23) +* CBC-MAC: Working with cipher handles. + (line 56) +* CCM, Counter with CBC-MAC mode: Available cipher modes. + (line 48) +* CFB, Cipher Feedback mode: Available cipher modes. + (line 17) +* ChaCha20: Available ciphers. (line 98) +* cipher text stealing: Working with cipher handles. + (line 50) +* comp: Cryptographic Functions. + (line 13) +* CRC32: Available hash algorithms. + (line 6) +* CTR, Counter mode: Available cipher modes. + (line 32) +* DES: Available ciphers. (line 57) +* DES-EDE: Available ciphers. (line 14) +* Digital Encryption Standard: Available ciphers. (line 14) +* disable-jent: Configuration. (line 58) +* EAX, EAX mode: Available cipher modes. + (line 89) +* ECB, Electronic Codebook mode: Available cipher modes. + (line 13) +* EdDSA: Cryptographic Functions. + (line 33) +* Enforced FIPS mode: Enabling FIPS mode. (line 29) +* error codes: Error Values. (line 6) +* error codes, list of: Error Sources. (line 6) +* error codes, list of <1>: Error Codes. (line 6) +* error codes, printing of: Error Strings. (line 6) +* error sources: Error Values. (line 6) +* error sources, printing of: Error Strings. (line 6) +* error strings: Error Strings. (line 6) +* error values: Error Values. (line 6) +* error values, printing of: Error Strings. (line 6) +* FIPS 140: Enabling FIPS mode. (line 6) +* FIPS 186: Cryptographic Functions. + (line 72) +* FIPS 186 <1>: Public-Key Subsystem Architecture. + (line 50) +* FIPS 186-2: Cryptographic Functions. + (line 80) +* FIPS mode: Enabling FIPS mode. (line 6) +* fips_enabled: Configuration. (line 69) +* GCM, Galois/Counter Mode: Available cipher modes. + (line 53) +* GCRYPT_BARRETT: Configuration. (line 12) +* GCRYPT_RNDUNIX_DBG: Configuration. (line 17) +* GCRYPT_RNDUNIX_DBGALL: Configuration. (line 17) +* GCRYPT_RNDW32_DBG: Configuration. (line 32) +* GCRYPT_RNDW32_NOPERF: Configuration. (line 25) +* GOST 28147-89: Available ciphers. (line 88) +* GOST 28147-89 CryptoPro keymeshing: Available ciphers. (line 92) +* GPL, GNU General Public License: Copying. (line 6) +* hardware features: Hardware features. (line 6) +* HAVAL: Available hash algorithms. + (line 6) +* HMAC: Working with hash algorithms. + (line 28) +* HMAC-BLAKE2s, HMAC-BLAKE2b: Available MAC algorithms. + (line 6) +* HMAC-GOSTR-3411-94: Available MAC algorithms. + (line 6) +* HMAC-MD2, HMAC-MD4, HMAC-MD5: Available MAC algorithms. + (line 6) +* HMAC-RIPE-MD-160: Available MAC algorithms. + (line 6) +* HMAC-SHA-1: Available MAC algorithms. + (line 6) +* HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512: Available MAC algorithms. + (line 6) +* HMAC-SHA-512/224, HMAC-SHA-512/256: Available MAC algorithms. + (line 6) +* HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512: Available MAC algorithms. + (line 6) +* HMAC-SM3: Available MAC algorithms. + (line 6) +* HMAC-Stribog-256, HMAC-Stribog-512: Available MAC algorithms. + (line 6) +* HMAC-TIGER1: Available MAC algorithms. + (line 6) +* HMAC-Whirlpool: Available MAC algorithms. + (line 6) +* HOME: Configuration. (line 37) +* IDEA: Available ciphers. (line 11) +* LGPL, GNU Lesser General Public License: Library Copying. (line 6) +* MD2, MD4, MD5: Available hash algorithms. + (line 6) +* no-blinding: Cryptographic Functions. + (line 41) +* no-keytest: Cryptographic Functions. + (line 59) +* nocomp: Cryptographic Functions. + (line 13) +* OAEP: Cryptographic Functions. + (line 27) +* OCB, OCB3: Available cipher modes. + (line 63) +* OFB, Output Feedback mode: Available cipher modes. + (line 29) +* only-urandom: Configuration. (line 61) +* param: Cryptographic Functions. + (line 47) +* PKCS1: Cryptographic Functions. + (line 23) +* Poly1305 based AEAD mode with ChaCha20: Available cipher modes. + (line 58) +* PSS: Cryptographic Functions. + (line 30) +* RC2: Available ciphers. (line 69) +* RC4: Available ciphers. (line 52) +* rfc-2268: Available ciphers. (line 69) +* RFC6979: Cryptographic Functions. + (line 38) +* Rijndael: Available ciphers. (line 35) +* RIPE-MD-160: Available hash algorithms. + (line 6) +* Salsa20: Available ciphers. (line 81) +* Salsa20/12: Available ciphers. (line 84) +* Seed (cipher): Available ciphers. (line 72) +* Serpent: Available ciphers. (line 65) +* SHA-1: Available hash algorithms. + (line 6) +* SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256: Available hash algorithms. + (line 6) +* SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256: Available hash algorithms. + (line 6) +* SM3: Available hash algorithms. + (line 6) +* SM4 (cipher): Available ciphers. (line 101) +* sync mode (OpenPGP): Working with cipher handles. + (line 46) +* TIGER, TIGER1, TIGER2: Available hash algorithms. + (line 6) +* transient-key: Cryptographic Functions. + (line 52) +* Triple-DES: Available ciphers. (line 14) +* Twofish: Available ciphers. (line 46) +* Whirlpool: Available hash algorithms. + (line 6) +* X9.31: Cryptographic Functions. + (line 65) +* X9.31 <1>: Public-Key Subsystem Architecture. + (line 50) +* XTS, XTS mode: Available cipher modes. + (line 74) + |