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.

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, DL-DHAES in
SCAN 1.0.17 and earlier.

Security comments:

DLIES-ISO has been proven semantically secure and non-malleable, under
the "Hash Diffie-Hellman Assumption" (that is, the assumption that the
Diffie-Hellman 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.

This algorithm replaces, but is not compatible with, EC-DHAES in
SCAN 1.0.17 and earlier.

Security comments:

ECIES-ISO has been proven semantically secure and non-malleable, under
the "Hash Elliptic Curve Diffie-Hellman Assumption" (that is, the
assumption that the Elliptic Curve Diffie-Hellman 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.

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

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.

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 zero-length 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 1363-2000.
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 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.

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.