Asymmetric +ciphers -- guide

What is asymmetric cryptography?
Types of asymmetric algorithms supported
Base classes and their derived classes

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.

+The diagram above shows the encryption and decryption process using: +an asymmetric algorithm; a plaintext message, M; a private key, K1, and a +public key, K2 (or vice versa); and the ciphertext, K1(M). + +

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:

+ + + +

Asymmetric algorithm

What it's used for

Specified in:

+ + + + +

RSA

both encryption and digital signatures

PKCS#1 v1.5

+ + +

DSA (Digital Signature Algorithm)

signing data

FIPS 186-2 CR1

+ + +

DH (Diffie-Hellman)

secure exchange of keys between two parties

PKCS#3

+ + + +

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

+The inheritance diagram above shows the <codeph>RInteger</codeph> and <codeph>CRSAParameters</codeph> classes, +and also the <codeph>CEncryptor</codeph>, <codeph>CDecryptor</codeph> and <codeph>CPadding</codeph> abstract +classes. Also shown are the following classes from the Cryptography API: <codeph>TInteger</codeph>, <codeph>MCryptoSystem</codeph>, <codeph>CRSAPKCS1v15Decryptor</codeph>, <codeph>CRSAPKCS1v15Encryptor</codeph>, <codeph>CRSAPrivateKey</codeph>, <codeph>CRSAPublicKey</codeph>, <codeph>CRSAPrivateKeyStandard</codeph>, <codeph>CRSAPrivateKeyCRT</codeph>, <codeph>CRSAKeyPair</codeph>, <codeph>CPaddingPKCS7</codeph>, <codeph>CPaddingPKCS1Encryption</codeph>, <codeph>CPaddingNone</codeph>, <codeph>CPaddingPKCS1Signature</codeph>, and <codeph>CPaddingSSLv3</codeph>. + + + +The inheritance diagram above shows the <codeph>CRSASigner</codeph> and <codeph>CRSAVerifier</codeph> classes. +Also shown are the following classes from the Cryptography API: <codeph>MSignatureSystem</codeph>, <codeph>CSigner</codeph>, <codeph>CRSAPKCS1v15Signer</codeph>, <codeph>CRSAParameters</codeph>, <codeph>CRSAPrivateKey</codeph>, <codeph>CRSAPublicKey</codeph>, <codeph>CPadding</codeph>, <codeph>CPaddingPKCS1Signature</codeph>, <codeph>CVerifier</codeph>, and <codeph>CRSAPKCS1v15Verifier</codeph>. + + +

DSA and associated classes

+The inheritance diagram above shows the <codeph>CDSAParameters</codeph> class. +Also shown are the following classes from the Cryptography API: <codeph>MSignatureSystem</codeph>, <codeph>TInteger</codeph>, <codeph>RInteger</codeph>, <codeph>CSigner</codeph>, <codeph>CDSASigner</codeph>, <codeph>CDSASignature</codeph>, <codeph>CDSAPrimeCertificate</codeph>, <codeph>CDSAKeyPair</codeph>, <codeph>CDSAPrivateKey</codeph>, <codeph>CDSAPublicKey</codeph>, <codeph>CVerifier</codeph>, +and <codeph>CDSAVerifier</codeph>. + +

DH and associated classes

+ The inheritance diagram above shows the <codeph>CDHParameters</codeph> class. +Also shown are the following classes from the Cryptography API: <codeph>TInteger</codeph>, <codeph>RInteger</codeph>, <codeph>CDHPrivateKey</codeph>, <codeph>CDHPublicKey</codeph>, <codeph>CDH</codeph>, and <codeph>CDHKeyPair</codeph>. + +