# Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

### Protego

# MLA -- Crypto Library

1 January, 2012

- 1
- 2
…
- 18
- 19
- 20
- 21
- 22
…
- 119
- 120

for more information). For XTEA, the block cipher mode module's BLOCK_CIPHER_[mode]_Initialize functions should be
initialized with the XTEA_Encrypt function, the XTEA_Decrypt function, and the XTEA_BLOCK_SIZE block size macro. If an
initialization vector or nonce/counter is required by the block cipher mode being used, it should be 8 bytes long (one block
length).
1.4.3.2 ARCFOUR
Describes how the ARCFOUR module works.
Description
Encrypting or decrypting a message using the ARCFOUR is essentially a two-step process. First, the user will create an
S-Box and initialize a "context" for the ARCFOUR module that will contain a reference to the S-Box and state information
that the ARCFOUR module will use to encrypt or decrypt the message. Then, the user will pass the data to be encrypted and
decrypted to the ARCFOUR module. The module will encrypt/decrypt the data in place.
1.4.3.3 RSA
Describes how the RSA module works.
Description
The RSA module defines DRV_RSA_Initialize/DRV_RSA_Deinitialize functions to initialize and deinitialize the module, and
DRV_RSA_Open/DRV_RSA_Close functions to control assignment of drive handles. These functions are intended to
provide compatibility with hardware RSA modules; if a hardware RSA/Modular Exponentiation driver is used, these functions
will initialize it and assign an instance of the hardware (if multiple instances are available) to the user for the RSA operation
they are attempting to perform. For pure software implementations, the software driver defines default values for
DRV_RSA_HANDLE and DRV_RSA_INDEX that will be used in all cases.
The RSA module can be opened with several intent options. DRV_IO_INTENT_BLOCKING and
DRV_IO_INTENT_NONBLOCKING are used to select whether the module operates in a blocking or non-blocking mode. In
the current implementation, the only client mode supported is DRV_IO_INTENT_EXCLUSIVE, which allows the module to
support one client at a time.
The RSA module currently supports two implementations. The dsPIC-only implementation allows the user to use
DSP-specific instructions to increase performance, but only operates in blocking mode. The other mode will function in
blocking and non-blocking modes and will run on 16-bit architectures, but has a longer execution time than the dsPIC-only
implementation.
Both implementations require the user to provide working buffers in the configuration function. These are referred to as the
xBuffer and yBuffer in the DRV_RSA_Configure function. For the dsPIC implementation, these buffers must be declared in
the dsPIC's x-memory and y-memory respectively, using the attributes, "
__attribute__ ((space(xmemory)))
" and
"
__attribute__ ((space(ymemory))).
" The xMemory buffer must be 64-byte aligned, and the yMemory buffer must
be 4-byte aligned, as well. The xBuffer should be twice as large as the largest supported key length in your application and
the yBuffer should be three times as large as the key length. In the other implementation, the buffers should be aligned to
the word size of the processor, and both should be twice as large as the largest supported key length.
Parameter xBuffer (dsPIC) yBuffer (dsPIC) xBuffer
(other)
ybuffer
(other)
Size (multiple of maximum key length supported) 2 3 2 2
Memory x-memory y-memory RAM RAM
Alignment (byte) 64 2 4 4
The RSA module also requires the user to provide a pointer to a random number generator function for use when padding
the messages. This function must conform to the prototype describes by the DRV_RSA_RandomGet function.
1.4 Using the Library MLA - Crypto Library Help How the Library Works
20

- 1
- 2
…
- 18
- 19
- 20
- 21
- 22
…
- 119
- 120