top of page



Encryption is used for data in transit and data at rest to ensure integrity, confidentiality, authentication, and nonrepudiation. Engineers should match the algorithm type and key strength to the work process to improve data availability for optimal transaction speed.

Sample Documents

Applying Cryptography in a HIPAA Regulated Organization

Applying updated encryption tools and standards to a fictitious HIPAA regulated organization

Topic Examples

A visual chart breaking down encryption components

Comments about applying cryptography and a visua example

An excerpt of Sales Force's Encryption Best Practices page

A brief discussion on modern and future threats to encryption

An overview of encryption and issues in Windows and FIPS

Key management as the "center of gravity" for secure systems

Encryption Basics


Applied Cryptography

The strength of the algorithm, complexity of computations, can slow down processes and server performance. Best Practice involves encrypting information to meet regulatory, security, compliance, privacy requirements, and most important: intellectual property that impacts success of the business. Additionally, systems may approve algorithms and may not be compatible with another system. Which means the  algorithm used in one version of software may be expired when going to the next version that excludes insecure algorithms. For example, in a Dell Sonicwall update to 10.7, the certificates that used SHA512 and MD algorithms became obsolete with TLS 1.2. See issue discussed  here.

See my example of a cryptographic plan for a fictitious Health Insurance Company.


Sales Force Encryption Best Practices Excerpt

The Salesforce developer site provides an excellent post on Platform Encryption Best Practices.

  1. Define a threat model for your organization.

    To identify the threats that are most likely to affect your organization, walk through a formal threat modeling exercise. Use your findings to create a data classification scheme, which can help you decide what data to encrypt. 

  2. Encrypt only where necessary. 

    • Not all data is sensitive. Focus on information that requires encryption to meet your regulatory, security, compliance, and privacy requirements. Unnecessarily encrypting data impacts functionality and performance.

    • Evaluate your data classification scheme early and work with stakeholders in security, compliance, and business IT departments to define requirements. Balance business-critical functionality against security and risk measures and challenge your assumptions periodically.

  3. Create a strategy early for backing up and archiving keys and data. 

    If your tenant secrets are destroyed, reimport them to access your data. You are solely responsible for making sure that your data and tenant secrets are backed up and stored in a safe place. Salesforce cannot help you with deleted, destroyed, or misplaced tenant secrets.

  4. Read the Shield Platform Encryption considerations and understand their implications on your organization. 

    • Evaluate the impact of the considerations on your business solution and implementation.

    • Test Shield Platform Encryption in a sandbox environment before deploying to a production environment. Encryption policy settings can be deployed using change sets.

    • Before enabling encryption, fix any violations that you uncover. For example, if you reference encrypted fields in a SOQL ORDER BY clause, a violation occurs. Fix the violation by removing references to the encrypted fields.

    • When requesting feature enablement, such as pilot features, give Salesforce Customer Support several days lead time. The time to complete the process varies based on the feature and how your org is configured.

  5. Analyze and test AppExchange apps before deploying them.

    • If you use an app from the AppExchange, test how it interacts with encrypted data in your organization and evaluate whether its functionality is affected.

    • If an app interacts with encrypted data that's stored outside of Salesforce, investigate how and where data processing occurs and how information is protected.

    • If you suspect Shield Platform Encryption could affect the functionality of an app, ask the provider for help with evaluation. Also discuss any custom solutions that must be compatible with Shield Platform Encryption.

    • Apps on the AppExchange that are built exclusively using Lightning Platform inherit Shield Platform Encryption capabilities and limitations.

  6. Use out-of-the-box security tools.

    Shield Platform Encryption is not a user authentication or authorization tool. To control which users can see which data, use out-of-the-box tools such as field-level security settings, page layout settings, and sharing rules, rather than Shield Platform Encryption.

  7. Grant the Manage Encryption Keys user permission to authorized users only. 

    Users with the Manage Encryption Keys permission can generate, export, import, and destroy organization-specific keys. Monitor the key management activities of these users regularly with the setup audit trail. 

  8. Synchronize your existing data with your active key material.

    Existing field and file data is not automatically encrypted when you turn on Shield Platform Encryption. To encrypt existing field data, update the records associated with the field data. This action triggers encryption for these records so that your existing data is encrypted at rest. To encrypt existing files or get help updating other encrypted data, contact Salesforce. We can encrypt existing file data in the background to ensure data alignment with the latest encryption policy and key material.

    When you contact Salesforce support to request the background encryption service, allow at least a week before you need the background encryption completed. The time to complete the process varies based on the volume of data involved. It could take several days.

  9. Handle currency and number data with care. 

    Currency and Number fields can’t be encrypted because they could have broad functional consequences across the platform, such as disruptions to roll-up summary reports, report timeframes, and calculations. You can often keep private, sensitive, or regulated data of this variety safe in other encryption-supported field types.

  10. Communicate to your users about the impact of encryption.

    Before you enable Shield Platform Encryption in a production environment, inform users about how it affects your business solution. For example, share the information described in Shield Platform Encryption considerations, where it's relevant to your business processes. 

  11. Encrypt your data using the most current key. 

    When you generate a new tenant secret, any new data is encrypted using this key. However, existing sensitive data remains encrypted using previous keys. In this situation, Salesforce strongly recommends re-encrypting these fields using the latest key. Contact Salesforce for help with re-encrypting your data.

  12. Use discretion when granting login as access to users or Salesforce Customer Support.

    If you grant login access to a user, and they have field level security access to an encrypted field, that user is able to view encrypted data in that field in plaintext.

    If you want Salesforce Customer Support to follow specific processes around asking for or using login as access, you can create special handling instructions. Salesforce Customer Support follows these instructions in situations where login as access may help them resolve your case. To set up these special handling instructions, contact your account executive."


