Application Level Cryptography

{LANG_NAVORIGIN} Encryption
Ashish Anand 07/05/2005

PGP Vulnerabilities

Fake PGP: Since it’s all open source, there are fake versions of the famous software floating about the net. Unless you’re sure that your copy of the program is from a trusted source, it wouldn’t be surprising to realize one day that your pass phrase was sent to an attacker via email the moment you went online! Once he has your pass phrase, he has your private key. Key transfer using public key cryptography is useless after this point.

Tempest attacks: Another kind of attack that has been used by well-equipped opponents involves the remote detection of the electromagnetic signals from your computer.

This expensive and somewhat labor-intensive attack is probably still cheaper than direct cryptanalytic attacks. An appropriately instrumented van can park near your office and remotely pick up all of your keystrokes and messages displayed on your computer video screen. This would compromise all of your passwords, messages and so on. This attack can be thwarted by properly shielding all of your computer equipment and network cabling so that it does not emit these signals. This shielding technology, known as ‘tempest’ is used by some government agencies and defense contractors. There are hardware vendors who supply tempest shielding commercially.

Keyloggers: Consider a keystroke recorder logging your pass phrase and emailing it to an eavesdropper. What’s the purpose of complex algorithms and 128 bit public keys when your own private key is in someone else’s hands? My program overcomes this issue with the mere fact that the only input the user will provide to the system are a bunch of random keystrokes for key generation. Any sensitive pass phrase or the private key is never “typed” by the user. There’s no question of encrypting the key and storing it locally. I’m essentially using a different key for each transaction. Since it’s a one time session key, it gets erased from the memory the moment the encryption operation is completed. (Whether the key is physically; actually; erased from the hard disk or not – is another issue, which may be exploited by data recovery packages; but then, this issue exists in PGP as well, and besides, clearing out swap files or overwriting on virtual memory…is not what my project is about!).

Given below is an outline of the algorithm for the system I designed:

Step 1: Processing of Plain Text
Read input file “PLAIN.TXT” sequentially (bit by bit) and generate its binary output. Since the ASCII Character Set consists of 256 characters (0-255), it follows that 8-bits are required to represent each character in its binary form. (28 = 256)

Step 2: Addition of One Time Pads
Pad each binary number with subsequent zero’s towards the Most Significant Bit (MSB) until the total number of the binary bits equals ten. This is required as the binary data is being encrypted using a 10-bit private key. Output is saved in file “BINARY.TXT”.

Step 3: Key Generation By Measuring Keyboard Latency
Take random input data from the keyboard. The time difference between each keystroke serves as an excellent source of randomness. The beauty of encryption lies not in the complexity of its algorithm, but how the key is generated. My key generation technique is based on a function that sums the millisecond field’s value of the time difference between each keystroke and either divides or multiplies the sum with another random number generated based on its magnitude and converts the final output into a 10-bit binary that is used as the private key. This key is saved in another file “PVTKEY.TXT” in binary form for future reference.

Step 4: Encrypting Plain Text (Phase I: Stream Ciphering)
Each 10-bit binary block is sequentially read from “BINARY.TXT” and XORed with the 10- bit key as read from “PVTKEY.TXT”. The resulting 10-bit data is stored in “XOR.TXT”. This process is often referred to as whitening. Step 5: Addition of Salt
We shall be using 16-bit long blocks of data during the second round of encryption. Hence the number of bits in “XOR.TXT” must essentially be an integral multiple of 16. For this purpose, n-bits of 0’s are padded at the end of “XOR.TXT” where ‘n’ is calculated by the following formula:

n = 16-[{(count-1)*10}%16]

where,

(count-1) :	represents the number of characters in plain text
* :	represents ordinary multiplication
% :	represents remainder after ordinary division

To make matters more complex, one may add salt values other than a continuous stream of zeros. Having another function to decide what salt values to use, based on the value of ‘n’ generated from the above mentioned formula wouldn’t hurt, although this change would require alterations in the proceeding steps. I would probably incorporate this, in the next version of my program.

Step 6: Generation of Sub-Keys for Block Ciphering
Two sub-keys K1 and K2 are generated using the private key. The first 2 bits from the MSB of the Private Key are discarded. The remaining 8 bits are complemented and saved as K1. The contents of K1 are reversed to obtain K2. Agreed this means of generating sub-keys is lame. But it’s no big a deal complicating this function, and would be taken care of, in the next version.

Step 7: Division of Stream Cipher into blocks for double encryption
The number of bits in the file “XOR.TXT” are now divisible by 16. Blocks of 16-bits are processed sequentially. Each 16-bit block is divided into two equal halves X1 and X2.


Fig. 3. Diagram showing 1 block of length 16-bits being sub-divided into X1 & X2, each 8-bit long

