Asymmetric Ciphers
Where an asymmetric cipher requires an encoding method in order to be specified completely,
the naming convention is "encryptionprimitive/encryptionencoding".
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 "DLIESISO(...)") 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.
× DLIESISO(prf,dem)  Asymmetric Cipher Construction

 Designers:
 Michel Abdalla,
Mihir Bellare,
Phillip Rogaway
 Published:
 August 1998, updated March 1999
 Description:
 [[DLIEScompatible scheme from Shoup's ISO paper, restricted to
secure options.]] Public and private keys belong to the "DH" key family.
 References:
 [An] Victor Shoup,
"A Proposal for an ISO Standard for Public Key Encryption
(version 2.1)"
Revised December 20, 2001.
http://www.shoup.net/papers/
 [Inf, An] Michel Abdalla, Mihir Bellare, Phillip Rogaway,
DHAES: An Encryption Scheme Based on the DiffieHellman Problem,
Contribution to IEEE P1363a,
Updated version, March 1999.
http://grouper.ieee.org/groups/1363/P1363a/Encryption.html#ABR
 [Inf, An] Michel Abdalla, Mihir Bellare, Phillip Rogaway,
DHAES: An Encryption Scheme Based on the DiffieHellman Problem,
Theory of Cryptography Library.
http://philby.ucsd.edu/cryptolib/1999/9907.html
[[update reference to eprint.iacr.org version]]
 Parameters:
 Comments:
 It is recommended that implementations make no practical restriction
on the lengths of the key parameters. In particular, values of p
(the prime modulus) up to at least 4096 bits SHOULD be supported.
 This algorithm replaces, but is not compatible with, DLDHAES in
SCAN 1.0.17 and earlier.
 Security comments:
 DLIESISO has been proven semantically secure and nonmalleable, under
the "Hash DiffieHellman Assumption" (that is, the assumption that the
DiffieHellman Problem is hard when a hash function is used to derive
keys from the shared secret), and that the MAC and symmetric cipher
algorithms are secure. See the Abdalla/Bellare/Rogaway paper for details.
× ECIESISO(prf,dem)  Asymmetric Cipher Construction

 Designers:
 Michel Abdalla,
Mihir Bellare,
Phillip Rogaway
 Published:
 August 1998, updated March 1999
 Description:
 [[ECIEScompatible scheme from Shoup's ISO paper, restricted to
secure options.]] Public and private keys belong to the "ECDH" key family.
 References:
 [An] Victor Shoup,
"A Proposal for an ISO Standard for Public Key Encryption
(version 2.1)"
Revised December 20, 2001.
http://www.shoup.net/papers/
 [Inf, An] Michel Abdalla, Mihir Bellare, Phillip Rogaway,
DHAES: An Encryption Scheme Based on the DiffieHellman Problem,
Contribution to IEEE P1363a,
Updated version, March 1999.
http://grouper.ieee.org/groups/1363/P1363a/Encryption.html#ABR
 [Inf, An] Michel Abdalla, Mihir Bellare, Phillip Rogaway,
DHAES: An Encryption Scheme Based on the DiffieHellman Problem,
Theory of Cryptography Library.
http://philby.ucsd.edu/cryptolib/1999/9907.html
[[update reference to eprint.iacr.org version]]
 Parameters:
 Comments:
 [[what options for EC parameters should be supported?]]
 This algorithm replaces, but is not compatible with, ECDHAES in
SCAN 1.0.17 and earlier.
 Security comments:
 ECIESISO has been proven semantically secure and nonmalleable, under
the "Hash Elliptic Curve DiffieHellman Assumption" (that is, the
assumption that the Elliptic Curve DiffieHellman Problem is hard when
a hash function is used to derive keys from the shared secret), and that
the MAC and symmetric cipher algorithms are secure. See the
Abdalla/Bellare/Rogaway paper for details.
ElgamalEnc/encoding  Asymmetric Cipher

 Designer:
 Taher Elgamal
 References:
 [Def] Taher Elgamal,
"A PublicKey Cryptosystem and a Signature Scheme Based on Discrete Logarithms,"
IEEE Transactions on Information Theory, v. IT31, n. 4, 1985,
pp. 469472, or
Advances in Cryptology  CRYPTO '84, pp. 1018,
SpringerVerlag, 1985.
 [Inf] Bruce Schneier,
