Encryption

One of the components of both SSL and SSH that I kept meeting is the encryption of the data.

Quite apart from SSL and SSH, encryption of data is becoming increasingly important in many areas of both data storage and data transmission.

So this webpage is a look at encryption.

Two basic kinds of encryption

So far I have come across two basic kinds of encryption -

encryption based on character substitution using some kind of look-up table
encryption based on mathematical manipulation of the data using a key

Encryption based on character substitution using a look-up table is as old as the hills, and doesn`t even need a computer - as long as the sender and the receiver have the same look-up table, they can exchange messages. However if you add an evesdropper with a bit of processing power, the security is low.

Key based encryption is a whole different ball game - computer processing power is required to perform the mathematical manipulation of both the encryption and the un-encryption of the data. A lot of processing power is required for an evesdropper to extract the data - there is no such thing as an encryption method that cannot be cracked - all you can do is to design an encryption method that requires so much processing power to crack it, it is impractical for the average evesdropper to assemble enough processing power.

Unless they happen to work for an organisation like a government or a university, with a handy number crunching cluster ........

Key based encryption

First off, a key is just a number - usually a large number. Back in the days of Windows NT and Windows 2000, 40 bit numbers were used. As commonly available processing power has increased, 128 bit numbers are now regarded as the minimum that should be used, however they are crackable. 256 bit numbers are quite a bit harder to crack, and 1024 bit numbers are very much harder to crack, but under threat of being cracked all the same.

Secondly, an algorithm is the technical term for the mathematical manipulation that the raw data undergoes in order to encrypt it.

As I described in the page about SSL, there are two main kinds of key based encryption systems -

symmetric key encryption - in which the same key is known to both the sender of the data, and to the receiver, and the same key is used to both encrypt the data, and to un-encrypt the data again at the other end
public / private key encryption - in which a server has a private key, and it sends out a public key to anyone who wants it - one of the keys is used to encrypt the data, the other key is used to un-encrypt the data again - the encrypted data can only be un-encrypted by the other key, it cannot be un-encrypted by the same key that was used for the encryption

Symmetric key encryption

Symmetric key encryption can be subdivided into two types -

block ciphers - in these the incoming raw data is divided into fixed length blocks of bytes, and the algorithm is designed around the manipulation of the various bits or bytes within that block
stream ciphers - in these the incoming data is processed as a continuous stream - stream ciphers tend to be less secure than block ciphers, but are easier to implement, they tend to run faster than block ciphers, with a lower hardware overhead

Some of the more common block cipher algorithms include -

DES - 56 bit key - 8 byte blocks - now regarded as insecure
Triple DES - 56 bit x 3 times, 112 bit x 2 times, or 168 bit x 1 time - still with 8 byte blocks - an update attempt to make DES more secure, but not as secure as some other algorithms with the same key lengths
Blowfish - variable key length up to 448 bits - 8 byte block size
Twofish - up to 256 bit keys - 16 byte block size - an improved version of Blowfish - Twofish is open source
AES-128, AES-192, AES-256 - 16 byte block size - one of the more secure forms of encryption
Serpent - 128 bit, 192 bit, or 256 bit keys - 16 byte block size - Serpent is open source - close to AES for security level
IDEA - uses a 128 bit key, 64 bit block size - it was designed to replace DES, it was patented, but the patent is due to run out shortly
RC2 - various possible key lengths up to 128 bits - 64 bit block size - a proprietary algorithm originally designed for inclusion with Lotus Notes, it has since spawned RC4, RC5, and RC6 - RC5 can use key lengths up to 2040 bits

There are fewer stream ciphers, and they include -

SEAL - works well for the encryption of hard drives - patented to IBM
RC4 - widely used, and fast, but maybe not the most secure - more easily implemented in software than in hardware - it was used in WEP, which now has well documented weaknesses, partly due to key re-use within WEP equipment - sometimes used more successfully in SSL, where shared keys are discarded after each session

Public / private key encryption

Some of the encryption algorithms designed around public / private key encryption include -

RSA - keys are typically 1024 to 2048 bits long - can be used for encryption and for digital signatures - SSH-1 can only use RSA - RSA is probably the most widely used public / private key algorithm
DSA - keys can be 512 to 2048 bits long - can only be used for digital signatures - SSH-2 can use DSA or RSA
Diffie-Hellman - historically significant and conceptually important, but not in itself used very much - can only be used for encryption
CEIlIDH - despite the name, it came from the states - it is a significant improvement on Diffie-Hellman
SPEKE - based on Diffie-Hellman, but increases security as it adds password authenticated key exchange - although SPEKE itself isn`t used that much, several other algorithms have been developed from it
SRP - Secure Remote Password protocol - it has its roots in Diffie-Hellman, but also uses password authentication - like SSH, it can be used to authenticate a user to a server, however it is more secure than SSH - there are several revisions of it, up to revision 6 - one of its advantages is that user passwords are not stored on the server, an alternative known as a verifier is used, and even if the server is cracked, knowledge of a verifier does not enable the attacker to learn the corresponding password. SRP can be used for authentication on SSL and TLS
An additional advantage of SRP is that is does not require the existence of certificates and a PKI, most other private / public key algorithms require these