Step 8: Encrypting Stream Cipher (Phase II: Block Ciphering)
The following operations are performed using X1, X2, K1 and K2 and the result is stored in “CIPHER2.TXT”


where,

:	represents XOR operation

Y1 and Y2 are concatenated to obtain a 16-bit binary block. This process is applied on the entire stream cipher.

Step 9: Processing of Block Cipher - I
The length of the binary file “CIPHER2.TXT” is essentially a multiple of 16. Thus it is implied that it is also a multiple of 8. Now we sequentially read 8-bits at a time and convert each 8-bit number into its decimal equivalent. The value of the decimal equivalent will always range between 0-256. Each corresponding decimal equivalent is padded to 3 bits of length (for instance, 3 is converted to 003, 52 is converted to 052, 145 is left as it is) and written into the file “CIPHER3.TXT”.

Step 10: Some more salt please!
The number of characters obtained from block ciphering the file “CIPHER3.TXT” needs to be a multiple of 2 for the next round of block ciphering. Since each character obtained from the previous file is being represented by 3 numbers in “CIPHER3.TXT”, the length of “CIPHER3.TXT” must essentially be a multiple of 3. I’m making it a multiple of 2 by padding the end of the file with a zero.

(I realized later that if suppose there are 2 characters obtained from processing the file “CIPHER2.TXT”; that would hold true if it consisted of just 16 bits, then the number of characters in “CIPHER3.TXT” would be 6, which is already a multiple of 2. Thus, subsequent addition of a zero would ruin things up a little, by printing a garbage character at the end of the decrypted text. This minor bug shall be removed in the next version of the program)

Step 11: Processing of Block Cipher – II
The file “CIPHER3.TXT” is now sequentially read, but this time 2 bits at a time. Thus at each read operation, we essentially obtain an integer between 00 and 99. 33 is added to each number and the ASCII character corresponding resulting number is written into the file “CIPHER.TXT”. The basic issue was to avoid low range codes as they contain non-printable characters, escape key codes, line breaks, spaces etc.

The cipher-text would then be compressed.

The next version of the program would incorporate a final transposition ciphering function at this stage. I’m working on a transposition function that would play around with the values just obtained and side by side make sure that the transposed resultant wouldn’t violate the ‘avoiding a low ASCII code range’ condition. The output of the transposition function is dependent on the private key. Thus, it isn’t possible to uncompress without the key, even if the algorithm is made public and an eavesdropper has access to the compressed cipher-text.

Thus the file “CIPHER.TXT” contains the cipher text corresponding to the contents of “PLAIN.TXT”.

Sample Plaintext

LZW Compression

The LZW compression method maps strings of text characters into numeric codes.
To begin with, all characters that may occur in the text file are assigned a
code. For example, suppose the text file to be compressed is the string:

aaabbbbbbaabaaba

The string is composed of the characters 'a' and 'b'. 'a' is assigned the code
0 and 'b' the code 1. The mapping between character strings and their codes is
stored in a dictionary. Each dictionary entry has two fields: KEY and CODE. The
character string represented by CODE is stored in the field KEY.

Corresponding Cipher text

[Note: Cipher text not compressed yet]