Threats to Encryption

The book “Secrets & Lies” by Bruce Schneier presents issues in cryptography that create insecurity. Schneier states entropy as one of the most valuable components of cryptographic systems: “Entropy is a measure of disorder; or, more specifically in the context of cryptography, it is a measure of uncertainty, the more uncertain something is, the more entropy in that thing.” Therefore, if security professionals implement cryptography with low entropy this will create a false sense of security.

Cryptographic systems depend on the high amount of computing power required to crack passwords. Those passwords, mostly required with random characters and long lengths to thwart brute-force attacks using a dictionary of common passwords. With the entrance of super computers and quantum computing, provides an inescapable fate for modern encryption systems.  

Researches are speculating that quantum computers would be the biggest concern for cryptography. Due to the speed of a quantum computer arranging the 1 and 0 bits, a Quantum computer will break encryption quickly with a brute force attack. Josh Holden from Quartz Media writes:

“While no one has yet built a quantum computer capable of solving problems of nontrivial size (unless they kept it secret), over the past 20 years, researchers have started figuring out how to write programs for such computers and predict that, once built, quantum computers will quickly solve “hidden subgroup problems.” Since all public-key systems currently rely on variations of these problems, they could, in theory, be broken by a quantum computer” (Holden, 2017).

Quanta magazine also reports:
“Google recently claimed that its quantum computers will be able to perform a calculation that’s beyond the reach of any classical computer by the end of the year. In light of this, cryptographers are scrambling to find a new quantum-proof security standard” (Kim, 2017).

The article continues to mention that long RSA keys can beat quantum computers if they are a terabyte-size key. But the sizes will effect encryption and decryption mechanisms making it unfeasible for most applications. Scott Aaronson, the director of the Quantum Information Center at the University of Texas, Austin comments on enormous RSA keys by saying “extremely precarious, vulnerable to even a modest improvement in algorithms or hardware, or a determined and well-funded-enough adversary” (kim, 2017).

One of the articles in the research mentioned if NSA or GCHQ wanted to beat nation states from using Quantum technology from discovering their secrets they would need to fight “quantum with quantum”. Currently, China has deployed a quantum encrypted satellite:

“A team of physicists reports that it sent eerily intertwined quantum particles from a satellite to ground stations separated by 1200 kilometers, smashing the previous world record. The result is a stepping stone to ultrasecure communication networks and, eventually, a space-based quantum internet” (Popkin, 2017).

The science magazine article says this is one of several missions that China hopes to make space science power on par with the United States and Europe. Does this mean US and UK already have these satellites in place?


(Popkin, 2017)

