IAIK-JCE works on any Java™ version starting with JDK 1.2 up to the most recent versions.
IAIK-JCE comes with its own security provider offering a great variety of cryptographic services, algorithms and secure random number generators. The X.509 package supports X.509 public key, qualified and attributes certificates, revocation information handling via CRLs and OCSP, and searching and downloading certificates or CRLs from LDAP directories. Comprehensive ASN.1 and PKCS APIs allow easy modelling of ASN.1 structures, secure storing of sensitive keying and data material, and signing or encrypting digital documents. An extensive demo source library makes it easy to soon become familiar with Cryptography for the Java™ platform and IAIK-JCE.
Since IAIK-JCE version 5.0 we have been delivering an optional AES addon, which makes use of the AES-NI instruction set extensions of modern x86 CPUs. Using this addon the throughput of AES can be sped up tremendously. Take a look at our speed tables to see the difference.
The provider architecture has been introduced by the Java™ Cryptographic Architecture (JCA), making it possible for different cryptographic implementations to operate on common interfaces (consult the Java™ Cryptography Architecture API Specification & Reference).
The term provider is an abbreviation for Cryptographic Package Provider and denotes a package or a set of packages supplying concrete implementations of some cryptographic services of the Java™ Cryptography API (see JCA). A JCA provider may realise implementations of digital signature, message digest and key pair generation algorithms, certificate factories and keystores. If the JCA API is extended by the Java™ Cryptography Extension (JCE) API, a provider may also implement encryption, message authentication and key exchange algorithms.
The master class of the IAIK security package provider is class IAIK of package iaik.security.provider. It extends class java.security.Provider for registering the IAIK provider specific cryptographic implementations within the Java™ cryptography architecture. The IAIK provider supports both, algorithm implemetations for JCA and for the JCE extension (see below).
The IAIK provider contains the following JCA implementations (follow this link for a detailed list):
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA512/224, SHA512/256, SHA3-224, SHA3-256, SHA3-384, SHA3-512;
SHA3 Extendable Output Functions (XOFs): SHAKE128 (SHAKE128InputStream), SHAKE256 (SHAKE256InputStream) |
Groestl-224, Groestl-256, Groestl-384, Groestl-512 |
BLAKE-224, BLAKE-256, BLAKE-384, BLAKE-512 |
Keccak-224, Keccak-256, Keccak-384, Keccak-512 |
JH-224, JH-256, JH-384, JH-512 |
Skein-224, Skein-256, Skein-384, Skein-512 |
MD2, MD5 |
RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320 |
WHIRLPOOL |
GOST-3411 |
PKCS#1 version 1.5 RSA with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA512/224, SHA512/256, SHA3-224, SHA3-256, SHA3-384, SHA3-512, MD2, MD5, RIPEMD-128, RIPEMD-160, RIPEMD-256, WHIRLPOOL; raw RSA with external hashing |
PKCS#1 version 2.1 RSA PSS with SHA-1, SHA-256, SHA-384, SHA-512, SHA512/224, SHA512/256, SHA3-224, SHA3-256, SHA3-384, SHA3-512, MD2, MD5, RIPEMD-128, RIPEMD-160, WHIRLPOOL; raw RSA PSS with external hashing Support for RSASSA-PSS keys according to RFC 4055 |
ISO 9796-2 (2002) RSA with SHA-1, SHA-256, SHA-384, SHA-512, RIPEMD-128, RIPEMD-160, WHIRLPOOL; raw RSA with external hashing |
SSL/TLS RSA signature with MD5 and SHA-1 |
DSA and DSA with external hashing; DSA with SHA-1, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512 |
RSA and RSASSA-PSS (IEEE P1363 and FIPS 186-3) |
DSA, SHA1withDSA, SHA224withDSA, SHA256withDSA |
RSA, RSASSA-PSS |
DSA, SHA1withDSA, SHA224withDSA, SHA256withDSA |
DSA, SHA1withDSA, SHA224withDSA, SHA256withDSA |
DSA, SHA1withDSA, SHA224withDSA, SHA256withDSA |
RSAPkcs15 (raw), RSASSA-PSS |
ISO9796-2-RM |
MGF1 |
IAIKKeyStore |
PKCS#12 |
X.509 |
Qualified |
X.509 AC (Attribute certificate factory) |
MGF1 |
NIST SP800-90 with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, HMAC/SHA-1, HMAC/SHA-224, HMAC/SHA256, HMAC/SHA-384, HMAC/SHA-512, AES-128, AES-192 and AES-256 |
FIPS 186 with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, RIPEMD-160 |
BSI AIS 20 (v2.0) E5 with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, MD5, RIPEMD-128, RIPEMD-160, WHIRLPOOL |
ANSI X9.17 |
See here for a detailed list of the JCA implementations of the IAIK provider.
The IAIK provider supports the following JCE implementations (follow this link for a detailed list):
AES, Blowfish, Camellia, CAST-128, DES, DESede, GOST, IDEA, MARS, RC2, RC5, RC6, Rijndael, Rijndael-256, Serpent, Twofish |
ARCFOUR (compatible with RC4™), ChaCha20, ChaCha20Poly1305 |
Key Wrap (AES, AES Key Wrap with Padding, Camellia, CAST-128, DESede, HMAC-DESede, HMAC-AES, IDEA, RC2) |
PBE (PKCS#5 PBES1 with MD5, SHA-1 and DES, Triple-DES, RC2; PKCS#5 PBES2 with AES, DESede, … and HMAC/SHA-1, HMAC/SHA-2) |
AES-CBC-CMAC-128, AES-CBC-CMAC-192, AES-CBC-CMAC-256 (BSI TR-03109-1) |
RSA (PKCS#1v1.5), RSAES-OAEP (PKCS#1v2.1) |
ElGamal (PKCS#1v1.5) |
ECB, CBC, PCBC, CFB, OFB, CTR, CCM, GCM, CTS, OpenPGPCFB |
RSA (PKCS#1v1.5): 0, 1, 2 (block types); SSL |
NoPadding, PKCS5Padding, SSL3Padding, ISO78164Padding, ISO10126-2 |
RSA: PKCS1Padding, OAEP |
ElGamal: PKCS1Padding |
DH, ESDH |
HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA512/224, SHA512/256, SHA3-224, SHA3-256, SHA3-384, SHA3-512, MD5, RIPEMD-128, RIPEMD-160, WHIRLPOOL, GOST-3411 |
CMAC with AES and DESede |
CBCMac with AES, DESede, and DES |
Poly1305, PBMAC1 |
RSA (PKCS#1v1.5), RSAES-OAEP (PKCS#1v2.1) (IEEE P1363 and FIPS 186-3) |
DH, ESDH |
ElGamal |
RSA (PKCS#1v1.5), RSAES-OAEP (PKCS#1v2.1) |
DH, ESDH |
ElGamal |
AES, AES-192, AES-256, Blowfish, Camellia, Camellia-192, Camellia-256, CAST-128, DES, DESede, GOST, IDEA, MARS, RC2, RC5, RC6, Rijndael, Rijndael-256, Serpent, Twofish |
ARCFOUR (compatible with RC4™), ChaCha20 |
PBKDF2 (with HMAC/SHA-1, HMAC/SHA-2), PKCS12, PKCS12-IV, PKCS12-MAC |
HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA512/224, SHA512/256, SHA3-224, SHA3-256, SHA3-384, SHA3-512, MD5, RIPEMD-128, RIPEMD-160, WHIRLPOOL |
Key Wrap (AES, AES-192, AES-256, CAST-128, DESede, DESede-HMAC, IDEA, RC2) |
AES-CBC-CMAC-128, AES-CBC-CMAC-192, AES-CBC-CMAC-256 (BSI TR-03109-1) |
Poly1305 |
AES, AES-192, AES-256, Blowfish, Camellia, CAST-128, DES, DESede, GOST, IDEA, MARS, RC2, RC5, RC6, Rijndael, Rijndael-256, Serpent, Twofish |
ARCFOUR (compatible with RC4™), ChaCha20 |
PBE, PBES2, PKCS#5, PKCS#12 |
Key Wrap (AES, AES-192, AES-256, CAST-128, DESede, DESede-HMAC, IDEA, RC2) |
AES-CBC-CMAC-128, AES-CBC-CMAC-192, AES-CBC-CMAC-256 (BSI TR-03109-1) |
Poly1305 |
DH, ESDH |
ElGamal |
PBE |
DH, ESDH, ESDHKEK |
ElGamal |
AES, AES-192, AES-256, Blowfish, Camellia, CAST-128, DES, DESede, GOST, IDEA, MARS, RC2, RC5, RC6, Rijndael, Rijndael-256, Serpent, Twofish |
IV (initialization vector) |
ARCFOUR (compatible with RC4™) |
PBE, PBES2 |
Key Wrap (CAST-128, RC2) |
CCM, CCMCMS, GCM |
ChaCha20Poly1305 |
See here for a detailed list of the JCE implementations of the IAIK provider.
The
Abstract Syntax Notation One
(ASN.1), defined by the ISO standard ISO 8824/ITU X.208, specifies a language for describing data structures in an abstract and platform independent manner.
IAIK-JCE supports all essential basic – simple and constructed – ASN.1 types:
IAIK-JCE provides the functionality for properly handling private, context-specific and application dependent types, as well as the pre-defined standard types.
Several en/decoding utilities support mechanisms for DER, Base64, and PEM en/decoding ASN.1 structures that may be implemented as Java™ classes. For avoiding memory problems ASN.1 structures may be written or parsed to/from their encodings in stream based manner.
IAK-JCE includes a library of pre-built ASN.1 structures to be used for application protocols like PKCS or X.509
IAIK-JCE supports the following standards of the PKCS public-key cryptography family:
There is support for these additional standards via separate products:
IAIK-JCE includes a variety of random number generators including those from NIST SP800-90, ANSI X9.17, FIPS PUB 186-2 and other hash-based random generators. In addition, IAIK-JCE provides utilities making it easy for GUI developers to use Java™ AWT events for seeding the generator.
Class name | Standard name | Description |
SHA1SP80090Random | SHA1PRNG-SP80090 | A SHA-1 hash-based secure random according NIST SP800-90. |
SHA224SP80090Random | SHA224PRNG-SP80090 | A SHA-224 hash-based secure random according NIST SP800-90. |
SHA256SP80090Random | SHA256PRNG-SP80090 | A SHA-256 hash-based secure random according NIST SP800-90. |
SHA384SP80090Random | SHA384PRNG-SP80090 | A SHA-384 hash-based secure random according NIST SP800-90. |
SHA512SP80090Random | SHA512PRNG-SP80090 | A SHA-512 hash-based secure random according NIST SP800-90. |
HMacSHA1SP80090Random | HMacSHA1PRNG-SP80090 | An HMac/SHA-1 based secure random according NIST SP800-90. |
HMacSHA224SP80090Random | HMacSHA224PRNG-SP80090 | An HMac/SHA-224 MAC-based secure random according NIST SP800-90. |
HMacSHA256SP80090Random | HMacSHA256PRNG-SP80090 | An HMac/SHA-256 MAC-based secure random according NIST SP800-90. |
HMacSHA384SP80090Random | HMacSHA384PRNG-SP80090 | An HMac/SHA-384 MAC-based secure random according NIST SP800-90. |
HMacSHA512SP80090Random | HMacSHA512PRNG-SP80090 | An HMac/SHA-512 MAC-based secure random according NIST SP800-90. |
AES128SP80090Random | AES128PRNG-SP80090 | An AES-128 blockcipher-based secure random according NIST SP800-90. |
AES192SP80090Random | AES192PRNG-SP80090 | An AES-192 blockcipher-based secure random according NIST SP800-90. |
AES256SP80090Random | AES256PRNG-SP80090 | An AES-256 blockcipher-based secure random according NIST SP800-90. |
SHA1Random | SHA1PRNG | A SHA-1 hash-based secure random according to example E.5 of the AIS 20 (v2.0) document for Common Criteria from BSI. |
MD5Random | A MD5 hash-based secure random according to example E.5 of the AIS 20 (v2.0) document for Common Criteria from BSI. | |
RipeMd128Random | A RIPEMD-128 hash-based secure random according to example E.5 of the AIS 20 (v2.0) document for Common Criteria from BSI. | |
RipeMd160Random | RipeMD160PRNG | A RIPEMD-160 hash-based secure random according to example E.5 of the AIS 20 (v2.0) document for Common Criteria from BSI. |
SHA256Random | SHA256PRNG | A SHA-256 hash-based secure random according to example E.5 of the AIS 20 (v2.0) document for Common Criteria from BSI. |
SHA384Random | SHA384PRNG | A SHA-384 hash-based secure random according to example E.5 of the AIS 20 (v2.0) document for Common Criteria from BSI. |
SHA512Random | SHA512PRNG | A SHA-512 hash-based secure random according to example E.5 of the AIS 20 (v2.0) document for Common Criteria from BSI. |
SHA1FIPS186Random | SHA1PRNG-FIPS186 | A SHA-1 hash-based secure random according to the general purpose version of the FIPS 186-2 random generator. |
RipeMd160FIPS186Random | RipeMD160PRNG-FIPS186 | A RIPEMD-160 hash-based secure random according to the general purpose version of the FIPS 186-2 random generator. |
SHA256FIPS186Random | SHA256PRNG-FIPS186 | A SHA-256 hash-based secure random according to the general purpose version of the FIPS 186-2 random generator. |
SHA384FIPS186Random | SHA384PRNG-FIPS186 | A SHA-384 hash-based secure random according to the general purpose version of the FIPS 186-2 random generator. |
SHA512FIPS186Random | SHA512PRNG-FIPS186 | A SHA-512 hash-based secure random according to the general purpose version of the FIPS 186-2 random generator. |
AnsiRandom | DESedePRNG | A triple DES based secure random according to ANSI X9.17. |
IAIK-JCE class LdapURLConnection allows to easily search an ldap directory for certificates, attribute certificates or certificate revocation lists in a way as accustomed from the java.net URL framework. In its most simple case you only will have to create an
LdapURLConnection object by calling method
openConnection on an LDAP URL object, set — if required — any request properties, and finally call method
getInputStream or
getContent for reading the search result, e.g.:
System.getProperties().put("java.protocol.handler.pkgs", "iaik.x509.net"); // the ldap url URL url = new URL("ldap://..."); // open connection LdapURLConnection con = (LdapURLConnection)url.openConnection(); ... // set any request properties (if required) ... // connect to the ldap server and read the result: X509CRL crl = (X509CRL)con.getContent();
For downloading a CRL from its (http or ldap) distribution point you simple can use method
loadCrl of the
DistributionPoint class. With this method you can download any referenced CRL(s) immediately while stepping through the distribution points contained in an
CRLDistributionPoints extension of a certificate, e.g.:
X509Certificate cert = ...; ... // get CRLDistributionPoints extension CRLDistributionPoints cRLDistributionPoints = cert.getExtension(CRLDistributionPoints.oid); if (cRLDistributionPoints != null) { // get DistributionPoints Enumeration e = cRLDistributionPoints.getDistributionPoints(); while (e.hasMoreElements()) { DistributionPoint dp = (DistributionPoint)e.nextElement(); if (dp.containsUriDpName()) { // download crl X509CRL crl = dp.loadCrl(); ... } } }
IAIK-JCE also contains command line utilities (see sub-directory
cmd/ldapSearch of the IAIK-JCE distribution) for searching an LDAP directory for certificates, attribute certificates and certificate revocation lists.
See also tech tip “LDAP for the Java™ NET URL framework” Part 1 and Part 2 .
This program also may be used to benchmark other JCA/JCE providers, like the default Sun provider for MD5 and SHA-1 hashes or the SunJCE provider.
The results below have been obtained on an Intel(R) Core(TM)i5 2540M 2.60 GHz (running in turbo mode at 3.3GHz), 8.00 GB RAM running Windows 7 Enterprise (64 Bit) and Ubuntu Linux 11.10/amd64 network connected with standard services active. The tests were done on IAIK JCE 5.0 release with JDK 1.6.0, each test for 3.0 seconds.
Results for Windows7/x64 and 64-bit VM:
Security provider: IAIK, version 5.01 Java VM: Sun Microsystems Inc., version 1.7.0_01, JIT OS: Windows 7/amd64, version 6.1The ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 8192.8k 8361.8k 8328.8k 8367.4k 8368.8k md5 192768.8k 278787.2k 299987.1k 308221.9k 310547.8k sha1 131748.4k 178218.1k 181367.1k 180751.9k 174020.8k sha224 92638.3k 111189.5k 113375.8k 114167.3k 113953.4k sha256 93090.7k 108834.0k 112697.8k 113722.4k 114043.1k sha384 128688.7k 164949.4k 170873.2k 171309.9k 171457.9k sha512 130878.8k 164634.2k 169945.4k 170414.5k 171128.7k ripe md128 146981.0k 204095.7k 204572.0k 204929.2k 207050.0k ripe md160 81875.8k 105747.6k 106845.8k 106367.4k 106700.0k ripe md256 143191.8k 197190.0k 197856.2k 199598.3k 201015.5k ripe md320 82946.9k 97874.1k 99081.7k 99863.6k 99979.9k whirlpool 22848.2k 26719.6k 26641.5k 26676.3k 26426.0k aes cbc n/a 104703.3k 109686.7k 110553.5k 111307.7k aes gcm n/a 47072.2k 48876.1k 45624.4k 47391.1k aes ccm n/a 37161.4k 39320.9k 38398.4k 38792.7k des cbc 45501.5k 51692.5k 52308.7k 52770.5k 52533.8k rc2 cbc 34764.1k 37557.7k 38205.0k 38238.9k 38217.5k blowfish cbc 64908.8k 74834.3k 78109.4k 78271.8k 78840.1k rc5 cbc 66286.7k 79032.8k 81391.9k 78292.6k 82015.2k gost cbc 37226.2k 40858.4k 41593.7k 41875.8k 41778.9k cast128 cbc 58399.8k 66593.6k 68516.5k 68696.7k 69083.7k rc6 cbc n/a 90648.9k 91982.9k 92758.2k 92704.8k mars cbc n/a 78499.2k 81449.8k 80043.7k 81199.0k twofish cbc n/a 83585.2k 85332.4k 85644.6k 86694.8k arcfour 148935.0k 252969.5k 264484.7k 284319.3k 285884.7k serpent cbc n/a 50064.3k 53411.5k 53415.3k 53600.3k rijndael-256 cbc n/a 71354.6k 74097.3k 74019.1k 74816.2k camellia cbc n/a 71468.5k 73533.3k 73922.5k 74503.3k rsa 512 bit private key 0.309 ms rsa 512 bit public key (2^16 +1) 0.024 ms rsa 1024 bit private key 1.448 ms rsa 1024 bit public key (2^16 +1) 0.066 ms rsa 2048 bit private key 8.115 ms rsa 2048 bit public key (2^16 +1) 0.225 ms rsa 4096 bit private key 55.759 ms rsa 4096 bit public key (2^16 +1) 0.834 ms |
Security provider: IAIK, version 5.01 (with AES addon) Java VM: Sun Microsystems Inc., version 1.7.0_01, JIT OS: Windows 7/amd64, version 6.1The ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 8186.1k 8276.6k 8292.4k 8320.8k 8308.9k md5 194896.0k 297683.1k 307329.9k 309925.1k 309717.9k sha1 133692.3k 177186.7k 180563.7k 181079.3k 181655.0k sha224 92125.6k 110622.5k 113042.4k 114933.8k 112418.9k sha256 93814.0k 110153.5k 113298.2k 114672.6k 114908.3k sha384 130208.5k 166805.7k 160485.8k 171432.4k 169314.0k sha512 130768.5k 164233.4k 169897.2k 170384.2k 170603.6k ripe md128 147508.0k 202093.8k 203951.1k 205582.8k 203752.5k ripe md160 87422.6k 105639.0k 105817.8k 106642.2k 106972.1k ripe md256 145238.0k 192878.3k 196550.1k 197925.8k 199268.8k ripe md320 87399.8k 102687.1k 100944.2k 102346.2k 97338.1k whirlpool 20088.6k 25927.7k 26547.9k 26761.3k 26649.1k aes cbc n/a 163261.0k 326741.5k 490796.6k 570920.6k aes gcm n/a 47103.8k 48320.8k 46011.0k 47410.7k aes ccm n/a 37366.7k 39127.2k 38821.9k 39561.5k des cbc 46504.8k 52049.1k 53410.0k 53529.5k 53284.7k rc2 cbc 33437.0k 37142.4k 38048.0k 38268.8k 38261.0k blowfish cbc 65475.8k 77140.6k 79923.4k 80948.4k 81413.9k rc5 cbc 66750.8k 82410.6k 85805.7k 86510.8k 86686.6k gost cbc 39299.1k 43802.9k 44716.4k 44873.0k 45013.8k cast128 cbc 55421.2k 65639.5k 67577.5k 67988.7k 67494.8k rc6 cbc n/a 91000.4k 92971.7k 88395.5k 93790.3k mars cbc n/a 77938.2k 80620.3k 80840.9k 81413.9k twofish cbc n/a 82801.9k 85394.4k 84413.8k 85397.0k arcfour 152430.8k 255504.2k 281974.4k 286814.2k 284818.2k serpent cbc n/a 49235.5k 53060.6k 53073.1k 53077.9k rijndael-256 cbc n/a 69108.3k 73627.0k 73466.8k 73630.0k camellia cbc n/a 69944.4k 72135.6k 67346.6k 73276.3k rsa 512 bit private key 0.370 ms rsa 512 bit public key (2^16 +1) 0.024 ms rsa 1024 bit private key 1.446 ms rsa 1024 bit public key (2^16 +1) 0.066 ms rsa 2048 bit private key 8.050 ms rsa 2048 bit public key (2^16 +1) 0.223 ms rsa 4096 bit private key 55.599 ms rsa 4096 bit public key (2^16 +1) 0.826 ms |
Results for Windows7/x64 and 32-bit VM:
Security provider: IAIK, version 5.01 Java VM: Sun Microsystems Inc., version 1.7.0, JIT OS: Windows 7/x86, version 6.1The ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 7774.5k 7881.9k 7925.5k 7908.0k 7909.0k md5 171882.2k 245575.6k 264835.0k 269613.6k 271590.2k sha1 120515.3k 144979.5k 164770.3k 164323.9k 166476.3k sha224 72577.3k 84347.5k 85443.8k 84795.4k 85184.8k sha256 68138.6k 83742.6k 84524.9k 84298.2k 83919.7k sha384 31501.7k 33904.5k 33929.0k 34311.3k 34209.9k sha512 31645.3k 33714.4k 33814.7k 34377.2k 33981.4k ripe md128 125691.1k 169376.1k 171722.9k 172169.3k 171436.1k ripe md160 93459.2k 116264.1k 116800.7k 118136.8k 118818.0k ripe md256 123595.7k 160494.2k 169136.9k 168605.6k 169711.2k ripe md320 91941.3k 114195.7k 116037.5k 116498.9k 117327.0k whirlpool 18850.7k 19818.2k 19785.2k 19849.4k 19833.8k aes cbc n/a 70377.6k 72619.8k 73566.7k 73779.7k aes gcm n/a 25391.6k 25416.8k 25976.6k 26293.3k aes ccm n/a 24322.0k 25035.0k 24973.0k 25808.0k des cbc 32244.7k 36594.5k 37615.9k 37876.4k 37956.3k rc2 cbc 30393.1k 34085.6k 34889.7k 34687.1k 34990.8k blowfish cbc 48282.5k 58331.5k 59988.8k 60680.2k 60611.5k rc5 cbc 45844.3k 56464.8k 58255.0k 58278.8k 58908.3k gost cbc 32375.6k 37288.9k 38109.2k 35691.7k 38649.3k cast128 cbc 41960.0k 52945.9k 54240.5k 54363.1k 54880.9k rc6 cbc n/a 70250.6k 72971.9k 73694.3k 73659.9k mars cbc n/a 59707.3k 61145.5k 61575.7k 61709.4k twofish cbc n/a 69657.0k 72412.4k 73484.8k 73888.5k arcfour 77074.4k 122718.0k 132467.8k 134102.5k 134671.4k serpent cbc n/a 39023.5k 39972.0k 37220.7k 39605.0k rijndael-256 cbc n/a 57642.5k 59913.0k 60327.5k 60850.9k camellia cbc n/a 48140.4k 49426.2k 49791.3k 50185.8k rsa 512 bit private key 0.943 ms rsa 512 bit public key (2^16 +1) 0.077 ms rsa 1024 bit private key 5.282 ms rsa 1024 bit public key (2^16 +1) 0.259 ms rsa 2048 bit private key 34.397 ms rsa 2048 bit public key (2^16 +1) 0.957 ms rsa 4096 bit private key 246.000 ms rsa 4096 bit public key (2^16 +1) 3.685 ms |
Security provider: IAIK, version 5.01 (with AES addon) Java VM: Sun Microsystems Inc., version 1.7.0, JIT OS: Windows 7/x86, version 6.1The ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 7745.9k 7805.1k 7866.7k 7877.4k 7881.8k md5 169483.8k 258748.7k 267118.0k 268694.0k 268926.6k sha1 121917.7k 164900.0k 167138.3k 167731.2k 168533.1k sha224 71909.7k 84566.7k 85486.3k 85113.0k 85456.8k sha256 72745.7k 84280.3k 78504.0k 85535.4k 84874.6k sha384 31642.9k 33985.7k 34220.8k 34389.1k 34294.3k sha512 31898.9k 33875.8k 34239.9k 34446.3k 34316.0k ripe md128 126060.4k 169366.4k 172089.8k 172652.3k 173139.3k ripe md160 93140.6k 116492.3k 117037.7k 117702.8k 119068.3k ripe md256 123817.0k 166513.2k 170014.0k 170803.9k 164454.8k ripe md320 91572.1k 112127.3k 115389.1k 116275.5k 116908.0k whirlpool 18882.8k 19888.2k 19839.3k 19850.8k 19956.2k aes cbc n/a 76694.7k 155416.7k 349515.5k 520000.1k aes gcm n/a 25321.9k 25524.3k 25610.7k 26539.6k aes ccm n/a 24460.8k 25289.7k 25360.1k 25427.9k des cbc 32389.8k 35310.1k 37647.3k 38046.8k 38242.0k rc2 cbc 30618.7k 34714.9k 35310.4k 35132.9k 35349.9k blowfish cbc 47507.0k 58538.2k 60084.2k 60974.0k 60908.1k rc5 cbc 45850.7k 56426.6k 58797.7k 59504.5k 58149.3k gost cbc 32309.1k 37413.3k 38156.0k 38422.9k 38271.9k cast128 cbc 43636.0k 50771.7k 53521.5k 54698.1k 54579.7k rc6 cbc n/a 69451.4k 72207.0k 73344.7k 73834.1k mars cbc n/a 58796.5k 60591.9k 60795.1k 61082.2k twofish cbc n/a 68775.4k 72478.7k 73572.9k 73763.3k arcfour 91715.6k 154340.5k 157259.0k 165858.7k 170162.8k serpent cbc n/a 38782.6k 39749.6k 40038.7k 39871.7k rijndael-256 cbc n/a 58765.7k 56869.4k 62217.4k 62341.9k camellia cbc n/a 49482.5k 50792.0k 51140.4k 51135.3k rsa 512 bit private key 0.931 ms rsa 512 bit public key (2^16 +1) 0.075 ms rsa 1024 bit private key 5.218 ms rsa 1024 bit public key (2^16 +1) 0.256 ms rsa 2048 bit private key 33.831 ms rsa 2048 bit public key (2^16 +1) 0.938 ms rsa 4096 bit private key 244.846 ms rsa 4096 bit public key (2^16 +1) 3.623 ms |
Results for Ubuntu Linux 11.10/amd64 and 64-bit VM:
Security provider: IAIK, version 5.01 Java VM: Sun Microsystems Inc., version 1.6.0_23, JIT OS: Linux/amd64, version 3.0.0-14-genericThe ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 8236.0k 8322.3k 8396.9k 8386.5k 8347.5k md5 200893.0k 302100.4k 310835.1k 313921.5k 313638.9k sha1 131815.3k 174837.6k 176549.9k 178310.8k 178853.2k sha224 91425.2k 110981.9k 111590.7k 112523.6k 112902.1k sha256 92974.0k 110711.5k 111650.3k 111594.1k 112164.8k sha384 126978.0k 165760.8k 171397.4k 171090.9k 172569.9k sha512 132950.3k 165426.8k 171347.0k 171213.4k 172367.8k ripe md128 150315.3k 203312.5k 206315.3k 207510.5k 207541.5k ripe md160 82350.6k 96687.2k 97386.4k 97715.5k 97525.7k ripe md256 145574.3k 185433.1k 195366.7k 198403.0k 199240.3k ripe md320 81370.7k 95493.2k 94723.9k 96071.4k 96266.9k whirlpool 29228.9k 41794.9k 41804.8k 42024.9k 42109.6k aes cbc n/a 102938.4k 109955.2k 111000.5k 111392.0k aes gcm n/a 47065.2k 48433.2k 48786.5k 48859.9k aes ccm n/a 37085.9k 40440.3k 39611.5k 39653.5k des cbc 45203.2k 50808.8k 52400.2k 52482.0k 52228.4k rc2 cbc 34699.1k 37845.5k 38228.7k 38521.5k 38469.6k blowfish cbc 58037.8k 67607.6k 69156.4k 69793.7k 69976.0k rc5 cbc 69334.6k 84703.3k 87511.0k 88754.5k 88307.6k gost cbc 31446.2k 34583.7k 35014.5k 35003.7k 35159.2k cast128 cbc 56889.1k 66440.8k 68167.1k 68507.9k 68949.3k rc6 cbc n/a 87897.3k 90236.8k 91657.2k 91335.3k mars cbc n/a 78245.4k 81238.2k 81473.8k 82070.1k twofish cbc n/a 83661.0k 85644.4k 86681.7k 86499.3k arcfour 157530.5k 282012.5k 305346.7k 311394.3k 318327.8k serpent cbc n/a 48921.1k 53738.7k 53887.1k 54010.9k rijndael-256 cbc n/a 71919.5k 74154.2k 74159.6k 74918.1k camellia cbc n/a 70834.4k 72754.0k 73924.9k 74006.4k rsa 512 bit private key 0.327 ms rsa 512 bit public key (2^16 +1) 0.034 ms rsa 1024 bit private key 1.437 ms rsa 1024 bit public key (2^16 +1) 0.085 ms rsa 2048 bit private key 7.973 ms rsa 2048 bit public key (2^16 +1) 0.257 ms rsa 4096 bit private key 53.210 ms rsa 4096 bit public key (2^16 +1) 0.873 ms |
Security provider: IAIK, version 5.01 (with AES addon) Java VM: Sun Microsystems Inc., version 1.6.0_23, JIT OS: Linux/amd64, version 3.0.0-14-genericThe ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 8240.1k 8356.1k 8389.8k 8367.1k 8402.1k md5 200615.5k 285807.1k 307981.6k 313814.0k 313942.0k sha1 132045.8k 174409.8k 177720.2k 178468.0k 178413.5k sha224 90700.4k 111554.9k 111726.4k 112596.3k 112347.8k sha256 92736.0k 111675.9k 111847.0k 112741.0k 112905.4k sha384 130648.6k 163098.0k 168191.6k 171061.2k 172474.3k sha512 131690.2k 162739.2k 168391.5k 169603.4k 171338.4k ripe md128 148196.9k 194506.1k 204275.4k 205884.0k 208112.2k ripe md160 81362.3k 96420.2k 97392.0k 97101.8k 97954.4k ripe md256 146730.9k 196365.8k 198911.4k 200342.5k 200518.3k ripe md320 81581.5k 95425.3k 96213.7k 96698.3k 96526.3k whirlpool 29832.1k 42052.8k 41802.5k 41990.4k 41869.3k aes cbc n/a 213282.8k 424044.2k 546418.6k 593420.2k aes gcm n/a 47007.2k 48171.0k 48504.4k 49076.4k aes ccm n/a 37497.2k 39250.8k 39474.4k 39534.8k des cbc 47209.0k 51961.1k 53043.5k 53127.5k 51876.2k rc2 cbc 35272.0k 37791.1k 38388.9k 38582.9k 38491.4k blowfish cbc 58732.5k 68587.4k 69673.5k 70517.7k 70579.5k rc5 cbc 72282.8k 85963.0k 88641.5k 88909.1k 89388.3k gost cbc 31690.4k 34705.9k 35284.6k 34957.9k 35394.9k cast128 cbc 57858.7k 66357.3k 68378.0k 68814.8k 68506.9k rc6 cbc n/a 89383.5k 90965.6k 92157.9k 91873.2k mars cbc n/a 78277.5k 81047.8k 81582.4k 81510.4k twofish cbc n/a 83700.7k 85169.4k 86283.6k 86343.6k arcfour 153854.9k 247516.6k 276623.3k 283919.7k 286067.3k serpent cbc n/a 49861.1k 53550.5k 53803.0k 53661.5k rijndael-256 cbc n/a 72108.5k 74293.0k 74430.8k 74866.3k camellia cbc n/a 70028.1k 72900.9k 73359.7k 73176.5k rsa 512 bit private key 0.331 ms rsa 512 bit public key (2^16 +1) 0.034 ms rsa 1024 bit private key 1.433 ms rsa 1024 bit public key (2^16 +1) 0.085 ms rsa 2048 bit private key 7.934 ms rsa 2048 bit public key (2^16 +1) 0.256 ms rsa 4096 bit private key 52.789 ms rsa 4096 bit public key (2^16 +1) 0.870 ms |
Results for Ubuntu Linux 11.10/amd64 and 32-bit VM:
Security provider: IAIK, version 5.01 Java VM: Sun Microsystems Inc., version 1.6.0_25, JIT OS: Linux/i386, version 3.0.0-14-genericThe ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 8123.2k 8323.6k 8334.8k 8300.5k 8314.8k md5 163998.5k 280917.1k 290870.5k 292294.9k 293718.6k sha1 114625.3k 161941.3k 165003.4k 165266.7k 166488.7k sha224 79338.9k 99172.1k 99858.2k 101340.5k 101086.5k sha256 81325.2k 99121.9k 100820.9k 101279.4k 100951.8k sha384 45611.7k 53295.1k 53973.7k 54096.8k 52244.8k sha512 49214.6k 53348.5k 53898.5k 54094.8k 54160.0k ripe md128 133182.6k 183257.6k 184231.4k 185255.9k 185685.3k ripe md160 67132.4k 76492.9k 78156.6k 78592.3k 79026.4k ripe md256 128659.5k 172585.8k 175225.0k 176485.7k 175946.4k ripe md320 62078.6k 71091.0k 71843.0k 72224.7k 71862.9k whirlpool 11485.9k 22302.7k 22122.4k 22390.1k 22112.9k aes cbc n/a 86624.4k 90797.0k 91254.1k 91657.0k aes gcm n/a 31214.2k 31707.1k 31846.4k 31673.0k aes ccm n/a 28844.9k 31227.8k 31362.1k 31164.5k des cbc 40946.6k 45942.3k 47072.7k 47101.6k 47325.1k rc2 cbc 30166.2k 33607.8k 34285.3k 34455.8k 34349.0k blowfish cbc 41867.3k 48407.3k 49830.3k 50254.8k 50154.1k rc5 cbc 60944.0k 75899.5k 77879.2k 79369.8k 78700.5k gost cbc 27987.0k 31404.5k 31813.4k 32105.1k 32082.8k cast128 cbc 49533.4k 60321.7k 62051.2k 62795.7k 62852.6k rc6 cbc n/a 74263.6k 77131.6k 78049.2k 78084.6k mars cbc n/a 66706.6k 69652.6k 70404.7k 70478.5k twofish cbc n/a 74914.6k 77963.7k 78634.7k 78900.8k arcfour 94164.4k 165045.9k 181442.9k 186806.9k 185222.1k serpent cbc n/a 47466.0k 50887.5k 51566.5k 51638.8k rijndael-256 cbc n/a 61845.7k 65315.7k 65909.7k 64782.3k camellia cbc n/a 59095.5k 61602.4k 61722.8k 61919.0k rsa 512 bit private key 0.540 ms rsa 512 bit public key (2^16 +1) 0.054 ms rsa 1024 bit private key 2.541 ms rsa 1024 bit public key (2^16 +1) 0.152 ms rsa 2048 bit private key 15.842 ms rsa 2048 bit public key (2^16 +1) 0.509 ms rsa 4096 bit private key 113.629 ms rsa 4096 bit public key (2^16 +1) 1.842 ms |
Security provider: IAIK, version 5.01 (with AES addon) Java VM: Sun Microsystems Inc., version 1.6.0_23, JIT OS: Linux/amd64, version 3.0.0-14-genericThe ‘numbers’ are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 8140.4k 8322.7k 8333.1k 8327.5k 8331.2k md5 164416.9k 281184.4k 290190.5k 292677.9k 294548.8k sha1 113844.2k 161927.9k 164697.7k 165188.6k 166283.9k sha224 78332.7k 99790.5k 100921.1k 100834.6k 101520.7k sha256 79921.3k 95432.8k 99465.9k 100059.8k 100963.6k sha384 45961.4k 53365.5k 54081.3k 54155.6k 53980.9k sha512 48953.9k 53315.5k 54106.7k 54083.9k 53937.2k ripe md128 132593.1k 182542.4k 183173.3k 184803.3k 184486.5k ripe md160 66327.9k 76120.5k 77479.6k 78453.7k 78727.8k ripe md256 127782.8k 174707.8k 175121.7k 176989.5k 177430.5k ripe md320 60981.3k 71265.3k 71368.5k 71416.4k 71761.9k whirlpool 11451.8k 22391.0k 22411.3k 22330.0k 22418.7k aes cbc n/a 197636.5k 392540.5k 533565.0k 589840.3k aes gcm n/a 31917.9k 31893.3k 31809.4k 31747.9k aes ccm n/a 28073.2k 31412.8k 31635.4k 31335.4k des cbc 43596.4k 47793.5k 48235.2k 48693.4k 48810.7k rc2 cbc 31506.0k 34358.7k 34414.0k 34882.2k 34891.7k blowfish cbc 44011.2k 51104.8k 52252.5k 51456.3k 52662.4k rc5 cbc 57674.5k 66731.0k 68554.4k 68882.0k 68476.9k gost cbc 29352.2k 32181.8k 32606.2k 32797.6k 32680.6k cast128 cbc 53401.3k 61587.8k 63050.9k 63672.6k 63824.4k rc6 cbc n/a 79707.4k 81850.3k 82350.7k 82741.6k mars cbc n/a 69498.9k 69516.4k 72093.6k 72433.6k twofish cbc n/a 77930.9k 80370.9k 81131.8k 80863.2k arcfour 110587.0k 180509.5k 196470.2k 203962.7k 203833.3k serpent cbc n/a 48094.3k 51911.0k 51978.2k 52262.2k rijndael-256 cbc n/a 62717.2k 64887.3k 65800.8k 65828.1k camellia cbc n/a 59323.2k 61237.4k 61360.4k 61718.5k rsa 512 bit private key 0.535 ms rsa 512 bit public key (2^16 +1) 0.054 ms rsa 1024 bit private key 2.544 ms rsa 1024 bit public key (2^16 +1) 0.152 ms rsa 2048 bit private key 15.826 ms rsa 2048 bit public key (2^16 +1) 0.507 ms rsa 4096 bit private key 113.370 ms rsa 4096 bit public key (2^16 +1) 1.849 ms |
Class or Package | Bug / Change / New Feature | Description and Examples |
---|---|---|
iaik.asn1.structures.AlgorithmID | C | Checks all registered implementation names when instantiating a JCA/JCE engine. |
iaik.pkcs.pkcs5.PBMAC1ParameterSpec, iaik.pkcs.pkcs5.PBKDF2PBMAC1ParameterSpec, iaik.pkcs.pkcs5.PBMAC1Parameters | NF | AlgorithmParameters and AlgorithmParameterSpec implementations for the PKCS#5 password-based PBMAC1 Message Authentication Scheme. |
iaik.pkcs.pkcs12.PKCS12KeyStore | C | JKS KeyStore fall back mechanism enabled by default. Explicitly call |
iaik.pkcs.pkcs12 | NF | Support for parsing and verification of PKCS#12 objects and key stores that use the PKCS#5 v2.1 password-based PBMAC1 Message Authentication Scheme for protecting the intergrity of the PKCS#12 file as specified in draft-ietf-lamps-pkcs12-pbmac1-02. Generation of PBMAC1 protected PKCS#12 objects / key stores is currently disabled because the specification (draft-ietf-lamps-pkcs12-pbmac1-02) has not been finalized yet. |
iaik.security.cipher.AESCBCCMac128, iaik.security.cipher.AESCBCCMac192, iaik.security.cipher.AESCBCCMac256, | NF, C | Additional associated data alternatively may be supplied by calling |
iaik.security.cipher.ChaCha20Poly1305 | B | Fixed reset of aad buffer. |
iaik.security.mac.PBMAC1 | NF | Mac engine for password-based PBMAC1 Message Authentication Scheme as specified by PKCS#5 v2.1 (RFC 8018). |
iaik.security.mac | NF | SecretKeyFactories for HMAC algorithms added. |
iaik.x509.extensions.etsi.QcCClegislation | NF | Implementation of the ETSI EN 319 412-1 ValidityAssuredShortTermCerts certificate extension. |
iaik.x509.extensions.qualified.structures.etsi.QcCClegislation | NF | Implementation of the ETSI EN 319 412-5 QCStatements QCStatementInfo. |
Class or Package | Bug / Change / New Feature | Description and Examples |
---|---|---|
* | NF | Jar file signed with new JCE provider certificate. |
iaik.asn1.structures.AlgorithmID | Added IDs for key agreement schemes dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha512kdf-scheme, dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-cofactorDH-sha256kdf-scheme, dhSinglePass-cofactorDH-sha384kdf-scheme, dhSinglePass-cofactorDH-sha512kdf-scheme added. |
|
iaik.asn1.structures.AlgorithmID | C | Ensure to not encode parameters field as NULL for CMS AES key wrap ciphers, encode parameters field as NULL for CMS DES-EDE key wrap cipher. |
iaik.pkcs.pkcs10.CertificateRequest | NF | New sign() methods allowing to specify signature algorithm parameters. |
iaik.pkcs.pkcs12.P12KeyStore | NF | Automatically plugged in for JDK versions >= Java 8 to allow the usage of protection parameters to specify different than the default algorithms when adding key/certificate entries to a or/and storing a particular PKCS#12 KeyStore. |
iaik.security.dsa | NF, C | For deterministic DSA signatures the signature value is now verified immediately after creation as countermeasure against fault attacks. The check can be generally en/disabled for all (deterministic and non deterministic) DSA signatures by using the static method |
iaik.security.kdf.KDF1 | NF | Implementation of Key Derivation Function (KDF) 1 as specified by ISO/IEC 18033-2. |
iaik.security.kdf.KDF2 | NF | Implementation of Key Derivation Function (KDF) 2 as specified by ANS X9.44. |
iaik.security.kdf.KDF3 | NF | Implementation of Key Derivation Function (KDF) 3 as specified by ANS X9.44. |
iaik.security.rsa.RsaKem | NF | Implementation of the RSA-KEM Key Encapsulation Mechanism as specified by RFC 5990 and ISO/IEC 18033-2. |
iaik.utils.Base64OutputStream | NF | Support for Base64Url encoding added. |
iaik.utils.Util | NF | Added |
iaik.utils.Util | NF | Added |
iaik.x509.X509Certificate | NF | Method |
iaik.x509.X509CRL | NF | Overrides method |
iaik.x509.attr.ACRL | C | Overrides method |
iaik.x509.X509Certificate, iaik.x509.X509CRL, iaik.x509.attr.AttributeCertificate, iaik.x509.attr.ACRL, iaik.x509.ocsp.BasicOCSPResponse, iaik.x509.ocsp.OCSPRequest | NF | New sign() methods allowing to specify signature algorithm parameters. |
JSSE fails with IAIK as first provider with an exception saying that that the trust store cannot be accessed because of a KeyStore parsing error.
Problem: When connecting to a TLS/HTTPS server using JSSE with IAIK as first provider the connection fails with an exception saying that that the trust store cannot be accessed because of a KeyStore parsing error. A typical exception stacktrace may look like:
Exception in thread "main" java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) at java.base/javax.net.ssl.DefaultSSLSocketFactory.throwException(SSLSocketFactory.java:263) at java.base/javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:270) at java.base/sun.net.www.protocol.https.HttpsClient.createSocket(HttpsClient.java:413) at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:162) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:474) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:569) at java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:265) at java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:372) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191) at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1181) at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1075) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) at java.base/java.net.URL.openStream(URL.java:1117) Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) at java.base/java.security.Provider$Service.newInstance(Provider.java:1831) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at java.base/javax.net.ssl.SSLContext.getInstance(SSLContext.java:168) at java.base/javax.net.ssl.SSLContext.getDefault(SSLContext.java:99) at java.base/javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:123) at java.base/javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:335) at java.base/javax.net.ssl.HttpsURLConnection.(HttpsURLConnection.java:292) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.(HttpsURLConnectionImpl.java:95) at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:62) at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:57) at java.base/java.net.URL.openConnection(URL.java:1051) ... 2 more Caused by: java.security.KeyStoreException: problem accessing trust store at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73) at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:278) at java.base/sun.security.ssl.SSLContextImpl$DefaultManagersHolder.getTrustManagers(SSLContextImpl.java:1052) at java.base/sun.security.ssl.SSLContextImpl$DefaultManagersHolder.(SSLContextImpl.java:1022) at java.base/sun.security.ssl.SSLContextImpl$DefaultSSLContext.(SSLContextImpl.java:1197) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.security.Provider.newInstanceUtil(Provider.java:153) at java.base/java.security.Provider$Service.newInstance(Provider.java:1824) ... 13 more Caused by: iaik.pkcs.pkcs12.PKCS12ParsingException: iaik.pkcs.PKCSParsingException: ASN.1 creation error: iaik.asn1.CodingException: Length: Too large ASN.1 object: 109 at iaik.pkcs.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:362) at iaik.utils.UniveralKeyStore.engineLoad(UniveralKeyStore.java:935) at java.base/java.security.KeyStore.load(KeyStore.java:1479) at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:365) at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:313) at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:55) at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49) ... 23 more
The root exception also may be “masked” causing an exception message like: ” Unable to execute HTTP request: No X509TrustManager implementation available”.
Solution: Oracle has changed the JDK default KeyStore format from “JKS” to “PKCS12”, but still uses the JKS format for its cacerts default KeyStore. When, for instance, an application uses JSSE to connect to some TLS/HTTPS server (and does not have explicitly set some trust store) JSSE tries to read the certificates from the default cacerts KeyStore by instantiating a KeyStore with the default format (“PKCS12”). When IAIK is installed as first provider the PKCS12 KeyStore of the IAIK provider is instantiated and tries to parse the cacerts KeyStore. This, however, must fail since cacerts is a JKS KeyStore which cannot be read by the IAIK PKCS12KeyStore (that, of course, expects a KeyStore in PKCS12 format). The TLS/HTTPS connection attempt will fail with an Exception saying that the trust store cannot be accessed because of a KeyStore parsing problem.
There are several work arounds for solving this problem (and keeping IAIK as first provider):
java -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.keyStoreType=jks ...
PKCS12KeyStore.setUSEJKSFallBack(true);
Note that in the last case (using PKCS12KeyStore.setUSEJKSFallBack(true);) the IAIK PKCS12KeyStore will be advised to try the JKS format anytime it fails to parse a PKCS#12 KeyStore. This may cause some overhead. For that reason — and because you may not notice that you read a JKS KeyStore while you are expecting to read a PKCS#12 KeyStore — the JKS fallback mechanism is disabled by default and has to be explicitly enabled by calling PKCS12KeyStore.setUSEJKSFallBack(true);.
When using IAIK-JCE and trying to get an JCE engine an ExceptionInInitializerError is thrown saying „Cannot set up certs for trusted CAs“. I am using JDK 1.4.
With JDK1.4 the JCE framework (JAVAX CRYPTO) has been incorporated into the standard JDK. Because of export regulations a JCE provider only maybe used with JDK1.4 (or JCE 1.2.1) if it is signed. IAIK-JCE provides signed and unsigned versions of its jar files (iaik_jce.jar, iaik_jce_full.jar). Using the unsigned version with JDK 1.4 will cause the ExceptionInInitializerError „Cannot set up certs for trusted CAs“. Please use the signed jar file. You also may ensure that the right JCE policy files are installed in the lib/security directory.
When installing the IAIK provider (signed version) as first provider and trying to get an JCE engine a stack overflow error occurs. I am using JDK 1.4.
Due to a bug in the JDK jar file verification mechanism it may be necessary that the original SUN provider is installed as first provider. So insert the Stiftung SIC provider as second provider and explicitly request an IAIK engine when calling getInstance:
Security.insertProviderAt(new IAIK(), 2); Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding", "IAIK");
Alternatively you may use static method addAsJDK14Provider of the IAIK-JCE provider main class. This method uses a work around that allows to use IAIK as first provider for JDK1.4, too:
IAIK.addAsJDK14Provider();
JDK 1.5.0_02 and later already have fixed the jar file verification problem. For this versions the IAIK provider
can be installed as first provider in the convential way (or registered statically):
Security.insertProviderAt(new IAIK(), 1);
Using IAIK-JCE (signed version) and trying to perform a TripleDES encryption gives a InvalidKeyException. It works with JDK 1.3, but not with JDK1.4. (This exception may occur wrapped into an InternalErrorException when, for instance, trying to de/encrypt PKCS#8 or PKCS#12 files).
Due to import control restrictions of some countries, JDK1.4 per default comes with jurisdiction policy files allowing “strong” but limited cryptography; so keys that exceed the allowed strength are not allowed to be used by this policy. If you are entitled to do so, you may download and install an “unlimited strength” version of these files (http://java.sun.com/j2se/1.4/download.html)
With former versions of IAIK-JCE I have has used method getExtensionValue of class X509Certificate to get the extension value of some specific extension. When, for instance, quering for a BasicConstraints extension I got the DER encoding of the SEQUENCE representing the ASN.1 representation of a BasicContraints extension. Now I get the DER encoding of an OCTET STRING.
To be compatible with the standard JDK certificate API we had to change method getExtensionValue to return the encoding of the OCTET STRING extnValue:
Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }
The value of the extnValue OCTET_STRING represents the DER encoding of the Extension in mind itself; so you may have to add a second decoding step, e.g.:
byte[] extnValueEnc = cert.getExtensionValue(); OCTET_STRING extnValue = DerCoder.decode(extnValueEnc); ASN1Object asn1Extension = DerCoder.decode(extnValue.getValue());
However, generally it might be more appropriate to call method getExtension immediately (except when forced to produce provider independent code):
BasicConstraints bc = (BasicConstraints)cert.getExtension(BasicConstraints.oid);
When trying to parse a PKCS#7 SignedData object I get an decoding error saying “Next ASN.1 object is no INTEGER!”
In practice PKCS#7 objects like SignedData or EnvelopedData are wrapped into a ContentInfo before transmission to tell the recipient the PKCS#7 content type (s)he has to deal with. When parsing your SignedData object you first have to unwrap the ContentInfo as shown in demo.pkcs.TestContentInfo, e.g.:
// the stream from which to read the PKCS#7 object InputStream is = ...; // the stream from which to read the content in explicit mode InputStream message = ...; // create the ContentInfo object ContentInfoStream cis = new ContentInfoStream(is); System.out.println("This ContentInfo holds content of type " + cis.getContentType().getName()); SignedDataStream signed_data = null; if (message == null) { // implicitly signed; get the content signed_data = (SignedDataStream)cis.getContent(); } else { // explicitly signed; set the data stream for digesting the message; // we assume here that SHA-1 and MD5 have been used for digesting AlgorithmID[] algIDs = { AlgorithmID.sha1, AlgorithmID.md5 }; signed_data = new SignedDataStream(message, algIDs); } // get an InputStream for reading the signed content InputStream data = signed_data.getInputStream(); OutputStream os = ...; StreamCopier sc = new StreamCopier(data, os); sc.copyStream(); if (message != null) { // if explicitly signed now decode the SignedData signed_data.decode(cis.getContentInputStream()); } // now you may verify the signature(s) System.out.println("SignedData contains the following signer information:"); SignerInfo[] signer_infos = signed_data.getSignerInfos(); for (int i=0; i<signer_infos.length; i++) { try { // verify the signed data using the SignerInfo at index i X509Certificate signer_cert = signed_data.verify(i); // if the signature is OK the certificate of the signer is returned System.out.println("Signature OK from signer: "+signer_cert.getSubjectDN()); } catch (SignatureException ex) { // if the signature is not OK a SignatureException is thrown System.out.println("Signature ERROR from signer: "+ signed_data.getCertificate(signer_infos[i].getIssuerAndSerialNumber()).getSubjectDN()); ex.printStackTrace(); } }
A certificate generated with IAIK-JCE causes Netscape 4.7 to crash. The certificate contains non printable characters in its subjectDN common name.
RFC2459 recommends to use UTF8String as default encoding. Where the character set is sufficient, PrintableString maybe used. For that reason IAIK-JCE uses PrintableString as default encoding for AVA string attribute values, but switches to UTF8String if the string value does contain non printable characters.
UTF8String, however, may not be handled by older versions of certificate processing applications like Netscape 4.7. You either may switch do a more recent version of Netscape or use static method setNonPrintableDefaultEncoding of class AVA to change the default secondary encoding to be used for string values containing non printable characters, e.g.:
AVA.setNonPrintableDefaultEncoding(ASN.BMPString);
I have created a PKCS#7 signature using Microsoft CAPICOM. If the content is included in the SignedData object (implicit mode) I have no problems to verify the signature with the PKCS#7 library of IAIK-JCE. However, if the content is not included (explicit mode) I get a SignatureException saying that the message hash is incorrect: “Signature verification error: message hash!”.
In explicit mode (where the content data is not included in the signature) we have observed that it might be necessary to apply “UnicodeLittleUnmarked” encoding to the data before verifying the Capicom signature, or to avoid using this encoding format right at the sender side as suggested in a former posting to this Newsgroup:
From the signing side (Capicom), the following code was used to read the file and avoid Unicode formatting: ------------------- Dim objUtilities As New CAPICOM.Utilities Open strPathDocToBeSigned For Binary Access Read As #1 ' Removing EOF ReDim abytFile(LOF(1) - 1) Get #1, , abytFile Close #1 strFileContents = objUtilities.ByteArrayToBinaryString(abytFile) ------------------- and after this the normal signing process of strFileContents.
However, with the following sample code you should be able to verify both, explicit and implicit signatures (use the stream based classes if you have to deal with big amounts of data):
import java.io.IOException; import java.io.InputStream; import java.io.FileInputStream; import java.security.NoSuchAlgorithmException; import java.security.SignatureException; import iaik.asn1.CodingException; import iaik.asn1.ObjectID; import iaik.asn1.structures.AlgorithmID; import iaik.asn1.structures.Attribute; import iaik.asn1.structures.ChoiceOfTime; import iaik.pkcs.PKCSException; import iaik.pkcs.pkcs7.ContentInfo; import iaik.pkcs.pkcs7.SignedData; import iaik.pkcs.pkcs7.SignerInfo; import iaik.security.provider.IAIK; import iaik.utils.ASN1InputStream; import iaik.x509.X509Certificate; public class SignedDataParse { public static void main(String[] args) { InputStream is = null; try { byte[] data = null; IAIK.addAsJDK14Provider(); // read in the PKCS#7 SignedData encoding is = new FileInputStream("..."); /* uncomment the follwing line to supply the data in explicit mode; */ // data = "...".getBytes("UnicodeLittleUnmarked"); ASN1InputStream asn1In = new ASN1InputStream(is); byte[] content = getSignedData(asn1In, data); /* uncomment the follwing if the data represents an (UnicodeLittleUnmarked) encoded string */ //String s1 = new String(content, "UnicodeLittleUnmarked"); //System.out.println(s1); System.out.println("Ready"); } catch (Exception ex) { ex.printStackTrace(); } finally { if (is != null) { try { is.close(); } catch (IOException ex) { } } } } /** * Parses a PKCS#7 SignedData object and verifies the signature. * * @param is the input stream supplying the BER encoded PKCS#7 SignedData object. * @param message the content data supplied by other means (only required in explicit mode) * * @return the content data * * @exception PKCSException if an error occurs when parsing the SignedData * @exception IOException if an error occurs when reading from the stream */ static byte[] getSignedData(InputStream is, byte[] message) throws PKCSException, IOException { // create a content info from the encoding ContentInfo ci = new ContentInfo(is); System.out.println("This ContentInfo holds content of type " + ci.getContentType().getName()); SignedData signed_data = null; if (message == null) { //in implicit mode we simply can get the content: signed_data = (SignedData)ci.getContent(); } else { // explicitly signed; set the data for digesting the message; we assume SHA-1 and MD5 AlgorithmID[] algIDs = { AlgorithmID.sha1, AlgorithmID.md5 }; try { signed_data = new SignedData(message, algIDs); // now explicit decode the DER encoded signedData obtained from the contentInfo: signed_data.decode(ci.getContentInputStream()); } catch (NoSuchAlgorithmException ex) { throw new PKCSException(ex.getMessage()); } } System.out.println("SignedData contains the following signer information:"); SignerInfo[] signer_infos = signed_data.getSignerInfos(); for (int i=0; i<<<font id="ezfont"><<font id="ezfont">font id="ezfont">font id='ezfont'</font>>signer_infos.length; i++) { try { // verify the signed data using the SignerInfo at index i X509Certificate signer_cert = signed_data.verify(i); // if the signature is OK the certificate of the signer is returned System.out.println("Signature OK from signer: "+signer_cert.getSubjectDN()); Attribute signingTime = signer_infos[i].getAuthenticatedAttribute(ObjectID.signingTime); if (signingTime != null) { ChoiceOfTime cot = new ChoiceOfTime(signingTime.getValue()[0]); System.out.println("This message has been signed at " + cot.getDate()); } Attribute contentType = signer_infos[i].getAuthenticatedAttribute(ObjectID.contentType); if (contentType != null) { System.out.println("The content has PKCS#7 content type " + contentType.getValue()[0]); } } catch (SignatureException ex) { // if the signature is not OK a SignatureException is thrown System.out.println("Signature ERROR from signer: "+ signed_data.getCertificate(signer_infos[i].getIssuerAndSerialNumber()).getSubjectDN()); ex.printStackTrace(); } catch (CodingException ex) { System.out.println("Attribute decoding error: " + ex.getMessage()); } } return signed_data.getContent(); } }
When creating a PKCS#7 EnvelopedData, is it possible to use OAEP padding when RSA encrypting the secret content encryption key with the recipient´s public key?
There are several ways for using OAEP padding (for instance you may encrypt the content encryption key outside with OAEP and then use the
constructor to supply the already encrypted key), but the most simple way might be to override the RSACipherProvider to use RSA with OEAP padding and set it for the RecipientInfos for which you want to use OAEP (note that you will have to specify a proper AlgorithmID for RSAEncryptionOAEP), e.g.:
public class RSACipherProviderOAEP extends RSACipherProvider { ... /** * En/deciphers the given data using RSA with OAEP padding. * * @param mode the cipher mode, either ENCRYPT (1) or DECRYPT (2) * @param key the key to be used * @param data the data to be en/deciphered: * <ul> * <li>for RecipientInfo cek encryption: the raw content encryption key * <li>for RecipientInfo cek decryption: the encrypted content encryption key * </ul> * * @return the en/deciphered data: * <ul> * <li>for RecipientInfo cek encryption: the encrypted content encryption key * <li>for RecipientInfo cek decryption: the raw (decrypted) content encryption key * </ul> * * @exception NoSuchProviderException if any of the crypto providers of this RSACipherProvider is not suitable * for requested operation * @exception NoSuchAlgorithmException if RSA ciphering is not supported * @exception InvalidKeyException if the supplied key is invalid * @exception GeneralSecurityException if a general security problem occurs */ protected byte[] cipher(int mode, Key key, byte[] data) throws NoSuchProviderException, NoSuchAlgorithmException, InvalidKeyException, GeneralSecurityException { Cipher rsa = Cipher.getInstance("RSA/ECB/OAEP"); rsa.init(mode, key); return rsa.doFinal(data); } }
On the sender side set your RSA cipher provider for each RecipientInfo you which to use it:
// specify an AlgorithmID for RSA with OAEP padding AlgorithmID rsaEncryptionOAEP = new AlgorithmID("1.2.840.113549.1.1.6", "RSAEncryptionOAEP"); // the recipient certificate X509Certificate recipientCert = ...; // create the RecipientInfo RecipientInfo recipient = new RecipientInfo(recipientCert, rsaEncryptionOAEP); // set the RSA cipher provider for using RSA with OAEP padding recipients[0].setRSACipherProvider(new RSACipherProviderOAEP());
On the receiving side set yout RSA cipher provider before decrypting the encrypted content encryption key:
// the RSA OAEP provider to be used RSACipherProviderOAEP rsaCipherProviderOAEP = new RSACipherProviderOAEP(); ... // get the RecipientInfos RecipientInfo[] recipients = enveloped_data.getRecipientInfos(); for (int i=0; i<recipients.length; i++) { System.out.println("Recipient: "+(i+1)); System.out.print(recipients[i].getIssuerAndSerialNumber()); // set the RSA cipher provider for using RSA with OAEP padding recipients[i].setRSACipherProvider(rsaCipherProviderOAEP); } // decrypt the message envelopedData.setupCipher(recipientPrivateKey, recipientInfoIndex);
JSSE fails with IAIK as first provider with an exception saying that that the trust store cannot be accessed because of a KeyStore parsing error.
Problem: When connecting to a TLS/HTTPS server using JSSE with IAIK as first provider the connection fails with an exception saying that that the trust store cannot be accessed because of a KeyStore parsing error. A typical exception stacktrace may look like:
Exception in thread "main" java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) at java.base/javax.net.ssl.DefaultSSLSocketFactory.throwException(SSLSocketFactory.java:263) at java.base/javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:270) at java.base/sun.net.www.protocol.https.HttpsClient.createSocket(HttpsClient.java:413) at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:162) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:474) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:569) at java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:265) at java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:372) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191) at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1181) at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1075) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) at java.base/java.net.URL.openStream(URL.java:1117) Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) at java.base/java.security.Provider$Service.newInstance(Provider.java:1831) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at java.base/javax.net.ssl.SSLContext.getInstance(SSLContext.java:168) at java.base/javax.net.ssl.SSLContext.getDefault(SSLContext.java:99) at java.base/javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:123) at java.base/javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:335) at java.base/javax.net.ssl.HttpsURLConnection.(HttpsURLConnection.java:292) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.(HttpsURLConnectionImpl.java:95) at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:62) at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:57) at java.base/java.net.URL.openConnection(URL.java:1051) ... 2 more Caused by: java.security.KeyStoreException: problem accessing trust store at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73) at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:278) at java.base/sun.security.ssl.SSLContextImpl$DefaultManagersHolder.getTrustManagers(SSLContextImpl.java:1052) at java.base/sun.security.ssl.SSLContextImpl$DefaultManagersHolder.(SSLContextImpl.java:1022) at java.base/sun.security.ssl.SSLContextImpl$DefaultSSLContext.(SSLContextImpl.java:1197) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.security.Provider.newInstanceUtil(Provider.java:153) at java.base/java.security.Provider$Service.newInstance(Provider.java:1824) ... 13 more Caused by: iaik.pkcs.pkcs12.PKCS12ParsingException: iaik.pkcs.PKCSParsingException: ASN.1 creation error: iaik.asn1.CodingException: Length: Too large ASN.1 object: 109 at iaik.pkcs.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:362) at iaik.utils.UniveralKeyStore.engineLoad(UniveralKeyStore.java:935) at java.base/java.security.KeyStore.load(KeyStore.java:1479) at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:365) at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:313) at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:55) at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49) ... 23 more
The root exception also may be “masked” causing an exception message like: ” Unable to execute HTTP request: No X509TrustManager implementation available”.
Solution: Oracle has changed the JDK default KeyStore format from “JKS” to “PKCS12”, but still uses the JKS format for its cacerts default KeyStore. When, for instance, an application uses JSSE to connect to some TLS/HTTPS server (and does not have explicitly set some trust store) JSSE tries to read the certificates from the default cacerts KeyStore by instantiating a KeyStore with the default format (“PKCS12”). When IAIK is installed as first provider the PKCS12 KeyStore of the IAIK provider is instantiated and tries to parse the cacerts KeyStore. This, however, must fail since cacerts is a JKS KeyStore which cannot be read by the IAIK PKCS12KeyStore (that, of course, expects a KeyStore in PKCS12 format). The TLS/HTTPS connection attempt will fail with an Exception saying that the trust store cannot be accessed because of a KeyStore parsing problem.
There are several work arounds for solving this problem (and keeping IAIK as first provider):
java -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.keyStoreType=jks ...
PKCS12KeyStore.setUSEJKSFallBack(true);
Note that in the last case (using PKCS12KeyStore.setUSEJKSFallBack(true);) the IAIK PKCS12KeyStore will be advised to try the JKS format anytime it fails to parse a PKCS#12 KeyStore. This may cause some overhead. For that reason — and because you may not notice that you read a JKS KeyStore while you are expecting to read a PKCS#12 KeyStore — the JKS fallback mechanism is disabled by default and has to be explicitly enabled by calling PKCS12KeyStore.setUSEJKSFallBack(true);.
When using IAIK-JCE and trying to get an JCE engine an ExceptionInInitializerError is thrown saying „Cannot set up certs for trusted CAs“. I am using JDK 1.4.
With JDK1.4 the JCE framework (JAVAX CRYPTO) has been incorporated into the standard JDK. Because of export regulations a JCE provider only maybe used with JDK1.4 (or JCE 1.2.1) if it is signed. IAIK-JCE provides signed and unsigned versions of its jar files (iaik_jce.jar, iaik_jce_full.jar). Using the unsigned version with JDK 1.4 will cause the ExceptionInInitializerError „Cannot set up certs for trusted CAs“. Please use the signed jar file. You also may ensure that the right JCE policy files are installed in the lib/security directory.
When installing the IAIK provider (signed version) as first provider and trying to get an JCE engine a stack overflow error occurs. I am using JDK 1.4.
Due to a bug in the JDK jar file verification mechanism it may be necessary that the original SUN provider is installed as first provider. So insert the Stiftung SIC provider as second provider and explicitly request an IAIK engine when calling getInstance:
Security.insertProviderAt(new IAIK(), 2); Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding", "IAIK");
Alternatively you may use static method addAsJDK14Provider of the IAIK-JCE provider main class. This method uses a work around that allows to use IAIK as first provider for JDK1.4, too:
IAIK.addAsJDK14Provider();
JDK 1.5.0_02 and later already have fixed the jar file verification problem. For this versions the IAIK provider
can be installed as first provider in the convential way (or registered statically):
Security.insertProviderAt(new IAIK(), 1);
Using IAIK-JCE (signed version) and trying to perform a TripleDES encryption gives a InvalidKeyException. It works with JDK 1.3, but not with JDK1.4. (This exception may occur wrapped into an InternalErrorException when, for instance, trying to de/encrypt PKCS#8 or PKCS#12 files).
Due to import control restrictions of some countries, JDK1.4 per default comes with jurisdiction policy files allowing “strong” but limited cryptography; so keys that exceed the allowed strength are not allowed to be used by this policy. If you are entitled to do so, you may download and install an “unlimited strength” version of these files (http://java.sun.com/j2se/1.4/download.html)
With former versions of IAIK-JCE I have has used method getExtensionValue of class X509Certificate to get the extension value of some specific extension. When, for instance, quering for a BasicConstraints extension I got the DER encoding of the SEQUENCE representing the ASN.1 representation of a BasicContraints extension. Now I get the DER encoding of an OCTET STRING.
To be compatible with the standard JDK certificate API we had to change method getExtensionValue to return the encoding of the OCTET STRING extnValue:
Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }
The value of the extnValue OCTET_STRING represents the DER encoding of the Extension in mind itself; so you may have to add a second decoding step, e.g.:
byte[] extnValueEnc = cert.getExtensionValue(); OCTET_STRING extnValue = DerCoder.decode(extnValueEnc); ASN1Object asn1Extension = DerCoder.decode(extnValue.getValue());
However, generally it might be more appropriate to call method getExtension immediately (except when forced to produce provider independent code):
BasicConstraints bc = (BasicConstraints)cert.getExtension(BasicConstraints.oid);
When trying to parse a PKCS#7 SignedData object I get an decoding error saying “Next ASN.1 object is no INTEGER!”
In practice PKCS#7 objects like SignedData or EnvelopedData are wrapped into a ContentInfo before transmission to tell the recipient the PKCS#7 content type (s)he has to deal with. When parsing your SignedData object you first have to unwrap the ContentInfo as shown in demo.pkcs.TestContentInfo, e.g.:
// the stream from which to read the PKCS#7 object InputStream is = ...; // the stream from which to read the content in explicit mode InputStream message = ...; // create the ContentInfo object ContentInfoStream cis = new ContentInfoStream(is); System.out.println("This ContentInfo holds content of type " + cis.getContentType().getName()); SignedDataStream signed_data = null; if (message == null) { // implicitly signed; get the content signed_data = (SignedDataStream)cis.getContent(); } else { // explicitly signed; set the data stream for digesting the message; // we assume here that SHA-1 and MD5 have been used for digesting AlgorithmID[] algIDs = { AlgorithmID.sha1, AlgorithmID.md5 }; signed_data = new SignedDataStream(message, algIDs); } // get an InputStream for reading the signed content InputStream data = signed_data.getInputStream(); OutputStream os = ...; StreamCopier sc = new StreamCopier(data, os); sc.copyStream(); if (message != null) { // if explicitly signed now decode the SignedData signed_data.decode(cis.getContentInputStream()); } // now you may verify the signature(s) System.out.println("SignedData contains the following signer information:"); SignerInfo[] signer_infos = signed_data.getSignerInfos(); for (int i=0; i<signer_infos.length; i++) { try { // verify the signed data using the SignerInfo at index i X509Certificate signer_cert = signed_data.verify(i); // if the signature is OK the certificate of the signer is returned System.out.println("Signature OK from signer: "+signer_cert.getSubjectDN()); } catch (SignatureException ex) { // if the signature is not OK a SignatureException is thrown System.out.println("Signature ERROR from signer: "+ signed_data.getCertificate(signer_infos[i].getIssuerAndSerialNumber()).getSubjectDN()); ex.printStackTrace(); } }
A certificate generated with IAIK-JCE causes Netscape 4.7 to crash. The certificate contains non printable characters in its subjectDN common name.
RFC2459 recommends to use UTF8String as default encoding. Where the character set is sufficient, PrintableString maybe used. For that reason IAIK-JCE uses PrintableString as default encoding for AVA string attribute values, but switches to UTF8String if the string value does contain non printable characters.
UTF8String, however, may not be handled by older versions of certificate processing applications like Netscape 4.7. You either may switch do a more recent version of Netscape or use static method setNonPrintableDefaultEncoding of class AVA to change the default secondary encoding to be used for string values containing non printable characters, e.g.:
AVA.setNonPrintableDefaultEncoding(ASN.BMPString);
I have created a PKCS#7 signature using Microsoft CAPICOM. If the content is included in the SignedData object (implicit mode) I have no problems to verify the signature with the PKCS#7 library of IAIK-JCE. However, if the content is not included (explicit mode) I get a SignatureException saying that the message hash is incorrect: “Signature verification error: message hash!”.
In explicit mode (where the content data is not included in the signature) we have observed that it might be necessary to apply “UnicodeLittleUnmarked” encoding to the data before verifying the Capicom signature, or to avoid using this encoding format right at the sender side as suggested in a former posting to this Newsgroup:
From the signing side (Capicom), the following code was used to read the file and avoid Unicode formatting: ------------------- Dim objUtilities As New CAPICOM.Utilities Open strPathDocToBeSigned For Binary Access Read As #1 ' Removing EOF ReDim abytFile(LOF(1) - 1) Get #1, , abytFile Close #1 strFileContents = objUtilities.ByteArrayToBinaryString(abytFile) ------------------- and after this the normal signing process of strFileContents.
However, with the following sample code you should be able to verify both, explicit and implicit signatures (use the stream based classes if you have to deal with big amounts of data):
import java.io.IOException; import java.io.InputStream; import java.io.FileInputStream; import java.security.NoSuchAlgorithmException; import java.security.SignatureException; import iaik.asn1.CodingException; import iaik.asn1.ObjectID; import iaik.asn1.structures.AlgorithmID; import iaik.asn1.structures.Attribute; import iaik.asn1.structures.ChoiceOfTime; import iaik.pkcs.PKCSException; import iaik.pkcs.pkcs7.ContentInfo; import iaik.pkcs.pkcs7.SignedData; import iaik.pkcs.pkcs7.SignerInfo; import iaik.security.provider.IAIK; import iaik.utils.ASN1InputStream; import iaik.x509.X509Certificate; public class SignedDataParse { public static void main(String[] args) { InputStream is = null; try { byte[] data = null; IAIK.addAsJDK14Provider(); // read in the PKCS#7 SignedData encoding is = new FileInputStream("..."); /* uncomment the follwing line to supply the data in explicit mode; */ // data = "...".getBytes("UnicodeLittleUnmarked"); ASN1InputStream asn1In = new ASN1InputStream(is); byte[] content = getSignedData(asn1In, data); /* uncomment the follwing if the data represents an (UnicodeLittleUnmarked) encoded string */ //String s1 = new String(content, "UnicodeLittleUnmarked"); //System.out.println(s1); System.out.println("Ready"); } catch (Exception ex) { ex.printStackTrace(); } finally { if (is != null) { try { is.close(); } catch (IOException ex) { } } } } /** * Parses a PKCS#7 SignedData object and verifies the signature. * * @param is the input stream supplying the BER encoded PKCS#7 SignedData object. * @param message the content data supplied by other means (only required in explicit mode) * * @return the content data * * @exception PKCSException if an error occurs when parsing the SignedData * @exception IOException if an error occurs when reading from the stream */ static byte[] getSignedData(InputStream is, byte[] message) throws PKCSException, IOException { // create a content info from the encoding ContentInfo ci = new ContentInfo(is); System.out.println("This ContentInfo holds content of type " + ci.getContentType().getName()); SignedData signed_data = null; if (message == null) { //in implicit mode we simply can get the content: signed_data = (SignedData)ci.getContent(); } else { // explicitly signed; set the data for digesting the message; we assume SHA-1 and MD5 AlgorithmID[] algIDs = { AlgorithmID.sha1, AlgorithmID.md5 }; try { signed_data = new SignedData(message, algIDs); // now explicit decode the DER encoded signedData obtained from the contentInfo: signed_data.decode(ci.getContentInputStream()); } catch (NoSuchAlgorithmException ex) { throw new PKCSException(ex.getMessage()); } } System.out.println("SignedData contains the following signer information:"); SignerInfo[] signer_infos = signed_data.getSignerInfos(); for (int i=0; i<<<font id="ezfont"><<font id="ezfont">font id="ezfont">font id='ezfont'</font>>signer_infos.length; i++) { try { // verify the signed data using the SignerInfo at index i X509Certificate signer_cert = signed_data.verify(i); // if the signature is OK the certificate of the signer is returned System.out.println("Signature OK from signer: "+signer_cert.getSubjectDN()); Attribute signingTime = signer_infos[i].getAuthenticatedAttribute(ObjectID.signingTime); if (signingTime != null) { ChoiceOfTime cot = new ChoiceOfTime(signingTime.getValue()[0]); System.out.println("This message has been signed at " + cot.getDate()); } Attribute contentType = signer_infos[i].getAuthenticatedAttribute(ObjectID.contentType); if (contentType != null) { System.out.println("The content has PKCS#7 content type " + contentType.getValue()[0]); } } catch (SignatureException ex) { // if the signature is not OK a SignatureException is thrown System.out.println("Signature ERROR from signer: "+ signed_data.getCertificate(signer_infos[i].getIssuerAndSerialNumber()).getSubjectDN()); ex.printStackTrace(); } catch (CodingException ex) { System.out.println("Attribute decoding error: " + ex.getMessage()); } } return signed_data.getContent(); } }
When creating a PKCS#7 EnvelopedData, is it possible to use OAEP padding when RSA encrypting the secret content encryption key with the recipient´s public key?
There are several ways for using OAEP padding (for instance you may encrypt the content encryption key outside with OAEP and then use the
constructor to supply the already encrypted key), but the most simple way might be to override the RSACipherProvider to use RSA with OEAP padding and set it for the RecipientInfos for which you want to use OAEP (note that you will have to specify a proper AlgorithmID for RSAEncryptionOAEP), e.g.:
public class RSACipherProviderOAEP extends RSACipherProvider { ... /** * En/deciphers the given data using RSA with OAEP padding. * * @param mode the cipher mode, either ENCRYPT (1) or DECRYPT (2) * @param key the key to be used * @param data the data to be en/deciphered: * <ul> * <li>for RecipientInfo cek encryption: the raw content encryption key * <li>for RecipientInfo cek decryption: the encrypted content encryption key * </ul> * * @return the en/deciphered data: * <ul> * <li>for RecipientInfo cek encryption: the encrypted content encryption key * <li>for RecipientInfo cek decryption: the raw (decrypted) content encryption key * </ul> * * @exception NoSuchProviderException if any of the crypto providers of this RSACipherProvider is not suitable * for requested operation * @exception NoSuchAlgorithmException if RSA ciphering is not supported * @exception InvalidKeyException if the supplied key is invalid * @exception GeneralSecurityException if a general security problem occurs */ protected byte[] cipher(int mode, Key key, byte[] data) throws NoSuchProviderException, NoSuchAlgorithmException, InvalidKeyException, GeneralSecurityException { Cipher rsa = Cipher.getInstance("RSA/ECB/OAEP"); rsa.init(mode, key); return rsa.doFinal(data); } }
On the sender side set your RSA cipher provider for each RecipientInfo you which to use it:
// specify an AlgorithmID for RSA with OAEP padding AlgorithmID rsaEncryptionOAEP = new AlgorithmID("1.2.840.113549.1.1.6", "RSAEncryptionOAEP"); // the recipient certificate X509Certificate recipientCert = ...; // create the RecipientInfo RecipientInfo recipient = new RecipientInfo(recipientCert, rsaEncryptionOAEP); // set the RSA cipher provider for using RSA with OAEP padding recipients[0].setRSACipherProvider(new RSACipherProviderOAEP());
On the receiving side set yout RSA cipher provider before decrypting the encrypted content encryption key:
// the RSA OAEP provider to be used RSACipherProviderOAEP rsaCipherProviderOAEP = new RSACipherProviderOAEP(); ... // get the RecipientInfos RecipientInfo[] recipients = enveloped_data.getRecipientInfos(); for (int i=0; i<recipients.length; i++) { System.out.println("Recipient: "+(i+1)); System.out.print(recipients[i].getIssuerAndSerialNumber()); // set the RSA cipher provider for using RSA with OAEP padding recipients[i].setRSACipherProvider(rsaCipherProviderOAEP); } // decrypt the message envelopedData.setupCipher(recipientPrivateKey, recipientInfoIndex);