Beginner’s Guide for “Crypto” to Keeping Secrets - BestCyberNews: Online News Presenter in the present world

BestCyberNews: Online News Presenter in the present world

Start knowing

test banner


Beginner’s Guide for “Crypto” to Keeping Secrets

Crypto is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers.

Serious cryptography research is typically based in advanced mathematics and number theory, providing a serious barrier to entry. The proper and accurate implementation of cryptography is extremely critical to its efficacy. A small mistake in configuration or coding will result in removing a large degree of the protection it affords and rending the crypto implementation useless against serious attacks.

Cryptographic systems can provide one or more of the following four services. It is important to distinguish between these, as some algorithms are more suited to particular tasks, but not to others.
When analyzing your requirements and risks, you need to decide which of these four functions should be used to protect your data.

Using a cryptographic system, we can establish the identity of a remote user (or system). A typical example is the SSL certificate of a web server providing proof to the user that he or she is connected to the correct server.
The identity is not of the user, but of the cryptographic key of the user. Having a less secure key lowers the trust we can place on the identity.

The concept of non-repudiation is particularly important for financial or e-commerce applications. Often, cryptographic tools are required to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions.
For example, a customer may request a transfer of money from her account to be paid to another account. Later, she claims never to have made the request and demands the money be refunded to the account. If we have non-repudiation through cryptography, we can prove – usually through digitally signing the transaction request, that the user authorized the transaction.

More commonly, the biggest concern will be to keep information private. Cryptographic systems were originally developed to function in this capacity. Whether it be passwords sent during a log on process, or storing confidential medical records in a database, encryption can assure that only users who have access to the appropriate key will get access to the data.

We can use cryptography to provide a means to ensure data is not viewed or altered during storage or transmission. Cryptographic hashes for example, can safeguard data by providing a secure checksum.

How to protect yourself Algorithm Selection

How to determine if you are vulnerable:

Proprietary encryption algorithms are not to be trusted as they typically rely on ‘security through obscurity’ and not sound mathematics. These algorithms should be avoided if possible.
Specific algorithms to avoid:

  • MD5 has recently been found less secure than previously thought. While still safe for most applications such as hashes for binaries made available publicly, secure applications should now be migrating away from this algorithm.
  • SHA-0 has been conclusively broken. It should no longer be used for any sensitive applications.
  • SHA-1 has been reduced in strength and we encourage a migration to SHA-256, which implements a larger key size.
  • DES was once the standard crypto algorithm for encryption; a normal desktop machine can now break it. AES is the current preferred symmetric algorithm.

Cryptography is a constantly changing field. As new discoveries in cryptanalysis are made, older algorithms will be found unsafe. In addition, as computing power increases the feasibility of brute force attacks will render other cryptosystems or the use of certain key lengths unsafe. Standard bodies such as NIST should be monitored for future recommendations.

How to protect yourself

Assuming you have chosen an open, standard algorithm, the following recommendations should be considered when reviewing algorithms:


  • Key sizes of 128 bits (standard for SSL) are sufficient for most applications
  • Consider 168 or 256 bits for secure systems such as large financial transactions


The difficulty of cracking a 2048 bit key compared to a 1024 bit key is far, far, far, more than the twice you might expect. Don’t use excessive key sizes unless you know you need them. Bruce Schneier in 2002 (see the references section) recommended the following key lengths for circa 2005 threats:

  • Key sizes of 1280 bits are sufficient for most personal applications
  • 1536 bits should be acceptable today for most secure applications
  • 2048 bits should be considered for highly protected applications.

  • Hash sizes of 128 bits (standard for SSL) are sufficient for most applications
  • Consider 168 or 256 bits for secure systems, as many hash functions are currently being revised (see above).

NIST and other standards bodies will provide up to date guidance on suggested key sizes.

How to protect yourself from Key Storage

  • Cryptographic keys should be protected as much as is possible with file system permissions. They should be read only and only the application or user directly accessing them should have these rights.
  • Private keys should be marked as not exportable when generating the certificate signing request.
  • Once imported into the key store (CryptoAPI, Certificates snap-in, Java Key Store, etc.), the private certificate import file obtained from the certificate provider should be safely destroyed from front-end systems. This file should be safely stored in a safe until required (such as installing or replacing a new front end server).
  • Host based intrusion systems should be deployed to monitor access of keys. At the very least, changes in keys should be monitored.
  • Applications should log any changes to keys.
  • Pass phrases used to protect keys should be stored in physically secure places; in some environments, it may be necessary to split the pass phrase or password into two components such that two people will be required to authorize access to the key. These physical, manual processes should be tightly monitored and controlled.
  • Storage of keys within source code or binaries should be avoided. This not only has consequences if developers have access to source code, but key management will be almost impossible.
  • In a typical web environment, web servers themselves will need permission to access the key. This has obvious implications that other web processes or malicious code may also have access to the key. In these cases, it is vital to minimize the functionality of the system and application requiring access to the keys.
  • For interactive applications, a sufficient safeguard is to use a pass phrase or password to encrypt the key when stored on disk. This requires the user to supply a password on startup, but means the key can safely be stored in cases where other users may have greater file system privileges.