Officially, the NSA announced back in August 11, 2015: “It is now clear that current Internet security measures and the cryptography behind them will not withstand the new computational capabilities that quantum computers will bring” (Wolchover, 2015).  An article on proposes lattice-based cryptography, code0 based cryptography, and multivariate cryptography  as viable schemes to be “quantum secure”.


(Wolchover, 2015)

Holden, J. (2017, May 20).  Quantum computing could make the encryption behind every internet transaction obsolete—someday. Retrieved from

Popkin, G. (2017, June 2017). China’s quantum satellite achieves ‘spooky action’ at record distance. Retrieved from

Schneier, B. (2000). Secrets & Lies. Digital Security in a Networked World. Danvers, MA: Wiley Publishing, Inc.

Wolchover, N. (2015, August 19).  The Tricky Encryption That Could Stump Quantum Computers. Retrieved from

Understanding Windows Encryption, FIPS, & Other Controls

“If a hacker were to compromise a significant encryption platform,
we could see something much worse than the WannaCry ransomware attack”
- Kevin Mitnick

Windows Vulnerabilities
Due to the overlap of government institutions and large organizations like Microsoft working together, NSA proof encryption mechanisms strike a balance between public and enterprise use.  This is due to the forever debate between law enforcement and privacy advocates regarding security and privacy. There are recent cyber attacks attributed to the deprecation of cryptography. Take the example of the DROWN attack. In 2016, the following comments regarding the factors of such vulnerabilities:

“For the third time in a year, a major Internet security vulnerability has resulted from the way cryptography was weakened by U.S. government policies that restricted exporting strong cryptography until the late 1990s. Although these restrictions, evidently designed to make it easier for NSA to decrypt the communication of people abroad, were relaxed nearly 20 years ago, the weakened cryptography remains in the protocol specifications and continues to be supported by many servers today, adding complexity—and the potential for catastrophic failure—to some of the Internet’s most important security features…The U.S. government deliberately weakened three kinds of cryptographic primitives: RSA encryption, Diffie-Hellman key exchange, and symmetric ciphers. FREAK exploited export-grade RSA, and Logjam exploited export-grade Diffie-Hellman. Now, DROWN exploits export-grade symmetric ciphers, demonstrating that all three kinds of deliberately weakened crypto have come to put the security of the Internet at risk decades later” (Madden, 2016).

This year, we seen the Shadow Brokers release a series of vulnerabilities affecting Windows systems. Recently, they have provided a new NSA Trojan called UNITEDDRAKE. According to Bruce Schnier’s blog, the Trojan is:

“…able to compromise Windows PCs running on XP, Windows Server 2003 and 2008, Vista, Windows 7 SP 1 and below, as well as Windows 8 and Windows Server 2012, the attack tool acts as a service to capture information…UNITEDRAKE, described as a "fully extensible remote collection system designed for Windows targets," also gives operators the opportunity to take complete control of a device” (Schneier, 2017).

Despite this vulnerability not affecting encryption mechanisms directly, this NSA backdoor provides a work around that eliminates the protections that encryption provides.

FIPS Issues
There are few articles regarding the division between Windows (FIPS Compliant settings) and the IT community. Below I have summarized the issues for internet, client/server connections, remote desktop connections, and bitlocker:

“The setting in Windows complies with the US government FIPS 140 standard. When it’s enabled, it forces Windows to only use FIPS-validated encryption schemes and advises applications to do so, as well. 'FIPS mode” doesn’t make Windows more secure. It just blocks access to newer cryptography schemes that haven’t been FIPS-validated. That means it won’t be able to use new encryption schemes, or faster ways of using the same encryption schemes. In other words, it makes your computer slower, less functional, and arguably less secure' (Hoffman, 2016).”

Issue 1: Internet
“Microsoft’s .NET framework will also block access to algorithms that aren’t FIPS-validated. he .NET framework offers several different algorithms for most cryptography algorithms, and not all of them have even been submitted for validation. As an example, Microsoft notes that there are three different versions of the SHA256 hashing algorithm in the .NET framework. The fastest one hasn’t been submitted for validation, but should be just as secure. So enabling FIPS mode will either break .NET applications that use the more efficient algorithm or force them to use the less efficient algorithm and be slower” (Hoffman, 2016).

