Generating unique random 25 Char using salesforce apex

Question

I have a requirement of generating a unique 25 char alpha numeric #which has to be unique across different pods. I am using the following function.

public with sharing class GenerateUniqueKey {
    private static final Integer KEY_LENGTH = 25;
    public static String generateKey(){
        Blob aes = Crypto.generateAesKey(128);
        String randomValue = EncodingUtil.convertToHex(aes).left(KEY_LENGTH);
        return randomValue;
   }
}

So far, in the debug console, running it in a loop of 4071 generated unique output since the set has 4071 elements.

try{
   Set<String> generateKey = new Set<String>();
   for(integer i = 0; i < 4071 ; i++){
       String key = GenerateUniqueKey.generateKey(); 
       generateKey.add(key);
   }
   for(String s : generateKey){
      System.debug(s);
   }
   System.debug('>>>>> length : ' + generateKey.size());
}catch(Exception e){
    System.debug('>>>>> Exception : ' + e);
}

My question is does the above class guarantee unique 25 chars across pods in salesforce?

Why 4071? in loop, else maximum debug log reached.

Answer 1

No, it does not guarantee unique character strings, even within the same pod. With a fixed-length ciphertext, there is always the possibility of a collision. How likely is that? probably very, very small.

It's likely more than good enough for your use case, just not guaranteed to be unique. Truncating the AES key to 25 characters makes it more likely that you'll see a collision. Exactly how likely, I can't say (I did end up taking a few semesters of courses related to probability/statistics, but it's definitely not my forte).

The more important bit here is that without additional information, you can't possibly know if the same 25 characters of an AES-128 key has already been given out on another pod (or another org, if you're dealing with multiple salesforce orgs within your company).

A solution to this is to generate another key on a per-org basis (storing it in a hierarchy custom setting, perhaps), and use that as a prefix to the key you're generating on a per-record basis. Using your organaizationId may be an option to use as your per-org key. That way, it doesn't matter if you happen upon the cosmically unlikely event of generating the same AES-128 key in different orgs, the per-org prefix will be different, hence your GUID will be different.

Answer 2

This number generator is subject to the Birthday Problem, of course, but the odds of generating a previously used number will be approximately 1/2¹⁰⁰, or approximately 0.788e-30 (about 0.00000000000000000000000000000000788% or so). Consider just encrypting (or even a digest using SHA-256) the Org ID, and using 25 characters from that result instead; you'll get a predictable value per org (in the sense that it is idempotent) with the same very small chance of collision.