How to protect yourself from Insecure transmission of secrets

How to determine if you are vulnerable

This can be extremely difficult without expert help. We can try to at least eliminate the most common problems:
  • The encryption algorithm or protocol needs to be adequate to the task. The above discussion on weak algorithms and weak keys should be a good starting point.
  • We must ensure that through all paths of the transmission we apply this level of encryption.
  • Extreme care needs to be taken at the point of encryption and decryption. If your encryption library needs to use temporary files, are these adequately protected?
  • Are keys stored securely? Is an unsecured file left behind after it has been encrypted?
How to protect yourself

We have the possibility to encrypt or otherwise protect data at different levels. Choosing the right place for this to occur can involve looking at both security as well as resource requirements.

Application: at this level, the actual application performs the encryption or other crypto function. This is the most desirable, but can place additional strain on resources and create unmanageable complexity. Encryption would be performed typically through an API such as the OpenSSL toolkit ( or operating system provided crypto functions.
An example would be an S/MIME encrypted email, which is transmitted as encoded text within a standard email. No changes to intermediate email hosts are necessary to transmit the message because we do not require a change to the protocol itself.

Protocol: at this layer, the protocol provides the encryption service. Most commonly, this is seen in HTTPS, using SSL encryption to protect sensitive web traffic. The application no longer needs to implement secure connectivity. However, this does not mean the application has a free ride. SSL requires careful attention when used for mutual (client-side) authentication, as there are two different session keys, one for each direction. Each should be verified before transmitting sensitive data.
Attackers and penetration testers love SSL to hide malicious requests. Content scanners are most likely unable to decode the SSL connection, letting it pass to the vulnerable web server.

Network: below the protocol layer, we can use technologies such as Virtual Private Networks (VPN) to protect data. This has many incarnations, the most popular being IPsec (Internet Protocol v6 Security), typically implemented as a protected ‘tunnel’ between two gateway routers. Neither the application nor the protocol needs to be crypto aware – all traffic is encrypted regardless.
Possible issues at this level are computational and bandwidth overheads on network devices.

How to protect yourself from Reversible Authentication Tokens

Today’s web servers typically deal with large numbers of users. Differentiating between them is often done through cookies or other session identifiers. If these session identifiers use a predictable sequence, an attacker need only generate a value in the sequence in order to present a seemingly valid session token.
This can occur at a number of places; the network level for TCP sequence numbers, or right through to the application layer with cookies used as authenticating tokens.

How to determine if you are vulnerable

Any deterministic sequence generator is likely to be vulnerable.

How to protect yourself

The only way to generate secure authentication tokens is to ensure there is no way to predict their sequence. In other words: true random numbers.
It could be argued that computers can not generate true random numbers, but using new techniques such as reading mouse movements and key strokes to improve entropy has significantly increased the randomness of random number generators. It is critical that you do not try to implement this on your own; use of existing, proven implementations is highly desirable.
Most operating systems include functions to generate random numbers that can be called from almost any programming language.

Windows & .NET: On Microsoft platforms including .NET, it is recommended to use the inbuilt CryptGenRandom function (

Unix: For all Unix based platforms, OpenSSL is an excellent option ( It features tools and API functions to generate random numbers. On some platforms, /dev/urandom is a suitable source of pseudo-random entropy.

PHP: mt_rand() uses a Mersenne Twister, but is nowhere near as good as CryptoAPI’s secure random number generation options, OpenSSL, or /dev/urandom which is available on many Unix variants. mt_rand() has been noted to produce the same number on some platforms – test prior to deployment. Do not use rand() as it is very weak.

Java: within the Java Cryptography Extension (JCE) provides secure random numbers. This should be used in preference to other random number generators.

ColdFusion: ColdFusion MX 7 leverages the JCE class of the underlying JVM as its pseudo random number generator (PRNG).

Source :

No comments:

Post a Comment