"Section 19.6 ElGamal,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [An] Y. Tsiounis, M. Yung,
"On the security of ElGamalbased encryption,"
1998 International Workshop on Practice and
Theory in Public Key Cryptography (PKC '98), February 56,
Yokohama, Japan.
http://www.ccs.neu.edu/home/yiannis/papers/eg.ps
 Comments:
 Taher Elgamal currently spells his name, and the name of this algorithm with a
lowercase 'g'.
 The reason for choosing separate names "ElgamalEnc" and "ElgamalSig", for
Elgamal encryption and signatures respectively, is that ElgamalEnc keys
can use the "DH" key family, while ElgamalSig requires its own key family
(because Elgamal signature keys have additional security constraints).
 It is recommended that implementations make no practical restriction
on the lengths of the key parameters p, g and x
(in particular, values of p up to at least 4096 bits SHOULD be
supported).
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:
 [Def] Ron Rivest, Adi Shamir, Leonard Adelman,
"A Method for Obtaining Digital Signatures and PublicKey Cryptosystems,"
MIT Laboratory for Computer Science and Department of Mathematics.
Communications of the ACM, February 1978, Volume 21, Number 2, pp. 120126.
 [Def] PKCS #1: RSA Encryption Standard,
An RSA Laboratories Technical Note,
Version 1.5. Revised November 1, 1993.
ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs1.asc
 [Inf] Bruce Schneier,
"Section 19.3 RSA,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Patent] R. Rivest, A. Shamir, L.M. Adelman,
"Cryptographic Communications System and Method,"
U.S. Patent 4,405,829, filed December 14 1977, issued September 20 1983.
 [An] Don Coppersmith, Matthew K. Franklin, Jacques Patarin, Michael K. Reiter,
"LowExponent RSA with Related Messages,"
Advances in Cryptology  EUROCRYPT '96 Proceedings,
Volume 1070 of Lecture Notes in Computer Science (U. Maurer, ed.), pp. 19.
SpringerVerlag, 1996.
http://www.belllabs.com/user/reiter/#Lowexp
 [An] Dan Boneh,
"Twenty Years of Attacks on the RSA Cryptosystem,"
Notices of the American Mathematical Society (AMS), Vol. 46, No. 2,
pp. 203213, 1999.
http://crypto.stanford.edu/~dabo/abstracts/RSAattacksurvey.html
 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.
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.
OAEPMGF1(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 13632000.
 Alias:
 "EMEOAEP", "EME1"
 References:
 [Def] RSA Security, Inc.,
PKCS #1: RSA Cryptography Standard, version 2.0.
http://www.rsalabs.com/pkcs/pkcs1/
 [Inf] IEEE,
IEEE Std 13632000: Standard Specifications For Public Key Cryptography.
http://grouper.ieee.org/groups/1363/index.html
 [Inf] M. Bellare, P. Rogaway,
Optimal asymmetric encryption  How to encrypt with RSA,
Extended abstract in Advances in Cryptology  EuroCrypt '94 Proceedings,
Volume 950 of Lecture Notes in Computer Science (A. De Santis, ed.), SpringerVerlag, 1995.
Full paper of revised version:
http://wwwcse.ucsd.edu/users/mihir/papers/pke.html#oaepaper
 [An] Victor Shoup,
"OAEP Reconsidered,"
Revised version, December 1 2000.
http://eprint.iacr.org/2000/060
 [An] Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval, Jacques Stern,
"RSAOAEP is Still Alive!"
December 4 2000.
http://eprint.iacr.org/2000/061
 [An] Victor Shoup,
"A Proposal for an ISO Standard for Public Key Encryption
(version 2.1)"
Revised December 20, 2001.
http://www.shoup.net/papers/
 [Test] RSA Security, Inc.,
Test vectors for OAEPbased encryption scheme: #1 and #2,
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs1v2/p1ovect1.txt
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs1v2/p1ovect2.txt
[for RSA/OAEPMGF1(SHA1)]
 [Test] Hans Dobbertin, Antoon Bosselaers, Bart Preneel,
The RIPEMD160 page,
OAEPencoding based on RIPEMD160: test vectors,
http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html#mgf1
[for OAEPMGF1(RIPEMD160)]
 Parameters:

String digest
[creation, no default]  the name of the
message digest that is to be used by the MGF1 mask generation function.

byte[] parameters
[write, default zerolength array]  a byte
array containing parameters to be used by the OAEP encoding operation.
This corresponds to the byte string P in PKCS #1 v2.0 and
IEEE Std 13632000.
The implementation may or may not copy the contents of arrays used
to set this parameter. If any such array is subsequently changed, the
output of the encoding method is undefined (it is therefore the responsibility
of the caller to make sure that a reference to this array is not
accessible to untrusted code). Setting this parameter will
not reset the current key.
 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 trapdooroneway function
into an encryption scheme that is secure under adaptive chosen ciphertext
attack (INDCCA2), is flawed (see the "OAEP Reconsidered" paper). The
"RSAOAEP is Still Alive!" paper shows that RSAOAEP can still be proven
INDCCA2secure 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:
 [An] Victor Shoup,
"A Proposal for an ISO Standard for Public Key Encryption
(version 2.1)"
Revised December 20, 2001.
http://www.shoup.net/papers/
 Parameters:
PKCS11.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", "EMEPKCS1v1_5"
 References:
 [Def] PKCS #1: RSA Encryption Standard,
An RSA Laboratories Technical Note,
Version 1.5. Revised November 1, 1993.
ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs1.asc
 [Inf] Burt Kaliski, Jessica Staddon,
PKCS #1: RSA Cryptography Specifications, Version 2.0
Internet draft, July 1998.
 [An] Daniel Bleichenbacher, Burt Kaliski, Jessica Staddon,
RSA Laboratories Security Bulletin No. 7:
Recent Results on PKCS #1: RSA Encryption Standard,
June 26, 1998.
ftp://ftp.rsa.com/pub/pdfs/bulletn7.pdf
 [An] Daniel Bleichenbacher,
"Chosen Ciphertext Attacks against Protocols Based on RSA Encryption
Standard PKCS #1,"
Advances in Cryptology  Crypto '98 Proceedings,
Volume 1462 of Lecture Notes in Computer Science (H. Krawczyk ed.), pp 112.
SpringerVerlag, 1998.
http://www.belllabs.com/user/bleichen/papers/pkcs.ps
 Comment:
 Some existing implementations of PKCS11.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 PKCS11.5
block. Applications and protocols that use PKCS11.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 OAEPMGF1
or KEM in preference to PKCS11.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.