There are several more algorithms for public / private key encryption or signatures, but they are getting somewhat obscure.

A third way to use keys

Apart from symmetric key encryption and public / private key encryption, there is a third way to use keys for encryption, that doesn`t require any kind of key exchange.

It is known as three-pass protocol - each party has their own pair of keys, which they keep to themselves. The basic process is -

the sender creates the message, and encrypts it with one of their keys ( call it S1 ) - then sends it to the other party
the receiving party can`t un-encrypt the message, because it doesn`t have a suitable key - however it then encrypts the message again with one of its own keys ( call it R1 ), and sends it back to the original sender. So the message has now been encrypted twice, with S1 and with R1.
the sender gets the message, and partially un-encrypts the message with S2, then sends it back to the receiving part - the message is now encrypted just once, with the R1 key.
the receiving party can now un-encrypt the message with its R2 key

So the message is always encrypted, and neither party needs to know the keys of the other party.

At least two different algorithms exist for the encryption process.

The three-pass protocol only does encryption, if authentication is required, this would have to set up on top of the three-pass protocol.

It would appear to have two weaknesses - the first is that the same keys are being repeatedly used, which is a known weakness of encryption - both parties would have to be responsible for generating new key pairs at regular intervals. This could be done at any time without telling the other party, but not within any particular message set.

The other weakness is that this system is vulnerable to a man-in-the-middle attack, where a rogue receiver replaces the intended receiver - the sender would not know this had happened.

MS Windows and file encryption

There is an increasing amount of pressure on both individuals and organisations to protect data. One of the ways that is continually being recommended is to encrypt the data. However the disadvantages and problems of encrypting data in files are rarely mentioned. I haven`t gone into this in great detail, but what follows are some of the issues that people should be aware of, before starting to encrypt files. I have based it around MS Windows, as that is the operating system most likely to be found in organisations.

once a file has been encrypted, you are absolutely at the mercy of the key - lose the key - you lose the file
keys are vulnerable - they can be deleted or made unavailable in many ways - by removing or renaming an account, by re-installing the operating system, by having your account corrupted, by having the administrator force a password change on a local account - you should back up your keys
Vista and Windows 7 allow for the keys to be stored externally on smart cards
encryption and compression are mutually exclusive, you can only do one or the other
encrypting files considerably increases the time it takes to access them
you need to be aware of how MS Windows handles encrypted files - it makes a difference whether you are on a stand-alone pc, or part of an Active Directory Domain
you need to be aware of how MS Windows copies or moves encrypted files to other hardware -

it can make a difference whether you move a file or copy the file to a new location

if you are copying or moving an encrypted file to an MS Windows server, in some cases it will transmit the file in its encrypted form, and in some cases it will un-encrypt the file, so the file is transmitted in clear text form, then encrypt it again on the server

you need to ascertain what happens if you copy or move an encrypted file to a non-Windows server, such as Netware or Unix - it may end up unencrypted, so you have a security problem, or it may end up still encrypted, but thereafter you may not have access to the key

I believe that both WebDAV and iSCSI can be used to transfer encrypted files onto other types of server, if you specifically want the encryption to be retained - however you may need to set up some sort of virtual NTFS drive on the remote server

the same issue may arise with USB memory sticks, many of which are based on FAT32 - normally the files will be un-encrypted before being sent to the memory stick

in some cases you will be given a choice as to whether to copy / move in encrypted form or in unencrypted form

