Methods involve in encrypting data

Traditionally, several methods can be used to encrypt data streams, all of which can easily be implemented through software, but not so easily decrypted when either the original or its encrypted data stream are unavailable. (When both source and encrypted data are available, code-breaking becomes much simpler, though it is not necessarily easy). The best encryption methods have little effect on system performance, and may contain other benefits (such as data compression) built in. The well-known ‘PKZIP®’ utility offers both compression AND data encryption in this manner. Also DBMS packages have often included some kind of encryption scheme so that a standard ‘file copy’ cannot be used to read sensitive information that might otherwise require some kind of password to access. They also need ‘high performance’ methods to encode and decode the data.

Fortunately, the simplest of all of the methods, the ‘translation table’, meets this need very well. Each ‘chunk’ of data (usually 1 byte) is used as an offset within a ‘translation table’, and the resulting ‘translated’ value from within the table is then written into the output stream. The encryption and decryption programs would each use a table that translates to and from the encrypted data. In fact, the 80×86 CPU’s even have an instruction ‘XLAT’ that lends itself to this purpose at the hardware level. While this method is very simple and fast, the down side is that once the translation table is known, the code is broken. Further, such a method is relatively straightforward for code breakers to decipher - such code methods have been used for years, even before the advent of the computer. Still, for general “unreadability” of encoded data, without adverse effects on performance, the ‘translation table’ method lends itself well.

A modification to the ‘translation table’ uses 2 or more tables, based on the position of the bytes within the data stream, or on the data stream itself. Decoding becomes more complex, since you have to reverse the same process reliably. But, by the use of more than one translation table, especially when implemented in a ‘pseudo-random’ order, this adaptation makes code breaking relatively difficult. An example of this method might use translation table ‘A’ on all of the ‘even’ bytes, and translation table ‘B’ on all of the ‘odd’ bytes. Unless a potential code breaker knows that there are exactly 2 tables, even with both source and encrypted data available the deciphering process is relatively difficult.

Similar to using a translation table, ‘data repositioning’ lends itself to use by a computer, but takes considerably more time to accomplish. A buffer of data is read from the input, then the order of the bytes (or other ‘chunk’ size) is rearranged, and written ‘out of order’. The decryption program then reads this back in, and puts them back ‘in order’. Often such a method is best used in combination with one or more of the other encryption methods mentioned here, making it even more difficult for code breakers to determine how to decipher your encrypted data. As an example, consider an anagram. The letters are all there, but the order has been changed. Some anagrams are easier than others to decipher, but a well written anagram is a brain teaser nonetheless, especially if it’s intentionally misleading.

My favorite methods, however, involve something that only computers can do: word/byte rotation and XOR bit masking. If you rotate the words or bytes within a data stream, using multiple and variable direction and duration of rotation, in an easily reproducable pattern, you can quickly encode a stream of data with a method that is nearly impossible to break. Further, if you use an ‘XOR mask’ in combination with this (’flipping’ the bits in certain positions from 1 to 0, or 0 to 1) you end up making the code breaking process even more difficult. The best combination would also use ‘pseudo random’ effects, the easiest of which would involve a simple sequence like Fibbonaci numbers. The sequence ‘1,1,2,3,5,…’ is easily generated by adding the previous 2 numbers in the sequence to get the next. Doing modular arithmetic on the result (i.e. Fib. sequence mod 3 to get rotation factor) and operating on multiple byte sequences (using a prime number of bytes for rotation is usually a good guideline) will make the code breaker’s job even more difficult, adding the ‘pseudo-random’ effect that is easily reproduced by your decryption program.

In some cases, you may want to detect whether data has been tampered with, and encrypt some kind of ‘checksum’ into the data stream itself. This is useful not only for authorization codes but for programs themselves. A virus that infects such a ‘protected’ program would no doubt neglect the encryption algorithm and authorization/checksum signature. The program could then check itself each time it loads, and thus detect the presence of file corruption. Naturally, such a method would have to be kept VERY secret, as virus programmers represent the worst of the code breakers: those who willfully use information to do damage to others. As such, the use of encryption is mandatory for any decent anti-virus protection scheme.

A cyclic redundancy check is one typically used checksum method. It uses bit rotation and an XOR mask to generate a 16-bit or 32-bit value for a data stream, such that one missing bit or 2 interchanged bits are more or less guaranteed to cause a ‘checksum error’. This method has been used for file transfers for a long time, such as with XMODEM-CRC. The method is somewhat well documented, and standard. But, a deviation from the standard CRC method might be useful for the purpose of detecting a problem in an encrypted data stream, or within a program file that checks itself for viruses.

Read more at http://www.mrp3.com/encrypt.html

Related posts:

1. Is data encrypted in iphone
2. EFS Encrypting file system
3. From Atlas to ASP.NET AJAX: Page Methods
4. Encrypting through USB drive
5. Biometrics uses minutae or correlation base
6. Flaws in custom data encryption

Related posts brought to you by Yet Another Related Posts Plugin.