Asymmetric Ciphers

Where an asymmetric cipher requires an encoding method in order to be specified completely, the naming convention is "encryption-primitive/encryption-encoding".

Some existing JCE providers will accept the use of a block cipher mode and padding with an asymmetric cipher (e.g. "RSA/CBC/PKCS#7"); this is not recommended, and new providers MUST reject this usage. An encryption primitive name on its own (e.g. "RSA", as opposed to a complete encryption scheme such as "DLIES-ISO(...)") SHOULD also be rejected.

All of the algorithms defined here use either modular exponentiation or elliptic curve multiplication, which are potentially vulnerable to timing attacks. See the following paper for details and possible countermeasures:

Generally, even if the same key pair can be used for different algorithms, this should not be done, since it will invalidate any security proofs associated with the algorithms and may permit attacks. This requirement can be achieved by associating an unambiguous specification of the algorithm with the public key when it is included in a certificate, or otherwise authenticated.

× DLIES-ISO(prf,dem) Asymmetric Cipher Construction
Designers:
Michel Abdalla, Mihir Bellare, Phillip Rogaway
Published:
August 1998, updated March 1999
Description:
[[DLIES-compatible scheme from Shoup's ISO paper, restricted to secure options.]] Public and private keys belong to the "DH" key family.
References:
Parameters:
Comments:
Security comments:

× ECIES-ISO(prf,dem) Asymmetric Cipher Construction
Designers:
Michel Abdalla, Mihir Bellare, Phillip Rogaway
Published:
August 1998, updated March 1999
Description:
[[ECIES-compatible scheme from Shoup's ISO paper, restricted to secure options.]] Public and private keys belong to the "ECDH" key family.
References:
Parameters:
Comments:
Security comments:

ElgamalEnc/encoding Asymmetric Cipher
Designer:
Taher Elgamal
References:
Comments:

RSA/encoding Asymmetric Cipher
Designers:
Ron Rivest, Adi Shamir, Leonard Adelman
Aliases:
"RSAES", "1.2.840.113549.1.1.1", "2.5.8.1.1"
References:
Comment:
It is recommended that implementations make no practical restriction on the lengths of the key parameters n and e (in particular, values of n up to at least 4096 bits SHOULD be supported).
Patent status:
RSA is patented in the United States and Canada (see references); the patent is licensed by RSA Data Security, Inc.

Asymmetric Cipher Encoding Methods

Note that any parameters required by Asymmetric Cipher Encoding Methods are set and retrieved by calling set/getParameter on the Cipher object, since there is not necessarily any object explicitly representing the encoding method.

OAEP-MGF1(digest) Asymmetric Cipher Encoding Method
Designers:
Mihir Bellare, Phillip Rogaway
Description:
Optimal Asymmetric Encryption Padding with Mask Generation Function 1, as specified in PKCS #1 v2.0 and IEEE Std 1363-2000.
Alias:
"EME-OAEP", "EME1"
References:
Parameters:
Comments:
The 'digestName' and 'diversifier' parameters in SCAN 1.0.16 have been renamed 'digest' and 'parameters' respectively. This is an incompatible change.
Security comments:
The original security proof that OAEP converts any trapdoor-one-way function into an encryption scheme that is secure under adaptive chosen ciphertext attack (IND-CCA2), is flawed (see the "OAEP Reconsidered" paper). The "RSA-OAEP is Still Alive!" paper shows that RSA-OAEP can still be proven IND-CCA2-secure for the RSA function, but with a reduction that is less tight. See Shoup's ISO paper for further discussion.

× KEM(prf,dem) Asymmetric Cipher Encoding Method
Designers:
Victor Shoup
Description:
[[TBD]]
References:
Parameters:

PKCS1-1.5 Asymmetric Cipher Encoding Method
Designers:
RSA Data Security, Inc.
Description:
Block type 02, described in section 8 of PKCS #1 v1.5.
Aliases:
"PKCS#1", "PKCS1Padding", "EME-PKCS1-v1_5"
References:
Comment:
Some existing implementations of PKCS1-1.5 only support moduli that are a multiple of 8 bits in length. The standard in fact makes no such restriction, and SCAN requires that bit lengths that are not a multiple of 8 MUST be supported.
Security comment:
The attack described in Bleichenbacher's paper relies on being able to determine whether decrypting a chosen ciphertext yields a valid PKCS1-1.5 block. Applications and protocols that use PKCS1-1.5 should therefore ensure that no information is leaked to an attacker (also taking into account timing differences and other potential side channels) about whether a decrypted block is valid.

It is recommended that new protocols use OAEP-MGF1 or KEM in preference to PKCS1-1.5.

Raw Asymmetric Cipher Encoding Method
Description:
A "null" encoding method, that passes its input directly to the underlying primitive. The block length is as large as necessary to ensure that all inputs to the public key primitive are possible (and no larger). This usually means that some block contents will not be valid; these will cause an IllegalArgumentException when the Cipher object's update or doFinal methods are called.
Security comment:
There are many attacks possible on public key encryption algorithms when this encoding method is used. It is intended only as a way to obtain access to a public key primitive (for those providers that support it), in order to implement encoding methods at the application rather than the provider level, or to maintain compatibility with legacy protocols.
Valid HTML 4.0 Valid CSS Copyright and trademarks