Core Java

Getting A List of Available Cryptographic Algorithms

How do you learn what cryptographic algorithms are available to you? The Java spec names several required ciphers, digests, etc., but a provider often offers more than that.

Fortunately this is easy to learn what’s available on our system.

 
 
 
 
 

public class ListAlgorithms {
    public static void main(String[] args) {
        // Security.addProvider(new
        // org.bouncycastle.jce.provider.BouncyCastleProvider());

        // get a list of services and their respective providers.
        final Map<String, List<Provider>> services = new TreeMap<>();

        for (Provider provider : Security.getProviders()) {
            for (Provider.Service service : provider.getServices()) {
                if (services.containsKey(service.getType())) {
                    final List<Provider> providers = services.get(service
                            .getType());
                    if (!providers.contains(provider)) {
                        providers.add(provider);
                    }
                } else {
                    final List<Provider> providers = new ArrayList<>();
                    providers.add(provider);
                    services.put(service.getType(), providers);
                }
            }
        }

        // now get a list of algorithms and their respective providers
        for (String type : services.keySet()) {
            final Map<String, List<Provider>> algs = new TreeMap<>();
            for (Provider provider : Security.getProviders()) {
                for (Provider.Service service : provider.getServices()) {
                    if (service.getType().equals(type)) {
                        final String algorithm = service.getAlgorithm();
                        if (algs.containsKey(algorithm)) {
                            final List<Provider> providers = algs
                                    .get(algorithm);
                            if (!providers.contains(provider)) {
                                providers.add(provider);
                            }
                        } else {
                            final List<Provider> providers = new ArrayList<>();
                            providers.add(provider);
                            algs.put(algorithm, providers);
                        }
                    }
                }
            }

            // write the results to standard out.
            System.out.printf("%20s : %s\n", "", type);
            for (String algorithm : algs.keySet()) {
                System.out.printf("%-20s : %s\n", algorithm,
                        Arrays.toString(algs.get(algorithm).toArray()));
            }
            System.out.println();
        }
    }
}

The system administrator can override the standard crypto libraries. In practice it’s safest to always load your own crypto library and either register it manually, as above, or better yet pass it as an optional parameter when creating new objects.

Algorithms

There are a few dozen standard algorithms. The ones we’re most likely to be interested in are:

Symmetric Cipher

  • KeyGenerator – creates symmetric key
  • SecretKeyFactor – converts between symmetric keys and raw bytes
  • Cipher – encryption cipher
  • AlgorithmParameters – algorithm parameters
  • AlgorithmParameterGernerator – algorithm parameters

Asymmetric Cipher

  • KeyPairGenerator – creates public/private keys
  • KeyFactor – converts between keypairs and raw bytes
  • Cipher – encryption cipher
  • Signature – digital signatures
  • AlgorithmParameters – algorithm parameters
  • AlgorithmParameterGernerator – algorithm parameters

Digests

  • MessageDigest – digest (MD5, SHA1, etc.)
  • Mac – HMAC. Like a message digest but requires an encryption key as well so it can’t be forged by attacker

Certificates and KeyStores

  • KeyStore – JKS, PKCS, etc.
  • CertStore – like keystore but only stores certs.
  • CertificateFactory – converts between digital certificates and raw bytes.

It is critical to remember that most algorithms are provided for backward compatibility and should not be used for in greenfield development. As I write this the generally accepted advice is:

  • Use a variant of AES. Only use AES-ECB if you know with absolute certainty that you will never encrypt more than one blocksize (16 bytes) of data.
  • Always use a good random IV even if you’re using AES-CBC. Do not use the same IV or an easily predicted one.
  • Do not use less than 2048 bits in an asymmetric key.
  • Use SHA-256 or better. MD-5 is considered broken, SHA-1 will be considered broken in the near future.
  • Use PBKDF2WithHmacSHA1 to create AES key from passwords/passphrases. (See also Creating Password-Based Encryption Keys.)

Some people might want to use one of the other AES-candidate ciphers (e.g., twofish). These ciphers are probably safe but you might run into problems if you’re sharing files with other parties since they’re not in the required cipher suite.

Beware US Export Restrictions

Finally it’s important to remember that the standard Java distribution is crippled due to US export restrictions. You can get full functionality by installing a standard US-only file on your system but it’s hard if not impossible for developers to verify this has been done. In practice many if not most people use a third-party cryptographic library like BouncyCastle. Many inexperienced developers forget about this and unintentionally use crippled functionality.

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button