Issue 2: Client & Server Connections
“Client devices that have this policy setting enabled cannot communicate by means of digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms cannot use servers that require them for network communications”
(Lich, 2017).

Issue 3: Remote Desktop Connections
“The Remote Desktop Connection tool uses the RDP protocol to communicate with servers that run Terminal Services and client computers that are configured for remote control; RDP connections fail if both devices are not configured to use the same encryption algorithms” (Lich, 2017).

Issue 4: Bitlocker (Disk Drive Encryption)
“Setting needs to be enabled before any encryption key is generated. Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 and later when this policy is enabled are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; BitLocker will prevent the creation or use of recovery passwords on these systems, so recovery keys should be used instead. Additionally, if a data drive is password-protected, it can be accessed by a FIPS-compliant computer after the password is supplied, but the drive will be read-only” (Lich, 2017).

What would be some of the supporting controls for a secure cryptographic network?

  • Intrusion Detection System and/or Intrusion Prevention Systems (IDS/IPS)

  • Key manager software and secure key dissemination process

  • Policy to change default passwords

  • BitLocker hard disk encryption to prevent data access after device is lost or stolen

  • Anti-keylogger software (mostly found in updated antivirus).  Anti-key logger will have to be tested that it doesn’t interfere with keyboard drivers, related hardware, or other crypto systems.

  • Protect against shoulder surfing and physical theft "computer screen or cable locks to deter theft can typically be purchased for $20 to $40"(Office of civil rights, 2018).

  • USB Device Policy and/or management to prevent key loggers:  "Port and device locks that physically restrict access to USB ports or devices such as CD/DVD drives are also available at low costs (technical controls including Microsoft Windows Group Policy configuration and third party software can also be effective at restricting access to USB ports and removable media devices). Unrestricted access to USB ports and removable media devices can facilitate unauthorized copying of data to removable media as well as permit access to removable media which could be infected with malicious software" (Office of civil rights, 2018).

  • Asset labels and inventory software to deter hardware switching

The emphasis on physical controls to support cryptographic systems would be essential. In a report released by the NSA in 2012, Russian spies developed electromagnetically bugs that could be implanted on typewriters and used to transmit information as it was typed. This was in the 1980’s on a simple device compromised by sophisticated tech, what would this mean for computers? Who’s checking the keyboards? Are assets labeled and identified in inventory correctly? Regular audits, and sufficient staff to carry out those audits, will ensure timely detection of intrusions by a variety of methods.


Barrett, B. (2017, June 30). The Encryption Debate Should End Right Now. Retrieved from

Collins, K. (2017, March 16). Today we’re worried about smart TVs, but in the 1980s Russian spies were hacking typewriters. Retrieved from

Hoffman, C. (2016, March 27). Why You Shouldn’t Enable “FIPS-compliant” Encryption on Windows. Retrieved from

Khandelwal, S. (2017, September 7). Shadow Brokers Leaks Another Windows Hacking Tool Stolen from NSA’s Arsenal. Retrieved from

Lich, B. (2017, August 29). System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing. Retrieved from

Madden, S. (2016, July 1). The DROWN Attack. Retrieved from

Office of Civil Rights. (2018, May). Workstation Security: Don't forget about physical security. Retrieved from

Schneier, B. (2017, September 8). ShadowBrokers Releases NSA UNITEDRAKE Manual [Web log post]. Retrieved from


Why is Key Management Important in Cryptography?

Key management is important in cryptography because it is one of the three major constraints of a cryptographic system. The other two constraints being algorithm strength (based on block cipher vs. stream, home grown vs. peer-reviewed) and cryptologic protocols used to defend against various of attacks (e.g. replay, MITM, spoofing, and dictionary) (Sherwood et al., 2005).

If the key management system is weak, the attacker can obtain the keys and crack the most complex encryption system. The lecture provided an example on how scripts were made to locate keys in a Windows system. The script located the key in the Root file structure in a shadow file, then copied them on their own computer. Then, used additional tools to crack the encrypted files (University of San Diego, n.d.)


