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>. - -