Lines Matching refs:In
69 \vspace{2in}
147 and store data in a format independent of the platform. This means if you encrypt with Blowfish on a PPC it should decrypt
154 configurable in terms of its build options. Out of the box the library will build with any modern version of GCC
179 unlike libraries like OpenSSL is not tied to direct routines. For instance, in OpenSSL there are CBC block
181 you have to update the associated support code as well. In LibTomCrypt the associated code (\textit{chaining modes in this case})
194 They can be removed from a build by simply commenting out the two appropriate lines in \textit{tomcrypt\_custom.h}. The rest
201 I would like to give thanks to the following people (in no particular order) for helping me develop this project from
226 In general the API is very simple to memorize and use. Most of the functions return either {\bf void} or {\bf int}. Functions
254 related issue is if you use the same symmetric cipher, hash or public key state data in multiple threads. Normally
272 32/64-bit words in little/big endian format. The macros are:
351 In the above example if the size of the RSA public key was more than 1024 bytes this function would return an error code
364 may be passed as \textbf{NULL} in such situations.
395 must pass in (a pointer to) an array of 32 \textit{unsigned char} variables. Certain routines (such as SAFER+) take
406 the API to grow in a modular fashion.
409 All ciphers store their scheduled keys in a single data type called \textit{symmetric\_key}. This allows all ciphers to
421 The XXX\_setup() routine will setup the cipher to be used with a given number of rounds and a given key length (in bytes).
424 If the function returns successfully the variable \textit{skey} will have a scheduled key stored in it. It's important to note
426 pass the scheduled key onto \textit{rc5\_ecb\_encrypt()}. All built--in setup functions do not allocate memory off the heap so
432 To encrypt or decrypt a block in ECB mode there are these two functions per cipher:
444 which cipher you are using.}, storing the result in the \textit{ct} buffer (\textit{pt} resp.). It is possible that the input and output buffer are
447 return \textbf{CRYPT\_OK} on success. To test a particular cipher against test vectors\footnote{As published in their design papers.}
464 Essentially, it will round the input keysize in \textit{keysize} down to the next appropriate key size. This function
484 This should indicate a keysize of sixteen bytes is suggested by storing 16 in \textit{keysize.}
496 An example snippet that encodes a block with Blowfish in ECB mode.
508 /* ... key is loaded appropriately in key ... */
509 /* ... load a block of plaintext in pt ... */
533 /* now we have decrypted ct to the original plaintext in pt */
549 total amount of entropy in N bits is $N \cdot -log_2\left ({1 \over 2} + \vert \gamma \vert \right)$. So if $\gamma$
560 To facilitate automatic routines an array of cipher descriptors is provided in the array \textit{cipher\_descriptor}. An element
589 are the minimum and maximum key sizes in bytes. The \textit{block\_length} member is the block size of the cipher
590 in bytes. As a good rule of thumb it is assumed that the cipher supports
591 the min and max key lengths but not always everything in between. The \textit{default\_rounds} field is the default number
595 and if missing will be emulated in software.
632 \caption{Built--In Software Ciphers}
643 in the middle (e.g. rijndael\_enc\_desc) are related to an implementation of Rijndael with only the encryption routine
652 Note that for \textit{DES} and \textit{3DES} they use 8 and 24 byte keys but only 7 and 21 [respectively] bytes of the keys are in
657 Note that \textit{Twofish} has additional configuration options (Figure \ref{fig:twofishopts}) that take place at build time. These options are found in
662 by the polynomials 5B and EF used in the MDS multiplication. As a result the code is faster and slightly larger. The
691 Which will search for a given name in the array. It returns $-1$ if the cipher is not found, otherwise it returns
692 the location in the array where the cipher was found. For example, to indirectly setup Blowfish you can also use:
710 * in key[] was already setup) */
723 A good safety would be to check the return value of \textit{find\_cipher()} before accessing the desired function. In order
766 A typical symmetric block cipher can be used in chaining modes to effectively encrypt messages larger than the block
768 $P$ under the key $k$ as $E_k(P)$. In some modes there exists an initial vector denoted as $C_{-1}$.
796 Where $W$ is the size of a block in bits (e.g. 64 for Blowfish). As long as the initial vector is random for each message
807 Note that in this library the output feedback width is equal to the size of the block cipher. That is this mode is used
818 Like the CFB mode the output width in CFB mode is the same as the width of the block cipher. OFB mode will also
824 \item No short cycles which is possible in the OFB and CFB modes.
839 Ciphertext stealing is a method of dealing with messages in CBC mode which are not a multiple of the block length. This is accomplished
840 by encrypting the last ciphertext block in ECB mode, and XOR'ing the output against the last partial block of plaintext. LibTomCrypt does not
875 In each case, \textit{cipher} is the index into the cipher\_descriptor array of the cipher you want to use. The \textit{IV} value is
877 length as the block size\footnote{In other words the size of a block of plaintext for the cipher, e.g. 8 for DES, 16 for AES, etc.}
879 parameters \textit{key}, \textit{keylen} and \textit{num\_rounds} are the same as in the XXX\_setup() function call. The final parameter
883 In the case of CTR mode there is an additional parameter \textit{ctr\_mode} which specifies the mode that the counter is to be used in.
908 In all cases, \textit{len} is the size of the buffer (as number of octets) to encrypt or decrypt. The CTR, OFB and CFB modes are order sensitive but not
909 chunk sensitive. That is you can encrypt \textit{ABCDEF} in three calls like \textit{AB}, \textit{CD}, \textit{EF} or two like \textit{ABCDE} and \textit{F}
910 and end up with the same ciphertext. However, encrypting \textit{ABC} and \textit{DABC} will result in different ciphertexts. All
913 In the ECB and CBC cases, \textit{len} must be a multiple of the ciphers block size. In the CBC case, you must manually pad the end of your message (either with
916 To decrypt in either mode, perform the setup like before (recall you have to fetch the IV value you used), and use the decrypt routine on all of the blocks.
933 stored in \textit{len}. The XXX\_setiv will initialize the chaining mode state as if the original IV were the new IV specified. The length
934 of the IV passed in must be the size of the ciphers block size.
938 What the \textit{setiv} function will do depends on the mode being changed. In CBC mode, the new IV replaces the existing IV as if it
939 were the last ciphertext block. In CFB mode, the IV is encrypted as if it were the prior encrypted pad. In CTR mode, the IV is encrypted without
940 first incrementing it (regardless of the LTC\_RFC\_3686 flag presence). In F8 mode, the IV is encrypted and becomes the new pad. It does not change
941 the salted IV, and is only meant to allow seeking within a session. In LRW, it changes the tweak, forcing a computation of the tweak pad, allowing for
942 seeking within the session. In OFB mode, the IV is encrypted and becomes the new pad.
1071 These will encrypt (or decrypt) the plaintext to the ciphertext buffer (or vice versa). The length is specified by \textit{len} in octets but must be a multiple
1087 in performance constrained code.
1098 The F8 Chaining mode (see RFC 3711 for instance) is yet another chaining mode for block ciphers. It behaves much like CTR mode in that it XORs a keystream
1114 (\textit{m} in the RFC 3711). The salt\_key can be shorter than the secret key but it should not be longer.
1130 These will encrypt or decrypt a variable length array of bytes using the F8 mode state specified. The length is specified in bytes and does not have to be a multiple
1160 M. Bellare, P. Rogaway, D. Wagner, A Conventional Authenticated-Encryption Mode.} in a manner similar to the way it was intended to be used
1167 be added at anytime during an EAX stream, and is part of the authentication tag. That is, changes in the meta-data can be detected by changes in the output tag.
1170 called a \textit{tag} is only emitted when the message is finished. In the interim, the user can process any arbitrary
1187 Where \textit{eax} is the EAX state. The \textit{cipher} parameter is the index of the desired cipher in the descriptor table.
1193 encrypted in EAX mode. Note: if \textit{headerlen} is zero you may pass \textit{header} as \textbf{NULL} to indicate there is no initial header data.
1195 To encrypt or decrypt data in a streaming mode use the following.
1208 The function \textit{eax\_encrypt} will encrypt the bytes in \textit{pt} of \textit{length} octets, and store the ciphertext in
1209 \textit{ct}. Note: \textit{ct} and \textit{pt} may be the same region in memory. This function will also send the ciphertext
1210 through the OMAC function. The function \textit{eax\_decrypt} decrypts \textit{ct}, and stores it in \textit{pt}. This also allows
1211 \textit{pt} and \textit{ct} to be the same region in memory.
1216 Note: both of these functions allow you to send the data in any granularity but the order is important. While
1235 This will terminate the EAX state \textit{eax}, and store up to \textit{taglen} bytes of the message tag in \textit{tag}. The function
1236 then stores how many bytes of the tag were written out back in to \textit{taglen}.
1273 /* now encrypt data, say in a loop or whatever */
1293 /* now we have the authentication tag in "tag" and
1298 You can also perform an entire EAX state on a block of memory in a single function call with the
1328 the tag it computed while decrypting the message. If the tags match then it stores a $1$ in \textit{res}, otherwise it stores a $0$.
1366 states (with different nonces). Also \textit{pt} and \textit{ct} may point to the same location in memory.
1383 you can pass them here. This will also encrypt the \textit{ptlen} bytes in \textit{pt} and store them in \textit{ct}. It will also
1420 This will OCB encrypt the message \textit{pt} of length \textit{ptlen}, and store the ciphertext in \textit{ct}. The length \textit{ptlen}
1440 it is only meant for \textit{packet} mode where the length of the input is known in advance. Since it is a packet mode function, CCM only has one
1457 This performs the \textit{CCM} operation on the data. The \textit{cipher} variable indicates which cipher in the descriptor table to use. It must have a
1460 The key can be specified in one of two fashions. First, it can be passed as an array of octets in \textit{key} of length \textit{keylen}. Alternatively,
1461 it can be passed in as a previously scheduled key in \textit{uskey}. The latter fashion saves time when the same key is used for multiple packets. If
1465 encrypted, it is stored in \textit{header} of length \textit{headerlen} octets. The header can be zero octets long (if $headerlen = 0$ then
1468 The plaintext is stored in \textit{pt}, and the ciphertext in \textit{ct}. The length of both are expected to be equal and is passed in as \textit{ptlen}. It is
1542 Galois counter mode is an IEEE proposal for authenticated encryption (also it is a planned NIST standard). Like EAX and OCB mode, it can be used in a streaming capacity
1546 A GCM stream is meant to be processed in three modes, one after another. First, the initial vector (per session) data is processed. This should be
1601 This processes message data where \textit{pt} is the plaintext and \textit{ct} is the ciphertext. The length of both are equal and stored in \textit{ptlen}. Depending on
1603 encrypted and stored in the ciphertext buffer. When \textit{direction} equals \textbf{GCM\_DECRYPT} the opposite occurs.
1614 This terminates the GCM state \textit{gcm} and stores the tag in \textit{tag} of length \textit{taglen} octets.
1618 it is very costly to have to call it repeatedly. To aid in this endeavour, the reset function has been provided.
1761 const unsigned char *in,
1765 are buffered. The data can be passed in any sized chunks as long as the order of the bytes are the same the message digest (hash output) will be the same. For example,
1783 This function will finish up the hash and store the result in the \textit{out} array. You must ensure that \textit{out} is long
1784 enough for the hash in question. Often hashes are used to get keys for symmetric ciphers so the \textit{XXX\_done()} functions
1800 unsigned char *in = "hello world", out[16];
1806 md5_process(&md, in, strlen(in));
1808 /* get the hash in out[0..15] */
1817 Like the set of ciphers, the set of hashes have descriptors as well. They are stored in an array called \textit{hash\_descriptor} and
1823 unsigned long hashsize; /* digest output size in bytes */
1829 const unsigned char *in,
1840 in bytes, while \textit{blocksize} is the size of blocks the hash expects to the compression function. Technically, this detail is not important
1847 position in the descriptor table of the hash.
1849 In addition, there is also find\_hash\_oid() which finds a hash by the ASN.1 OBJECT IDENTIFIER string.
1900 Note the usage of \textbf{MAXBLOCKSIZE}. In LibTomCrypt, no symmetric block, key or hash digest is larger than \textbf{MAXBLOCKSIZE} in
1903 There are three helper functions to make working with hashes easier. The first is a function to hash a buffer, and produce the digest in a single
1909 const unsigned char *in,
1915 This will hash the data pointed to by \textit{in} of length \textit{inlen}. The hash used is indexed by the \textit{hash} parameter. The message
1916 digest is stored in \textit{out}, and the \textit{outlen} parameter is updated to hold the message digest size.
1927 This will hash the file named by \textit{fname} using the hash indexed by \textit{hash}. The file named in this function call must be readable by the
1929 when it is called. The message digest is stored in \textit{out}, and the \textit{outlen} parameter is updated to hold the message digest size.
1934 FILE *in,
1939 This will hash the file identified by the handle \textit{in} using the hash indexed by \textit{hash}. This will begin hashing from the current file pointer position, and
1941 when it is called. The message digest is stored in \textit{out}, and the \textit{outlen} parameter is updated to hold the message digest size.
2008 \caption{Built--In Software Hashes}
2014 An addition to the suite of hash functions is the \textit{Cipher Hash Construction} or \textit{CHC} mode. In this mode
2015 applicable block ciphers (such as AES) can be turned into hash functions that other LTC functions can use. In
2018 In order to use the CHC system the developer will have to take a few extra steps. First the \textit{chc\_desc} hash
2020 data. While it is in the hash system you still have to tell the CHC code which cipher to use. This is accomplished
2028 A cipher has to be registered with CHC (and also in the cipher descriptor tables with
2061 /* now you can use chc_hash in any LTC function
2083 and its length. The key is much like a key you would pass to a cipher. That is, it is simply an array of octets stored in
2094 length (in octets) of the key you want to use to authenticate the message. To send octets of a message through the HMAC system you must use the following function:
2098 const unsigned char *in,
2102 number of octets to process. Like the hash process routines you can send the data in arbitrarily sized chunks. When you
2116 message (file pointer, address in memory), and produce the HMAC result in one shot. These are useful if you want to avoid
2124 const unsigned char *in, unsigned long inlen,
2127 This will produce an HMAC code for the array of octets in \textit{in} of length \textit{inlen}. The index into the hash descriptor
2128 table must be provided in \textit{hash}. It uses the key from \textit{key} with a key length of \textit{keylen}.
2129 The result is stored in the array of octets \textit{out} and the length in \textit{outlen}. The value of \textit{outlen} must be set
2167 /* get index of SHA1 in hash descriptor table */
2170 /* we would make up our symmetric key in "key[]" here */
2203 HMAC routines. Instead, in this case a cipher is used instead of a hash.
2221 const unsigned char *in,
2224 This will send \textit{inlen} bytes from \textit{in} through the active OMAC state \textit{state}. Returns \textbf{CRYPT\_OK} if the
2248 specification states that the output may be truncated. So if you pass in $outlen = 5$ and use AES as your cipher than
2252 Similar to the HMAC code the file and memory functions are also provided. To OMAC a buffer of memory in
2260 const unsigned char *in, unsigned long inlen,
2263 This will compute the OMAC of \textit{inlen} bytes of \textit{in} using the key \textit{key} of length \textit{keylen} bytes and the cipher
2264 specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with the same
2278 and the cipher specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with
2305 /* get index of Rijndael in cipher descriptor table */
2308 /* we would make up our symmetric key in "key[]" here */
2358 const unsigned char *in,
2361 This will process \textit{inlen} bytes of \textit{in} in the given \textit{state}. The function is not sensitive to the granularity of the
2384 than the size of the tag it is set to the amount of bytes stored in \textit{out}.
2386 Similar to the OMAC code the file and memory functions are also provided. To PMAC a buffer of memory in one shot use the
2394 const unsigned char *in, unsigned long inlen,
2398 specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with the same
2412 and the cipher specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with
2438 const unsigned char *in,
2441 This will process \textit{inlen} bytes of \textit{in} through the Pelican MAC. It's best that you pass in multiples of 16 bytes as it makes the
2442 routine more efficient but you may pass in any length of text. You can call this function as many times as required to process
2466 32 /* key length in octets */
2500 by using a cipher in CBC mode. It also uses a single key which it expands into the requisite three keys for the MAC function. A XCBC--MAC state is
2511 This will initialize the XCBC--MAC state \textit{xcbc}, with the key specified in \textit{key} of length \textit{keylen} octets. The cipher indicated
2519 const unsigned char *in,
2523 This will add the message octets pointed to by \textit{in} of length \textit{inlen} to the XCBC--MAC state pointed to by \textit{state}. Like the other MAC functions,
2535 This will retrieve the XCBC--MAC tag from the state pointed to by \textit{state}, and store it in the array pointed to by \textit{out}. The \textit{outlen} parameter
2545 const unsigned char *in, unsigned long inlen,
2549 specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with the same rules as xcbc\_done().
2562 specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with the same rules as xcbc\_done().
2580 F9--MAC differs slightly from the other MAC functions in that it requires the caller to perform the final message padding. The padding quite simply is a direction
2597 This will initialize the F9--MAC state \textit{f9}, with the key specified in \textit{key} of length \textit{keylen} octets. The cipher indicated
2604 const unsigned char *in,
2608 This will add the message octets pointed to by \textit{in} of length \textit{inlen} to the F9--MAC state pointed to by \textit{state}. Like the other MAC functions,
2620 This will retrieve the F9--MAC tag from the state pointed to by \textit{state}, and store it in the array pointed to by \textit{out}. The \textit{outlen} parameter
2631 const unsigned char *in, unsigned long inlen,
2635 specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with the same rules as f9\_done().
2648 specified by the \textit{cipher}'th entry in the cipher\_descriptor table. It will store the MAC in \textit{out} with the same rules as f9\_done().
2671 This will setup the PRNG for future use and not seed it. In order for the PRNG to be cryptographically useful you must give it
2672 entropy. Ideally you'd have some OS level source to tap like in UNIX. To add entropy to the PRNG call:
2675 int XXX_add_entropy(const unsigned char *in,
2718 int XXX_import(const unsigned char *in,
2723 This will call the start and add\_entropy functions of the given PRNG. It will use the state in
2724 \textit{in} of length \textit{inlen} as the initial seed. You must pass the same seed length as was exported
2741 fresh state. This helps in the case that the program aborts or the machine is powered down without
2760 in the PRNG until ready() is called again. This allows the PRNG to be used and re-seeded at the same time. No real error
2761 checking is guaranteed to see if the entropy is sufficient, or if the PRNG is even in a ready state before reading.
2796 PRNGs have descriptors that allow plugin driven functions to be created using PRNGs. The plugin descriptors are stored in the structure \textit{prng\_descriptor}. The
2801 int export_size; /* size in bytes of exported state */
2823 To find a PRNG in the descriptor table the following function can be used:
2840 descriptor twice, and will return the index of the current placement in the table if the caller attempts to register it more than once. The unregister function
2874 Fortuna is slightly less flexible than Yarrow in the sense that it only works with the AES block cipher
2879 Fortuna is more secure than Yarrow in the sense that attackers who learn parts of the entropy being
2887 RC4 is an old stream cipher that can also double duty as a PRNG in a pinch. You key RC4 by
2891 When you read from RC4, the output is XOR'ed against your buffer you provide. In this manner, you can use rc4\_read()
2906 Unlike Yarrow and Fortuna, all of the entropy (and hence security) of this algorithm rests in the data
2910 Like RC4, the output of SOBER--128 is XOR'ed against the buffer you provide it. In this manner, you can use
2958 An RNG is related to a PRNG in many ways, except that it does not expand a smaller seed to get the data. They generate their random bits
2959 by performing some computation on fresh input bits. Possibly the hardest thing to get correctly in a cryptosystem is the
2973 on most *NIX platforms provides cryptographic random bits\footnote{This device is available in Windows through the Cygwin compiler suite. It emulates \textit{/dev/random} via the Microsoft CSP.}.
2987 the callback in \textit{rng\_get\_bytes()}. It is highly recommended that you use this function to setup your PRNGs unless you have a
3024 It is possible to access the secure RNG through the PRNG interface, and in turn use it within dependent functions such
3057 RSA wrote the PKCS \#1 specifications which detail RSA Public Key Cryptography. In the specifications are
3064 documented later on in this chapter.
3083 parameter indicates the length of the modulus in bits. The padded data is stored in \textit{out} with a length of \textit{outlen} octets. The output will not be
3102 This will remove the PKCS padding data pointed to by \textit{msg} of length \textit{msglen}. The decoded data is stored in \textit{out} of length
3103 \textit{outlen}. If the padding is valid, a 1 is stored in \textit{is\_valid}, otherwise, a 0 is stored. The \textit{block\_type} parameter must be set to either
3133 OAEP encoding requires the length of the modulus in bits in order to calculate the size of the output. This is passed as the parameter
3135 used but both the encoder and decoder must use the same hash in order for this to succeed. The size of hash output affects the maximum
3137 The padded message is stored in \textit{out} along with the length in \textit{outlen}.
3139 If $h$ is the length of the hash and $m$ the length of the modulus (both in octets) then the maximum payload for \textit{msg} is
3163 match what was used during encoding this function will not decode the packet. \textit{modulus\_bitlen} is the size of the RSA modulus in bits
3168 $1$ in \textit{res}. If the packet is invalid it stores $0$ in \textit{res} and if the function fails for another reason
3191 \textit{msghashlen}. PSS allows a variable length random salt (it can be zero length) to be introduced in the signature process.
3195 Similar to OAEP encoding \textit{modulus\_bitlen} is the size of the RSA modulus (in bits). It limits the size of the salt. If $m$ is the length
3196 of the modulus $h$ the length of the hash output (in octets) then there can be $m - h - 2$ bytes of salt.
3216 This will decode the PSS encoded message in \textit{sig} of length \textit{siglen} and compare it to values in \textit{msghash} of length
3218 it is set to zero. The rest of the parameters are as in the PSS encode call.
3243 the plaintext to be encrypted than it is possible that $M^3 < N$ in which case finding the cube-root would be trivial.
3265 Where \textit{wprng} is the index into the PRNG descriptor array. The \textit{size} parameter is the size in bytes of the RSA modulus desired.
3268 least 128 bytes, and no more than 512 bytes in size (\textit{that is from 1024 to 4096 bits}).
3278 PK\_PRIVATE type.} in the form of a RSAPrivateKey (PKCS \#1 compliant). The second type, is a public RSA key which only includes the modulus and public exponent.
3285 int rsa_exptmod(const unsigned char *in,
3292 This will load the bignum from \textit{in} as a big endian integer in the format PKCS \#1 specifies, raises it to either \textit{e} or \textit{d} and stores the result
3293 in \textit{out} and the size of the result in \textit{outlen}. \textit{which} is set to {\bf PK\_PUBLIC} to use \textit{e}
3299 Normally RSA is used to encrypt short symmetric keys which are then used in block ciphers to encrypt a message.
3305 const unsigned char *in,
3316 This function will OAEP pad \textit{in} of length \textit{inlen} bytes, RSA encrypt it, and store the ciphertext
3317 in \textit{out} of length \textit{outlen} octets. The \textit{lparam} and \textit{lparamlen} are the same parameters you would pass
3321 As of v1.15, the library supports both v1.5 and v2.1 PKCS \#1 style paddings in these higher level functions. The following is the extended
3327 const unsigned char *in,
3350 const unsigned char *in,
3360 This function will RSA decrypt \textit{in} of length \textit{inlen} then OAEP de-pad the resulting data and store it in
3367 As of v1.15, the library supports both v1.5 and v2.1 PKCS \#1 style paddings in these higher level functions. The following is the extended
3373 const unsigned char *in,
3397 int rsa_sign_hash(const unsigned char *in,
3408 This will PSS encode the message digest pointed to by \textit{in} of length \textit{inlen} octets. Next, the PSS encoded hash will be RSA
3409 \textit{signed} and the output stored in the buffer pointed to by \textit{out} of length \textit{outlen} octets.
3414 the RSA modulus (in octets), and \textit{hLen} is the length of the message digest produced by the chosen hash.
3423 const unsigned char *in,
3435 This will PKCS encode the message digest pointed to by \textit{in} of length \textit{inlen} octets. Next, the PKCS encoded hash will be RSA
3436 \textit{signed} and the output stored in the buffer pointed to by \textit{out} of length \textit{outlen} octets. The \textit{padding} parameter
3506 /* register a math library (in this case TomsFastMath)
3527 /* fill in pt[] with a key we want to send ... */
3579 This will export the RSA key in either a RSAPublicKey or RSAPrivateKey (PKCS \#1 types) depending on the value of \textit{type}. When it is
3587 int rsa_import(const unsigned char *in,
3592 This will import the key stored in \textit{inlen} and import it to \textit{key}. If the function fails it will automatically free any allocated memory. This
3596 import the key, strip off the additional data (it's the preferred hash) and fill in the rsa\_key structure as if it were a native RSAPublicKey. Note that
3597 there is no function provided to export in this format.
3603 Diffie-Hellman routines in the previous chapter. Elliptic curves (of certain forms) have the benefit that they are harder
3604 to attack (no sub-exponential attacks exist unlike normal DH crypto) in fact the fastest attack requires the square root
3605 of the order of the base point in time. That means if you use a base point of order $2^{192}$ (which would represent a
3606 192-bit key) then the work factor is $2^{96}$ in order to find the secret key.
3608 The curves in this library are taken from the following website:
3621 The variable $b$ is chosen such that the number of points is nearly maximal. In fact the order of the base points $\beta$
3623 range in order from $\approx 2^{112}$ points to $\approx 2^{521}$. According to the source document any key size greater
3640 The optimization works by using a Fixed Point multiplier on any base point you use twice or more in a short period of time. It has a limited size
3642 pre--computation phase, and then the fixed point algorithm can be used. For example, if you use a NIST base point twice in a row, the 2$^{nd}$ and
3663 LibTomCrypt uses a unique format for ECC public and private keys. While ANSI X9.63 partially specifies key formats, it does it in a less than ideally simple manner. \
3664 In the case of LibTomCrypt, it is meant \textbf{solely} for NIST and SECG $GF(p)$ curves. The format of the keys is as follows:
3671 keySize INTEGER, -- Curve size (in bits) divided by eight
3679 keySize INTEGER, -- Curve size (in bits) divided by eight
3700 /** The size of the curve in octets */
3706 /** The prime that defines the field (encoded in hex) */
3723 The curve must be of the form $y^2 = x^3 - 3x + b$, and all of the integer parameters are encoded in hexadecimal format.
3736 The \textit{keysize} is the size of the modulus in bytes desired. Currently directly supported values are 12, 16, 20, 24, 28, 32, 48, and 65 bytes which
3779 int ecc_import(const unsigned char *in,
3783 This will import the ECC key from \textit{in}, and store it in the ecc\_key structure pointed to by \textit{key}. If the operation fails it will free
3791 int ecc_import_ex(const unsigned char *in,
3796 This will import the key from the array pointed to by \textit{in} of length \textit{inlen} octets. The key is stored in
3801 The following function exports an ECC public key in the ANSI X9.63 format:
3809 The ECC key pointed to by \textit{key} is exported in public fashion to the array pointed to by \textit{out}. The ANSI X9.63 format used is from
3817 int ecc_ansi_x963_import(const unsigned char *in,
3821 This will import the key stored in the array pointed to by \textit{in} of length \textit{inlen} octets. The imported key is stored in the ECC key pointed to by
3829 int ecc_ansi_x963_import_ex(const unsigned char *in,
3834 This will import the key stored in the array pointed to by \textit{in} of length \textit{inlen} octets using the domain parameters pointed to by \textit{dp}.
3835 The imported key is stored in the ECC key pointed to by \textit{key}. The function will free any allocated memory upon error.
3847 Note: this function stores only the $x$ co-ordinate of the shared elliptic point as described in ANSI X9.63 ECC--DH.
3857 int ecc_encrypt_key(const unsigned char *in,
3868 plaintext in the array pointed to by \textit{in} of length \textit{inlen} octets. It uses the public ECC key pointed to by \textit{key}, and
3869 hash algorithm indexed by \textit{hash} to construct a shared secret which may be XOR'ed against the plaintext. The ciphertext is stored in
3878 int ecc_decrypt_key(const unsigned char *in,
3887 to use some form of challenge response in that case (e.g. compute a MAC of a known string).
3903 There are also functions to sign and verify messages. They use the ANSI X9.62 EC-DSA algorithm to generate and verify signatures in the
3911 int ecc_sign_hash(const unsigned char *in,
3920 This function will EC--DSA sign the message digest stored in the array pointed to by \textit{in} of length \textit{inlen} octets. The signature
3921 will be stored in the array pointed to by \textit{out} of length \textit{outlen} octets. The function requires a properly seeded PRNG, and
3935 This function will verify the EC-DSA signature in the array pointed to by \textit{sig} of length \textit{siglen} octets, against the message digest
3936 pointed to by the array \textit{hash} of length \textit{hashlen}. It will store a non--zero value in \textit{stat} if the signature is valid. Note:
3944 With ECC if you try to sign a hash that is bigger than your ECC key you can run into problems. The math will still work, and in effect the signature will still
3946 SHA256 and an ECC-192 key, you in effect have 96--bits of security.
3992 The leading BIT STRING has a single bit in it which is zero for public keys and one for private keys. This makes the structure uniquely decodable,
4005 \textit{modulus\_size} control the difficulty of forging a signature. Both parameters are in bytes. The larger the
4037 \item $x$ a random secret (the secret key) in the range $1 < x < q$
4068 This will test \textit{key} and store the result in \textit{stat}. If the result is $stat = 0$ the DSA key failed one of the tests
4077 int dsa_sign_hash(const unsigned char *in,
4086 Which will sign the data in \textit{in} of length \textit{inlen} bytes. The signature is stored in \textit{out} and the size
4087 of the signature in \textit{outlen}. If the signature is longer than the size you initially specify in \textit{outlen} nothing
4102 Which will verify the data in \textit{hash} of length \textit{inlen} against the signature stored in \textit{sig} of length \textit{siglen}.
4115 int dsa_encrypt_key(const unsigned char *in,
4125 This will encrypt the payload in \textit{in} of length \textit{inlen} and store the ciphertext in the output buffer \textit{out}. The
4133 int dsa_decrypt_key(const unsigned char *in,
4139 This will decrypt the ciphertext \textit{in} of length \textit{inlen}, and store the original payload in \textit{out} of length \textit{outlen}.
4153 This will export the DSA \textit{key} to the buffer \textit{out} and set the length in \textit{outlen} (which must have been previously
4162 int dsa_import(const unsigned char *in,
4167 This will import the DSA key from the buffer \textit{in} of length \textit{inlen} to the \textit{key}. If the process fails the function
4168 will automatically free all of the heap allocated in the process (you don't have to call dsa\_free()).
4173 are all provided with three basic functions with \textit{similar} prototypes. One function has been dedicated to calculate the length in octets of a given
4177 in the same manner as the other data types except they use list of objects known as the \textbf{ltc\_asn1\_list} structure. It is defined as the following:
4193 \textit{size} field is specific to what you are encoding (e.g. number of bits in the BIT STRING data type). The \textit{used} field is primarily for the CHOICE decoder
4194 and reflects if the particular member of a list was the decoded data type. To help build the lists in an orderly fashion the macro
4197 It will assign to the \textit{index}th position in the \textit{list} the triplet (Type, Data, Size). An example usage would be:
4254 The SEQUENCE data type is a collection of other ASN.1 data types encapsulated with a small header which is a useful way of sending multiple data types in one packet.
4267 This encodes a sequence of items pointed to by \textit{list} where the list has \textit{inlen} items in it. The SEQUENCE will be encoded to \textit{out} and of length \textit{outlen}. The
4268 function will terminate when it reads all the items out of the list (upto \textit{inlen}) or it encounters an item in the list with a type of \textbf{LTC\_ASN1\_EOL}.
4270 The \textit{data} pointer in the list would be the same pointer you would pass to the respective ASN.1 encoder (e.g. der\_encode\_bit\_string()) and it is simply passed on
4271 verbatim to the dependent encoder. The list can contain other SEQUENCE or SET types which enables you to have nested SEQUENCE and SET definitions. In these cases
4278 Decoding a SEQUENCE is similar to encoding. You set up an array of \textbf{ltc\_asn1\_list} where in this case the \textit{size} member is the maximum size
4279 (in certain cases). For types such as IA5 STRING, BIT STRING, OCTET STRING (etc) the \textit{size} field is updated after successful decoding to reflect how many
4283 int der_decode_sequence(const unsigned char *in,
4289 This will decode upto \textit{outlen} items from the input buffer \textit{in} of length \textit{inlen} octets. The function will stop (gracefully) when it runs out of items to decode.
4312 This will get the encoding size for the given \textit{list} of length \textit{inlen} and store it in \textit{outlen}.
4325 int der_decode_sequence_multi(const unsigned char *in,
4329 These either encode or decode (respectively) a SEQUENCE data type where the items in the sequence are specified after the length parameter.
4360 SET and SET OF are related to the SEQUENCE type in that they can be pretty much be decoded with the same code. However, they are different, and they should
4362 a \textbf{single} ASN.1 object sorted in ascending order by the DER their respective encodings.
4376 This will encode the list of ASN.1 objects in \textit{list} of length \textit{inlen} objects, and store the output in \textit{out} of length \textit{outlen} bytes.
4377 The function will make a copy of the list provided, and sort it by the TAG. Objects with identical TAGs are additionally sorted on their original placement in the
4388 int der_decode_set(const unsigned char *in,
4394 This will decode the SET specified by \textit{list} of length \textit{outlen} objects from the input buffer \textit{in} of length \textit{inlen} octets.
4402 A \textit{SET OF} object is an array of identical objects (e.g. OCTET STRING) sorted in ascending order by the DER encoding of the object. They are
4414 This will encode a \textit{SET OF} containing the \textit{list} of \textit{inlen} ASN.1 objects and store the encoding in the output buffer \textit{out} of length \textit{outlen}.
4416 The routine will first encode the SET OF in an unordered fashion (in a temporary buffer) then sort using the XQSORT macro and copy back to the output buffer. This
4435 int der_decode_integer(const unsigned char *in,
4452 int der_decode_short_integer(const unsigned char *in,
4460 These will encode or decode an unsigned \textbf{unsigned long} type (only reads upto 32--bits). For values in the range $0 \dots 2^{32} - 1$ the integer
4467 int der_encode_bit_string(const unsigned char *in,
4472 int der_decode_bit_string(const unsigned char *in,
4481 These will encode or decode a BIT STRING data type. The bits are passed in (or read out) using one \textbf{char} per bit. A non--zero value will be interpreted
4488 int der_encode_octet_string(const unsigned char *in,
4493 int der_decode_octet_string(const unsigned char *in,
4513 int der_decode_object_identifier(const unsigned char *in,
4523 These will encode or decode an OBJECT IDENTIFIER object. The words of the OID are stored in individual \textbf{unsigned long} elements, and must be in the range
4530 int der_encode_ia5_string(const unsigned char *in,
4535 int der_decode_ia5_string(const unsigned char *in,
4545 These will encode or decode an IA5 STRING. The characters are read or stored in individual \textbf{char} elements. These functions performs internal character
4554 int der_encode_printable_string(const unsigned char *in,
4559 int der_decode_printable_string(const unsigned char *in,
4569 These will encode or decode an PRINTABLE STRING. The characters are read or stored in individual \textbf{char} elements. These functions performs internal character
4578 int der_encode_utf8_string(const wchar_t *in,
4583 int der_decode_utf8_string(const unsigned char *in,
4593 These will encode or decode an UTF8 STRING. The characters are read or stored in individual \textbf{wchar\_t} elements. These function performs no internal
4596 These functions use the \textbf{wchar\_t} type which is not universally available. In those cases, the library will typedef it to \textbf{unsigned long}. If you
4601 The UTCTIME type is to store a date and time in ASN.1 format. It uses the following structure to organize the time.
4628 int der_decode_utctime(const unsigned char *in,
4636 The encoder will store time in one of the two ASN.1 formats, either \textit{YYMMDDhhmmssZ} or \textit{YYMMDDhhmmss$\pm$hhmm}, and perform minimal error checking on the
4639 It is suggested that decoded data be further scrutinized (e.g. days of month in particular).
4643 The CHOICE ASN.1 type represents a union of ASN.1 types all of which are stored in a \textit{ltc\_asn1\_list}. There is no encoder for the CHOICE type, only a
4651 int der_decode_choice(const unsigned char *in,
4657 This will decode the input in the \textit{in} field of length \textit{inlen}. It uses the provided ASN.1 list specified in the \textit{list} field which has
4658 \textit{outlen} elements. The \textit{inlen} field will be updated with the length of the decoded data type, as well as the respective entry in the \textit{list} field
4663 the structure of the data. Where der\_decode \_sequence() requires the developer to specify the data types to decode in advance the flexi decoder is entirely
4666 The flexi decoder uses the same \textit{ltc\_asn1\_list} but instead of being stored in an array it uses the linked list pointers \textit{prev}, \textit{next}, \textit{parent}
4668 encoded in a SEQUENCE are stored as a child element.
4675 int der_decode_sequence_flexi(const unsigned char *in,
4680 This will decode items in the \textit{in} buffer of max input length \textit{inlen} and store the newly created pointer to the list in \textit{out}. This function allocates
4688 \textbf{Note:} the list decoded by this function is \textbf{NOT} in the correct form for der\_encode\_sequence() to use directly. You will have to first
4689 have to convert the list by first storing all of the siblings in an array then storing all the children as sub-lists of a sequence using the \textit{.data}
4690 pointer. Currently no function in LibTomCrypt provides this ability.
4746 At this point, we are pointing to the last node of the list. Lists are terminated in all directions by a \textbf{NULL} pointer. All nodes are doubly linked so that you
4758 void der_sequence_free(ltc_asn1_list *in);
4766 In order to securely handle user passwords for the purposes of creating session keys and chaining IVs the PKCS \#5 was drafted. PKCS \#5
4785 Where \textit{password} is the user's password. Since the algorithm allows binary passwords you must also specify the length in \textit{password\_len}.
4787 on the password. The \textit{hash\_idx} is the index of the hash you wish to use in the descriptor table.
4789 The output of length up to \textit{outlen} is stored in \textit{out}. If \textit{outlen} is initially larger than the size of the hash functions output
4790 it is set to the number of bytes stored. If it is smaller than not all of the hash output is stored in \textit{out}.
4809 Where \textit{password} is the users password. Since the algorithm allows binary passwords you must also specify the length in \textit{password\_len}.
4811 on the password. The \textit{hash\_idx} is the index of the hash you wish to use in the descriptor table. The output of length up to
4812 \textit{outlen} is stored in \textit{out}.
4830 /* create the material (100 iterations in algorithm) */
4844 /* use material (recall to store the salt in the output) */
4850 The library provides functions to encode and decode a RFC 1521 base--64 coding scheme. The characters used in the mappings are:
4854 Those characters are supported in the 7-bit ASCII map, which means they can be used for transport over
4859 Often, it is desirable to line wrap the output to fit nicely in an e-mail or usenet posting. The decoder allows you to
4860 put any character (that is not in the above sequence) in between any character of the encoders output. You may not however,
4863 To encode a binary string in base64 call:
4866 int base64_encode(const unsigned char *in,
4871 Where \textit{in} is the binary string and \textit{out} is where the ASCII output is placed. You must set the value of \textit{outlen} prior
4872 to calling this function and it sets the length of the base64 output in \textit{outlen} when it is done. To decode a base64
4875 int base64_decode(const unsigned char *in,
4883 The library includes primality testing and random prime functions as well. The primality tester will perform the test in
4888 $\left ( { 1 \over 4 } \right )^{8} = 2^{-16}$. In practice the probability of error is in fact much lower than that.
4890 When making random primes the trial division step is in fact an optimized implementation of \textit{Implementation of Fast RSA Key Generation on Smart Cards}\footnote{Chenghuai Lu, Andre L. M. dos Santos and Francisco R. Pimentel}.
4891 In essence a table of machine-word sized residues are kept of a candidate modulo a set of primes. When the candidate
4896 In the event that a composite did make it through it would most likely cause the the algorithm trying to use it to fail. For
4897 instance, in RSA two primes $p$ and $q$ are required. The order of the multiplicative sub-group (modulo $pq$) is given
4908 This puts a one in \textit{result} if the number is probably prime, otherwise it places a zero in it. It is assumed that if
4909 it returns an error that the value in \textit{result} is undefined. To make
4917 Where \textit{len} is the size of the prime in bytes ($2 \le len \le 256$). You can set \textit{len} to the negative size you want
5026 pthreads based mutex locking in various routines such as the Yarrow and Fortuna PRNGs, the fixed point ECC multiplier, and other routines.
5090 All four can be used to create custom install locations depending on the nature of the OS and file system in use.
5136 \textbf{EXTRALIBS} specifies any extra libraries required to link the test programs and shared libraries. They are specified in the notation
5158 That will build LibTomCrypt (including the TomsFastMath descriptor), and install it in the default locations indicated previously. You can enable
5159 the built--in LibTomMath descriptor as well (or in place of the TomsFastMath descriptor). Similarly, you can build the library with no built--in
5166 In this case, no math descriptors are present in the library and they will have to be made available at build or run time before you can use any of the
5169 Note that even if you include the built--in descriptors you must link against the source library as well.
5193 stored in \textit{tomcrypt\_custom.h} which allow the enabling and disabling of various algorithms.
5218 the name of the respective functions from the standard C library by default. This lets you substitute in your own memory routines.
5219 If you substitute in your own functions they must behave like the standard C library functions in terms of what they expect as input and
5230 During the build if LTC\_NO\_FILE is defined then any function in the library that uses file I/O will not call the file I/O
5239 When this has been defined the various self--test functions (for ciphers, hashes, prngs, etc) are included in the build. This is the default configuration.
5248 cbc\_encrypt() that it can safely XOR multiple octets in one step by using a larger data type. This has the benefit of
5255 In practice however, you can use it on pretty much any platform (even MIPS) with care.
5263 The simplest precaution is to make sure you process all data in power of two blocks and handle \textit{remainder} at the end. e.g. If you are
5264 CTR'ing a long stream process it in blocks of (say) four kilobytes and handle any remaining incomplete blocks at the end of the stream.
5279 dependency issues which are noted in the file. For instance, Yarrow requires CTR chaining mode, a block
5291 to allow some trade-offs in the implementation. When TWOFISH\_SMALL is defined the scheduled symmetric key for Twofish
5296 When TWOFISH\_TABLES is defined the cipher will use pre-computed (and fixed in code) tables required to work. This is
5322 When this has been defined the ECC point multiplier (built--in to the library) will use a timing resistant point multiplication
5329 descriptors for the respective library are built and included in the library as \textit{gmp\_desc}, \textit{ltm\_desc}, or \textit{tfm\_desc} respectively.
5331 In the test demos that use the libraries the additional flags \textbf{USE\_GMP}, \textbf{USE\_LTM}, and \textbf{USE\_TFM} can be defined
5342 That will build and install the library with all descriptors (and link against all), but only use TomsFastMath in the timing demo.
5346 The entire API was designed with plug and play in mind at the low level. That is you can swap out any cipher, hash, PRNG or bignum library and the dependent API will not
5351 That works well for most cases but there are times where performance is of the essence. This API allows optimized routines to be dropped in--place of the existing
5357 development simple. In most dependent routines all an end developer has to do is register\_XXX() the descriptor and they are set.
5360 The ciphers in LibTomCrypt are accessed through the ltc\_cipher\_descriptor structure.
5428 @param keysize [in/out] The size of the key desired
5547 @param taglen [in/out] The max size and resulting size
5573 @param taglen [in/out] The MAC tag length
5589 @param in The message
5592 @param outlen [in/out] Initial and final size of out
5597 const unsigned char *in, unsigned long inlen,
5603 @param in The message
5606 @param outlen [in/out] Initial and final size of out
5611 const unsigned char *in, unsigned long inlen,
5617 @param in The message
5620 @param outlen [in/out] Initial and final size of out
5626 const unsigned char *in, unsigned long inlen,
5634 The \textit{name} parameter specifies the name of the cipher. This is what a developer would pass to find\_cipher() to find the cipher in the descriptor
5641 The minimum key length is \textit{min\_key\_length} and is measured in octets. Similarly the maximum key length is \textit{max\_key\_length}. They can be equal
5642 and both must valid key sizes for the cipher. Values in between are not assumed to be valid though they may be.
5645 The size of the ciphers plaintext or ciphertext is \textit{block\_length} and is measured in octets.
5653 in \textit{skey}.
5656 ones provided. Just make sure in your \textit{done()} function that you free the allocated memory.
5659 To process a single block in ECB mode the ecb\_encrypt() and ecb\_decrypt() functions were provided. The plaintext and ciphertext buffers are allowed to overlap so you
5669 example, if the input is $25$ and $24$ is valid then it stores $24$ back in the pointed to integer. It must not round up and must return an error if the keysize
5674 it is not supported. In those cases the software defaults are used (using the single ECB block routines).
5677 These two functions are meant for cases where a user wants to encrypt (in ECB mode no less) an array of blocks. These functions are accessed
5700 The \textit{CTR pad} is empty when a multiple (including zero) blocks of text have been processed. That is, if you pass in seven bytes to AES--CTR mode you would have to
5701 pass in a minimum of nine extra bytes before the accelerator could be called. The CTR accelerator must increment the counter (and store it back into the
5704 The accelerator will only be used to encrypt whole blocks. Partial blocks are always handled in software.
5707 These functions are meant for accelerated LRW. They process blocks of input in lengths of multiples of 16 octets. They must accept the \textit{IV} and \textit{tweak}
5708 state variables and updated them prior to returning. Note that you may want to disable \textbf{LRW\_TABLES} in \textit{tomcrypt\_custom.h} if you intend
5714 if your device requires any (LRW specific) resources you should free them in your ciphers() done function. The simplest way to think of it is to write
5719 This function is meant for accelerated CCM encryption or decryption. It processes the entire packet in one call. You can optimize the work flow somewhat
5740 This function is meant for accelerated GCM encryption or decryption. It processes the entire packet in one call. Note that the setup() function will not
5754 the caller to perform any 3GPP related padding before calling in order to ensure proper compliance with F9.
5769 /** Size of digest in octets */
5772 /** Input block size in octets */
5789 @param in The data to hash
5794 const unsigned char *in,
5817 const unsigned char *in,
5832 The \textit{hashsize} variable indicates the length of the output in octets.
5835 The \textit{blocksize} variable indicates the length of input (in octets) that the hash processes in a given
5846 guaranteed to be a multiple of the block size in length.
5852 A compatible accelerator must allow processing data in any granularity which may require internal padding on the driver side.
5856 to be able to process multiple blocks per MAC then you will have to simply provide a process() callback and use hmac\_memory() as provided in LibTomCrypt.
5867 /** size in bytes of exported state */
5877 @param in The entropy
5882 int (*add_entropy)(const unsigned char *in,
5910 @param outlen [in/out] The max size and resulting size
5919 @param in The data to import
5924 int (*pimport)(const unsigned char *in,
5941 When an PRNG state is to be exported for future use you specify the space required in this variable.
5965 The library also makes use of the math descriptors to access math functions. While bignum math libraries usually differ in implementation
5975 /** Bits per digit, amount of bits must fit in an unsigned long */
6067 @param a The integer to store the power in
6078 @param radix The radix the integer has been represented in (2-64)
6086 @param radix The radix the integer is to be represented in (2-64)
6093 @return The length of the integer in octets
6099 @param dst The buffer to store the integer in
6127 (single digit of upto bits_per_digit in length)
6144 (single digit of upto bits_per_digit in length)
6153 (single digit of upto bits_per_digit in length)
6162 (single digit of upto bits_per_digit in length)
6193 @param b The modulus (upto bits_per_digit in length)
6296 (can be ignored if you work in affine only)
6337 @remark The mapping can be different but keep in mind a
6363 @param size The size of the key in octets
6376 @param in The octet array representing the base
6378 @param out The destination (to be stored in an octet array format)
6385 int (*rsa_me)(const unsigned char *in, unsigned long inlen,
6398 free the bignum as well as the structure you allocated to place it in.
6409 The ECC system in LibTomCrypt is based off of the NIST recommended curves over $GF(p)$ and is used to implement EC-DSA and EC-DH. The ECC functions work with
6410 the \textbf{ecc\_point} structure and assume the points are stored in Jacobian projective format.
6413 /** A point on a ECC curve, stored in Jacobian format such
6427 could point to anything you want. The only further exception is the export functions which expects the values to be in affine format.
6430 This will multiply the point $G$ by the scalar $k$ and store the result in the point $R$. The value should be mapped to affine only if $map$ is set to one.
6433 This will add the point $P$ to the point $Q$ and store it in the point $R$. The $mp$ parameter is the \textit{b} value from the montgomery\_setup() call. The input points
6434 may be in either affine (with $z = 1$) or projective format and the output point is always projective.
6442 To accelerate EC--DSA verification the library provides a built--in function called ltc\_ecc\_mul2add(). This performs two point multiplications and an addition in
6444 overlap (e.g., $A \leftarrow k_1A + k_2B$) and must return the final point in affine format.
6448 The RSA Modular Exponentiation (ME) function is used by the RSA API to perform exponentiations for private and public key operations. In particular for
6475 The call reads the \textit{in} buffer as an unsigned char array in big endian format. Then it performs the exponentiation and stores the output in big endian format
6476 to the \textit{out} buffer. The output must be zero padded (leading bytes) so that the length of the output matches the length of the modulus (in bytes). For example,
6479 Since the function is given the entire RSA key (for private keys only) CRT is possible as prescribed in the PKCS \#1 v2.1 specification.