(Townsend Security, 2016), a key management company, lists management of keys the most common mistake. They list 6 common mistakes:
Mistake #1: Assuming your developers are security experts
Mistake #2: Believing that regulatory compliance means you’re secure
Mistake #3: Relying on cloud providers to secure your data
Mistake #4: Relying on low-level encryption
Mistake #5: Using the wrong cipher modes and algorithms
Mistake #6: Getting key management wrong

  • “In the database, on the file system, in an application config file – BAD”

  • “To encrypt your encryption key itself with another encryption key, typically called a Key Encryption Key (KEK)”

  • “Even with three layers of encryption protecting your data, there is still the challenge of transferring the key to your app securely. Ideally this involves authentication between your app and the key management server as well as delivery over an encrypted connection”

  • Using key rotation (e.g. Changing keys)
    (Guez, 2016)

Case 1 Example: OneLogin
One great example showing the importance of key storage in when a hacker stole Amazon Web Server (AWS) keys for OneLogin, a single sign-on application company that host many Companies, from a third-party vendor. The article states:
The password management firm said the stolen keys gave the intruder access through the AWS API, something industry experts say could have been averted if OneLogin maintained control of its keys. There could possibly be a design flaw, some say. “This risk could have been averted,” said Simon Hunt, EVP and chief technology officer at WinMagic. "Maintaining exclusive enterprise control of a business's keys isn't a nice-to-do. Emerging hypervisor vulnerabilities create a real security gap, and cloud-based key management solutions can leave keys open to theft or transfer of authority.”...“The threat actor was able to access database tables that contain information about users, apps and various types of keys,”…"We will have to see if they were able to offline the data," Bambenek said, noting this is not an easy task to do in the AWS environment.”

Case 2 Example: Cloudflare
The second case involves Cloudflare, a company that helps companies spread their websites and online services across the internet. They host companies like Uber, OK Cupid, and Fitbit.
“Cloudflare's systems slipped random chunks of server memory into some webpages, under certain circumstances. That means if you visited a website powered by Cloudflare, there's a small chance you may have ended up getting chunks of someone else's web traffic bunged at the bottom of your browser page… This leak was triggered when webpages had a particular combination of unbalanced HTML tags, which confused Cloudflare's proxy servers and caused them to spit out data belonging to other people – even if that data was protected by HTTPS. The webpages would also need to use a particular set of Cloudflare services as a catalyst for the spillage“ (Thompson, 2017).

The key management strategy to avoid these two major breaches is not to rely on cloud services to protect your secrets. The catch 22 is the business benefits that cloud services provide equate to huge cost savings. Therefore, it may be more effective to change keys associated with cloud accounts more often. The more moving parts of the system provide more exposure for the crypto keys. This is proved in a study where applications revealing plaintext of crypto keys are one of the most common errors:


(Lazar et al, 2014)

Townsend Security does a great review of Key management techniques that can be found here:

NIST’s statement paints an accurate picture. Like a safe’s combination, your encryption keys are only as good as the security you use to protect them. There is an entire physical and digital cryptosystem that must be must be accounted for as well as each key’s full lifecycle. Therefore, a robust encryption key management system and policies includes: 

-Key lifecycle: key generation, pre-activation, activation, expiration, post-activation, escrow, and destruction
-Physical access to the key server(s)
-Logical access to the key server(s)
-User/Role access to the encryption keys
(Townsend Security, 2016)

Guez, Y. (2016, October 20). 6 encryption mistakes that lead to data breaches. Retrieved as

Lazar, D., Chen, H., Wang, X., Zeldovich, N. (2014). Why does cryptographic software fail? A case study and open problems. Retrieved from
Olenick, D. (2017, June 2). OneLogin hacker swiped AWS keys, can decrypt stolen data. Retrieved from
Sherwood, J., Clark, A., Lynas, D. (2005). Enterprise Security Architecture, A Business-Driven Approach. Boca Raton, Florida: CRC Press.

Thompson, I. (2017, February 24). Cloudbleed: Big web brands 'leaked crypto keys, personal secrets' thanks to Cloudflare bug. Retrieved from

Townsend Security. (2016). The Definitive Guide to Encryption Key Management Fundamentals. Retrieved from
University of San Diego. (n.d.). Module 5 Presentation, Physical Security Architecture [Video File]. Retrieved from

bottom of page