Quite a many secure electronic transactions take place at Oliver Klozoff's company and, in order to make sure the remain secure, his company undertook an Encryption Initiative. The idea was that, because encryption is such a vital part of security, all encryption should be done in one place, with once web service, instead of within each application. All applications -- new and existing -- would need to be immediately changed to utilize the new web service, and a crack team of only the best developers would be formed to lead up the Encryption Initiative.
The web service required to support the Encryption Initiative needed to be pretty robust. Because each application could (and often did) have its own encryption algorithms, the service would need to account for that. In addition, applications could (and often did) use several different keys that plugged into their application. Thankfully, the Encryption Initiative team had already thought of all that.
Once everything went into production, some same strange things started happening: quite a bit of data in various applications couldn't be decrypted. The Encryption Initiative team blamed it on the applications, saying that their code was elegant and simple, and couldn't possibly fail. A few days and several thousand un-decryptable transactions later, Oliver was brought in to help. At first glance, the application code doesn't seem that bad...
encWebSrvc = new EncryptionWebService(SERVICE_URL); encWebSrvc.setEncryptionType("CFB64"); encWebSrvc.setPrivateKeyId("42B9657F-0E9A-44EC-BCC2-F1E38770B0C2"); return encWebSrvc.Encrypt(transactionLog);
... until one considers that each line requires a separate request and, as the web service is used by several applications, it takes a lot of luck that one individual thread will be lucky enough to have three consecutive requests to set the encryption type, set the key, and encrypt that data. Whoops.