General Encryption Questions

Welcome to Crypto. We hope you enjoy your visit.

You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.

Join our community!

If you're already a member please log in to your account to access all of our features:

General Encryption Questions; programming methods
Topic Started: Nov 14 2006, 10:08 PM (274 Views)
loki	Nov 14 2006, 10:08 PM Post #1
Advanced Member Posts: 87 Group: Members Member #48 Joined: April 28, 2006	a character is an 8 bit varible, in C its an unsigned char. Is there any advantage at all to expanding this to a short int (16 bit) or as commonly seen long 32 bit. the reason I ask, is that im nearly finished the next baldr which uses a block length of 256 bits. I am using unsigned shorts. The reason why escapes now. I just foresee the question, why are you using unsigned shorts. I the answer "I really dont know", So I won't realese it until I understand why. So whats the advantage to using one varible over the other? Am I even making any sense to anyone ?
	c(x) = 3x3 + x2 + x + 2; Find the inverse


loki	Nov 16 2006, 03:05 PM Post #2
Advanced Member Posts: 87 Group: Members Member #48 Joined: April 28, 2006	here is anouther question, has anyone ever used a binary tree in an encryption algortyhm? I know its used in some huffman compression schemes, I thought that it would be a great pre encryption method to find all major occarances of symbols and modify them using a counter. I know its almost silly since cbc, ofb, etc etc are designed as it is to do this. But was curoius if any has done it.
	c(x) = 3x3 + x2 + x + 2; Find the inverse


Donald	Nov 17 2006, 01:36 PM Post #3
Elite member Posts: 454 Group: Trusted Member Member #8 Joined: September 2, 2005	"Loki" a character is an 8 bit varible, in C its an unsigned char. Is there any advantage at all to expanding this to a short int (16 bit) or as commonly seen long 32 bit. From a modern encryption point of view, you really don't care if the data is 8 bit ascii, Unicode, a sequence of 32 bit integers, or even 7 bit ascii. From the encryption program's point of view, its just a string of bytes. SO, the only ADVANTAGES from switching from encrypting one 8 bit byte at a time to encrypting blocks of 16, 32, 64, 128 or even 256 bits are cryptographic mixing and speed. Speed because a program that encrypts blocks of 128 bits at a time may be able to run more quickly and efficiently. And Cryptographic mixing because when you encrypt a larger block, your algorithm presumably is dependent upon a larger chunk of the data at a time. to put it back into simple pen and paper cipher terms. With most ciphers, you encrypt one character at a time, and the encryption of that character is NOT dependent upon what characters were around it. BUT, with a playfair, you encrypt two characters at a time. The letter "A" will encrypt differently depending upon what other character of the plaintext it is paired with. This "mixing" makes decryption more difficult. And I like a double overlapping variation of Playfair. It uses the same rules as playfair, but has a variant "doubling" rule. If you run into a double letter, instead of separating them with a null, you encrypt with the double of the letter below and to the right. Now then, with that one rule change, you encrypt twice, preferably using two different keysquares, like so: Step 1: Encrypt the text with playfair using keyword 1 using ordinary playfair divisions. So if the message was ABCDEFGH, it would be encrypted as AB CD EF GH Step 2: Encrypt the results of the above encryption with playfair AGAIN using keyword 2, BUT, start at the SECOND character, and encrypt the first and last characters together. So if the result of the above was KLMNOPQR, it would be encrypted as K LM NO PQ R (with K and R being encrypted together) The end result is that each letter in the plain text is encrypted not only depending upon one letter next to it, but on three. The plaintext C is first encrypted combined with the plain text D, and then encrypted again combined with the encryption of the plain text B, which was dependent upon the plain text A. It's much more MIXED, and I certainly wouldn't want to try and decrypt the resulting ciphertext! (Ordinary playfair was hard enough!) With modern ciphers, encrypting based upon a larger block means more mixing and generally a stronger cipher. Within limits. I'm not certain if there are any actual practical advantages to encrypting with a 256 bit block instead of a 128 bit block. But there are certainly advantages encrypting a 128 bit block instead of an 8 bit block.



loki	Nov 18 2006, 09:09 PM Post #4
Advanced Member Posts: 87 Group: Members Member #48 Joined: April 28, 2006	interesting, I like that idea. I think you have just helped me spawn a whole plethora new amatuer ideas I would like try.
	c(x) = 3x3 + x2 + x + 2; Find the inverse


1 user reading this topic (1 Guest and 0 Anonymous)


« Previous Topic · General · Next Topic »