later versions of the command-line tools XCOPY and COPY have switches to select encrypted or un-encrypted form
just because you encrypt a file, that doesn`t mean that no-one else can read or access it - on both stand-alone pc`s, and on Active Directory member pc`s, some administrators can set themselves up with the ability to un-encrypt other users encrypted files - maybe handy if you can`t get into an encrypted file, but bad for security - it should be possible to disable encrypted file recovery if security is important - however you have killed the ability to recover as well
if a laptop with encrypted files on it is stolen, the thief may be able to access and un-encrypt the files by re-installing the operating system, setting himself up as the administrator and as a recovery agent, then un-encrypt the files - this can be prevented by removing the recovery keys from the laptop, and storing them somewhere else
in MS Windows, file encryption is based on EFS - Encrypting File System - later versions of MS Office are EFS compatible, however other applications may not be fully compatible with EFS
in Active Directory, EFS can be disabled via Group Policy - this creates a registry setting on the pc
on local machines, EFS can be disabled with another registry setting
saving a file in encrypted form will temporarily create plain text shreds of the file on the hard drive - although not visible through Windows Explorer or DIR, they could be recovered using a more sophisticated NTFS recovery tool, until they are overwritten by subsequent file storage - using cipher.exe can force them to be overwritten, and so not be recoverable - however it isn`t a tool you would want to use routinely
using an encrypted file in an application will often leave a copy of the un-encrypted file in places like the Temp folder, the Paging file, temporary files within the application programme files, and working folders within user profiles ( Vista can be set to encrypt the page file, but it slows down the pc )
if encryption is specified on a per-file basis, programmes like Word that do auto-backups will leave unencrypted versions of the file in the working folder - this can be prevented by specifying encryption on a per-folder basis
if you specify encryption on a per-folder basis, the folder itself is not encrypted, and behaves like a normal folder - however every file in the folder is automatically encrypted
different versions of MS Windows have by default used different encryption algorithms - if an organisation has different versions of MS Windows, it needs to ensure that backward compatibility of the encryption algorithms is maintained
in some cases, it may be possible to set up a file server under Active Directory to allow remote users to encrypt files on the server using a private key - the private key is stored in a profile on the server - however it can have an impact on file sharing, and will have a considerable impact on file back-ups, and how they are done

Vista introduced an additional completely different type of encryption from EFS - it is called BitLocker - and it can encrypt the whole hard drive on a per volume basis, so it makes stolen laptops a lot more resistent to unauthorised access. It is a completely different subject, and I haven`t gone into at all in this web page.

However BitLocker in Windows 7 can be used to encrypt USB memory sticks and external hard drives, even if they are using FAT32.

When I started to look at file encryption and MS Windows, I had no idea that I would find so many tripwires. In their efforts to make encryption transparent to users, Microsoft seem to have built an overly complicated system - is it really neccessary to use a combination of both public / private key encryption AND symmetric key encryption just to encrypt some files on the hard drive ?

Do you really need more than a password/pass-phrase driven private symmetric key encryption system, which uses a standard well-proven symmetric key algorithm ?

Perhaps there would be advantages in not using the encryption system built into MS Windows, but instead to use some kind of third party application software to do the encryption. The users would have to be more interactive with the encryption mechanism, but it would remove most of the tripwires associated with the MS Windows encryption system. It would also make copying and moving encrypted files between different hardware much simpler, and may possibly allow for the same encrypted files to be used on different operating systems - ie, moving and using encrypted files on MS Windows, MAC`s, Linux, etc - instead of being restricted to MS Windows.

It appears that for an organisation, or an individual, to start using file encryption, a lot of research is required, to find out how encryption is going to fit into their IT environment. Setting up a file encryption environment is not trivial, it is going to change things, it adds a whole new layer of technology which can go wrong, and I`ll guarantee it will increase support calls.

Just how do you tell someone that all their work for the last 5 years is safely stored away - but completely inaccessible because their key is corrupted ?

Key management

One of the aspects of encryption systems that may get overlooked is the importance of key management - whether an organisation is using symmetric key encryption or public / private key encryption, the security gained through the use of encryption is only as good as the security of the keys used.

Like many aspects of IT, there is probably a bigger risk of encryption being cracked by keys being obtained through poor key security within the organisation, rather than through communications being evesdropped in the outside world.

Is internet security just an illusion ?

After doing these pages on SSL, SSH, and encryption, one of the thoughts I am left with is that internet security is just an illusion.

We have mathematicians, software writers, and hardware designers all designing encryption systems that use larger and larger key lengths, and more and more robust algorithms, to produce encryption systems that can take 10 years to crack.

Yet we build the whole system on the assumption that the server we are talking to is the server we actually want to talk to.

We base this assumption on a certificate that is in our browser.

The certificate is in our browser either because the browser creator put it there, or we tried to connect to a server that our browser didn`t know about - and the server put it there. All we had to do was just tick a box that allows the server to install the certificate.

Or maybe a completely innocent looking website offering downloads put it there, and we ticked the box without really having any understanding of what was happening.

Once that certificate is in the browser, any server that relates to that certificate is regarded as safe. No matter how unsafe the purpose of the server.

Now at this point it could be argued that the internet is quite safe, because the Public Key Infrastructure is there as a mechanism to ensure that everybody is who they say they are.

However there are snags with the PKI.

The first is that the PKI is a big money making machine - a lot of companies are making a lot of money selling certificates and providing a trust tree - so there is a strong vested interest in perpetuating the idea that the PKI is making the internet safe.

The second is that the PKI only has an involvement in certificates that are bought through Certificate Authorities that are part of the PKI - the PKI doesn`t have an involvement in certificates that come from elsewhere - so the PKI itself can confirm that some certificates relate to who they say relate to - it can`t provide information on the others. How to deal with these is left to the browser and ultimately the user.

Finally, it is quite easy to acquire a legitimate certificate with little more than a domain name and an e-mail address, at low cost. Certificate Authorities are companies that want to make money by selling certificates - and some of them don`t ask too many questions.

So I don`t think that the PKI provides the assurances that it should.

website design by ron-t

website hosting by freevirtualservers.com

+ +