Asymmetric ciphers -- guide

What is asymmetric cryptography?

Asymmetric ciphers, unlike symmetric ciphers, are algorithms that involve the use of two keys: a private key and a public key. The private key is kept secret, while the public key is made publicly available. For schemes which are thought to be secure, it is believed that deriving the private key from the public key, or any transformation resulting from the public key, is computationally infeasible.

This type of algorithm generates the keys as key pairs. This means that if one key in the pair is used to encrypt some data, only the other key can decrypt it, and vice versa.

Although it varies depending on the specific algorithm, the generation of asymmetric keys is much slower than symmetric key generation.

There are four basic primitives in asymmetric cryptography: encryption and decryption, and signing and verification.

Encryption schemes

In order to encrypt a message with an asymmetric scheme, one performs a well-known transformation on the message using the public key of the intended recipient. Upon receipt, the receiver can decrypt this message using the inverse transformation and the associated private key. Provided that only the intended recipient knows the associated private key, it is believed that message secrecy between the sender and receiver is achieved.

Signature schemes

Conversely, in order to digitally sign a message with an asymmetric scheme, one performs another well-known transformation on the message using one's own private key. Both the original message and the resulting transformation are sent to the intended recipient. Upon receipt, the receiver can verify that the message was signed by the associated private key by performing the inverse operation with the public key as input, and then comparing the received message with the message obtained from the transformation of the signature.

Types of asymmetric algorithms supported

The following asymmetric algorithms are supported:

RSA

The Cryptography library allows support for RSA as specified in PKCS#1 v1.5. The library does not, in and of itself, fulfil all the requirements of PKCS#1 v1.5. This is because the Cryptography library’s modular design allows applications utilizing it to provide their own mechanisms of certain operations. At minimum, signature input data (be prepared in compliance with PKCS#1 v1.5) must be provided by applications in order to support PKCS#1 v1.5.

• Private Key Encryption and Decryption

  RSA private keys provide functionality for encrypting and decrypting data with the private key. Encrypting with the private key is typically used in signature generation while decrypting would be used for key exchange or confidentiality of other small amounts of data.

  The basic mathematics involved in the encryption and decryption is identical, the differences lay with the handling of padding; encryption adds padding while decryption removes and checks it.

• Padding

  For padding the existing PKCS#1 padding mechanism is used. However, this interface allows the use of any defined padding mechanism.

• Key Generation

  Before any private keys can be used they need to be generated. They can be generated on the device or generated elsewhere.

  An RSA modulus takes the form of the product of a pair of large prime numbers, which will be generated randomly and considered prime if they pass a probabilistic primality test (where the chance of claiming a non-prime is prime is less than 1 in 2 ³⁰ ). This generation process can be rather long-winded, even for relatively small keys.

  While there is no actually limit on RSA modulus sizes, for most applications they range from 512 bits to 4096 bits.

DSA

The Cryptography library allows support for NIST Digital Signature Standard (DSS) as specified in FIPS 186-2 change request 1. The standard specifies DSA as the algorithm for digital signatures and SHA-1 for hashing. At minimum, the following items must be provided by applications using the library in order to be fully compliant:

• Signature input data must be hashed with SHA-1 as specified in FIPS 180-1 .

  or should it be

  Signature input data must be hashed with SHA-1 as specified in FIPS 180-2 .

• A FIPS-186-2 CR 1 compliant random number generator must be supplied. The library provides a mechanism for using such a random number generator if required.

• For backwards compatibility reasons, the Cryptography library continues to allow prime moduli of less than 1024 bits to be used. If an application wanted to be fully compliant with the FIPS 186-2 CR1, it should refuse to submit requests to the Cryptography library to sign data with a prime modulus of less than 1024 bits.

The following are some important features of DSA:

• Key Generation

  DSA keys have an associated set of parameters, these parameters are generally public and used across a community of users. If some parameters are supplied the key generation will use those parameters or it will generate a set if there are none supplied.

• Parameter Generation

  Parameter generation for DSA keys is implemented as specified in FIPS-186.

Diffie-Hellman (DH)

The Cryptography library supports Diffie-Hellman as specified in PKCS#3 . Note that due to security concerns and a serious lack of interoperable implementations, the library does not support DH parameter generation. It is up to the application using the DH implementation to ensure that they trust the source of the parameters they intend to use for a DH key exchange.

Base classes and their derived classes

The asymmetric cipher API is used by the certman (certitificate management) component for WTLS and X.509 certificate support and by appinst for SIS file signature verification. It is also used by Networking (TLS/IPSec).

CRSAParameters , CDSAParameters , and CDHParameters are the base classes that allow a client to use the supported asymmetric algorithms listed above. The classes hold the domain parameters used by the public key algorithms. They are used by some of the asymmetric algorithms to define some common mathematical structures used by the encryption or signature processes.

The diagrams below show the main classes used in asymmetric cipher framework. Blue dotted arrows indicate that a class is contained or used by another class. The arrows are labelled with the variable(s) through which the pointed class is accessible. The color of the boxes indicates the type of Symbian class, i.e., M , C , R or T class. For detailed information on each component see the Cryptography API Reference material.

RSA, padding and associated classes

DSA and associated classes

DH and associated classes