How LinkedIn Could Have Avoided a Breach Download the podcast "How LinkedIn Could Have Avoided a Breach" Click Here to Download Now

SHA-1 is perhaps the most often encountered hash algorithm in use today. But its use in digital signatures will be restricted by NIST in the near future. NIST has already restricted use of SHA-1 for federal organizations starting back in 2010, but the weaknesses found in the SHA-1 algorithm has prompted NIST to restrict it’s use for all digital signature generation.

Digital signatures have two aspects: signature generation and signature verification. In January 2011 NIST issued Special Publication 800-131A titled "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths." Digital signature generation is addressed in Appendix B.2, Digital Signature Generation Using Asymmetric (Public) Keys and SHA-1. Here NIST states, "Some applications, such as signing a public key certificate, are very high risk and the use of SHA-1 in those applications should be avoided as much as possible. In NIST’s view, after 2013, the risk is unacceptable in all applications, and the use of SHA-1 when generating a digital signature is not allowed after that date."

Signature verification of already calculated hashes will still be allowed in what is termed a "legacy-use" period.

SSL uses X.509 certificates which are frequently seen with the Signature Algorithm attribute sha1WithRSAEncryption. As December 31, 2013 is fast approaching you may want to consider recreating these certificates with one of the newer SHA-2 algorithms such as SHA-256 or SHA-512. For example when creating certificate signing requests with OpenSSL try using "openssl req -new -sha256 etc...".

NIST has good reason to restrict the use of SHA-1 after 2013. Not only have experts found weaknesses in the SHA-1 algorithm through differential attacks, companies using SHA-1, such as LinkedIn, have already fallen prey to hackers. LinkedIn’s data breach this year could have likely been prevented if they had been using stronger hash algorithms with proper salting.

Is your company still using SHA-1 hash algorithms? Learn more about why you should move to SHA-2 or higher  in our podcast, “How LinkedIn Could Have Avoided a Data Breach” featuring security expert, Patrick Townsend.

 

 

The modern enterprise runs on a variety of computing platforms. The concept of being "an IBM shop" has gone the way of the buggy whip. With cloud computing and virtual machine technology, you may not even know what your hardware base is. This has caused  those seeking to realize the benefits of standardization to shift their focus to the software.

Take, for example, the need for securely transferring files, both within the organization and between trading partners. In the UNIX-Linux-Windows world the de facto standard for secure file transfer is undoubtedly PGP. The technology is mature and it is implemented on every significant OS variant in common use. It is extensively documented and familiar to a very large number of programmers and administrators.

But while the IBM shop may have disappeared, IBM servers have not. The enterprise is often built around mainframes and mid-range servers. And these servers now need to inter-operate with not only desktop PCs, but mobile laptops and cell phones. This makes the ability to settle on a single secure file transfer standard for the entire company more important than ever.

Fortunately PGP has spread to both the mainframe and mid-range platforms; IBM series z and i. And not just in a quirky slapdash port to UNIX emulation environments, but as fully supported native z/OS applications integrated with RACF and controlled via JCL.

With PGP it is possible to have all the advantages of a uniform secure file transfer approach without sacrificing any of the security and scalability of enterprise level platforms.

If you would like to download a free 30-evaluation of PGP for the IBM i or IBM z, let us know.  We'd be happy to show you how easy it is to encrypt with PGP and transfer to your trading partner.

How Much Data Can You Encrypt with RSA Keys?

When someone first begins to consider using encryption to protect business data, they discover that there are two general types: symmetric (AES) and asymmetric (RSA). At first glance, which one you would choose can be confusing.

One of the differences between the two is speed. Symmetric encryption is much faster than asymmetric. The exact difference is implementation dependent, but may be on the order of 100 to 1000 times faster.

It is widely known that AES encrypts a 16-byte block of data at a time. However, how much data can be encrypted at one time with an RSA key is usually only discussed in vague terms such as “use RSA to encrypt session keys.” This raises the question of how much data can be encrypted by an RSA key in a single operation.

The typical encryption scenario is to encrypt with a public key and decrypt with the private key. OpenSSL provides the RSA_public_encrypt and RSA_private_decrypt functions to implement this.

The first parameter to the RSA_public_encrypt function is flen. This is an integer that indicates the number of bytes to encrypt. Its maximum value depends on the padding mode. For OAEP padding, recommended for all new applications, it must be less than the size of the key modulus – 41 (all in bytes).

To get the size of the modulus of an RSA key call the function RSA_size.

The modulus size is the key size in bits / 8. Thus a 1024-bit RSA key using OAEP padding can encrypt up to (1024/8) – 42 = 128 – 42 = 86 bytes.

A 2048-bit key can encrypt up to (2048/8) – 42 = 256 – 42 = 214 bytes.

Additional Resources for IT Developers and Professionals

We collaborate with developers and IT professionals around the world and know that they use a wide variety of languages and platforms to accomplish their work.  Our products include documentation, source code examples, and HOWTO guides for developers in order to help projects get done quickly. Visit our Developer Resources section of our web site to learn more and discuss your upcoming project with our development team.

 

 

The advent of faster and faster computers poses a never ending challenge for encryption methodologies. An excellent example of this is the demise of the DES encryption standard in 1999.  That was when a group of programmers was able to break the security of a DES key in about 22 hours using a brute force attack which simply tried every possible value of the key. Computers have gotten a lot faster since then! This exploit lead to the adoption of AES as the new standard for symmetric encryption.

This year marks another milestone regarding the use of RSA keys. These are the public-private key pairs that are used in the creation of the SSL/TLS connections that enable ecommerce to transactions to run over the Internet (for example when you engage in electronic banking or give a credit card number to an on-line merchant).

In the past the use of RSA keys with a length of 1024-bits was quite common. However, the official policy has changed. NIST (the National Institute for Standards in Technology) now recommends that 2048-bit keys be used to encrypt data through 2030. After that time 3072-bit keys will be required.

This is documented in NIST Special Publication 800-57, Recommendation for Key Management. See “Table 4: Recommended algorithms and minimum key sizes” for particulars.