6!V(]H7@l.]ƒ2iJ7,s3rt/"b!qƒ3|H4Tr2740Jt(Is+}/5+W7"„/^`(@o/UK7-OJ„/
Tt(5c/UN6{W#sD7@a!r?4iK5+X7"h/,b!r/0AK5+W#s<7@_(6•7}N5+W7#40r`5"?.iN
6^45Jt7@b!r/6AG5+W"6l/^c!|o1-;5+W7"„0Tc!|`3|^65W#}T0hc!s;1-
H5+X0_8.|b(]t.A96qW%UT0^b(6?5U96iP27H/,`/"O6AB6h42AT/^d!{$.AG6iO7"l/,t(
5#3|^7!W+sH7@_(6•7}N5+W/#8/hc"6O-
}L6^/8_X/"`.]#0AH6^32AT0rt(6_3U>6^/"AT3Ta.hp.A=7?W:7(/@a(6€3,^7-
P3rx/@a.h_/T^7!W+sH7@_(6•7}N5+W/#8/hc"6O6AG5+W5KH7@d.]ƒ2iJ7,s3rt/"c!s,.
AA7-K8^h0,c"6O5-N7,s-J€06n5]T$@E4T-(gt9^z"I$$@E6h3:7X0hd5"o/-
<6hs:7X0hd!r?/-94Tm(gt2,b(6€.AK7!X5K8/Tc/"O1-K5+W7"„/^`(5ƒ5-
=6]S8^„0@t(A+1U=5+W7#40r`5"?.iN6^45Jt7@s.^@0@^6h3"7D7@s.^p0@l5+S0_X6^t(
5#5,^6h47"t0"c.^//U>5+X2740Jt(6_3U>6^/8hx7@d!r//|^5#O5U@7@_(53/T^6iO#sD
0Jt(h@3|^65W+sH7@a!r?4iJ6|3"7@7@d5"•6AO6^33r€7@d.]3-}L6h37"h0J`5JO5-
N7,s-J€06`/"O-}H6]S8^h0,c!q#5T^6iO#sD0J`/"O1-
K5+X7"h/J`5"•/|^6|3"AT0rt(7+1-;7!WJ„/
Td!|o7Tl5+U3sX0^b(^O/}A6iP278/Ja5"?5UQ5+W3r€.|`5+$.AB6h47-
T.|_.]„.A@6|33s$0T`/+T.A#5r2-
UT0ra5#,.@•6#M26,5|t(U+1U=5+W7#40r`5"?.iN6^45UT/"_(@o1-
H6_K8^p0J`(@o/UK6^3"6h0Jc(^O/-Q5+U7!h3hk"6O1-
K5+X7"h/,a.^•/|^6|3"AT.|b(6€.A@6|33s$0Tt(IC"i156p*

Private Key Used

Disclaimer

This project, for me, is an ongoing process of learning; and like any other open source project, would claim to remain ‘under development’ till the end of time! The next version of my program would incorporate the following points I currently have in mind:

• Compressing data after encryption to reduce redundancy and provide more immunity to frequency analysis attacks
• Longer key length (so that a brute force attack would theoretically take longer than the age of the universe to complete)
• Applying more randomization functions on the data obtained after calculating keyboard latency in order to make the process of key generation even more secure
• Performing modular (clocked) arithmetic operations for key generation
• Use a transposition ciphering function after the process of whitening and multiple block ciphering
• Minor bug fixes, as discussed above

A ‘Terminate and Stay Resident’ version would make it possible to read the encrypted file in DOS and transfer its contents to the Windows Clipboard. This is done by playing around with hardware interrupts at the OS level.

Another side project that I have initiated is making a TSR version of the program. This would make it highly inter-portable between Windows & DOS. My aim was to code in C++ (DOS based, not the Windows based VC++) but still make it possible for a user to “Ctrl. + V” the encrypted message into his browser when he arrives at the ‘Compose Message’ screen. This would eliminate the need to send the cipher-text as an attachment, thus making the entire process more convenient.

Since the instant messaging server is being developed on a Linux platform, coding a Linux based version of the cryptosystem wouldn’t hurt either. Further ideas about the client-server model would be discussed in the presentation.

“Those who claim to have an unbreakable cipher simply because they can’t break it are either geniuses or fools. Unfortunately, there are more of the latter in the world.”

Wireless Security: A short note

The IEEE 802.11b standard uses WEP (Wired Equivalent Protocol) to send packets over a wireless network that are converted into a format equivalent to the regular Ethernet packets. The catch is that the moment a wireless base station is connected to the Ethernet, all the traffic on the Ethernet suddenly appears on the wireless interface (exceptions might arise, but this would certainly hold true in case of a non-switched topology). This is similar to the case where a LAN Interface can be set to ‘promiscuous mode’ thus making it possible to intercept packets that are not intended to arrive at that interface.

What this boils down to is that if I take my laptop to the basement of your office that uses a Wireless LAN, and if your DHCP server permits an additional node to be added to the network (your administrator didn’t consider defining IP Leases!), or if it were possible that my laptop got assigned an IP address under the same subnet as that of the wireless network, I could then simply run a network analyzing utility on my laptop and filter out packets and be able read plain text mails traveling within and out of your office’s network. Sounds cool doesn’t it? By the way, the same would hold true for being able read chat sessions (though messengers aren’t permitted to be installed in an ideal office environment!).

Now that’s what happens when you simply ‘plug and play’ your brand new wireless station, with the security options turned off as factory defaults. That’s what happens at MTNL!

RSA Security came out with algorithms such as the RC2, RC4, RC5 that are used to encrypt packets flowing across a wireless network. The base station and the node share a secret key which is used for encryption/decryption of packets [4].

To sum up, wireless security is yet another discussion altogether, and of course, is out of the scope of this paper.

Software implementation

For those avid cryptographers who don’t find my results convincing but are still curious about what this is all about, here’s an encrypted version of my programs source code: http://ashishanand2.tripod.com/s ource/source.zip

References

[1] Applied Cryptography – Bruce Schneier
[2] D. Balenson, Feb. 1993. RFC#1423: Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers - Network Working Group
[3] D. Comer, D. Stevens, Internetworking with TCP/IP (Client - Server Programming & Applications)
[4] A. S. Tanenbaum, Computer Networks
[5] RFC#2440: OpenPGP Message Format
[6] www.pgp.com, www.openpgp.org














Your IP address will be sent with this e-mail

From e-mail to e-mail