
February 24th, 2005, 05:02 PM
#1
Senior Member
Simple Encryption
I am coding a shift + transposition encryption program. I have read articles about these 2 algorithm and it seems that they omit punctuation and spaces in the cipher text. How can decrypt the ciphertext back to the original message with punctuation ?
note: my encryption program is based on keyword

February 24th, 2005, 05:35 PM
#2
Hi
Let's look at it in another way:
Your plaintext consists of elements of an alphabet A(usually az, AZ, 09, ",", ".", "!", ...).
Your ciphertext might be based on the same alphabet A, but does not have to. It also
could be another alphabet B (!@#$%^&* ... )
You cipher (an algorithm for encryption and decryption) may be a permutation
(shift and transposition), ie
Code:
a <> i
b <> m
. <> .
Such a "mapping" replaces a with i and back, but leaves the dot as a dot.
People usually think, that the shift/transposition only works on "alphanumerics",
but this is not true:
When you decrypt the ciphertext back, your cipher uniquely defines the dot
as a dot. (or space as space, comma as comma).
A welldefined cipher knows how to deal with any [group of] elements of the
alphabet A, which might appear in your plaintext, and for the decryption process,
it also knows how to deal with any [group of] elements of the alphabet B of
your ciphertext.
Cheers.
If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 190870)

February 25th, 2005, 06:00 AM
#3
Senior Member
HMm... so i will include the spaces and "." into the encrypt process. Example. in my defined array that "." is defined as number 99. Example of plaintext + key will make my calculation as 99 + x(key) so for my decryption process i will minus away the value of key. Yeah. thanks alot

February 25th, 2005, 10:27 AM
#4
or just use the ASCII values, that works, ive done that before
i2c

February 25th, 2005, 01:15 PM
#5
After you're done with that, have a look at xor encryption. Once again, it's pretty simple, but it's also relatively effective. I wouldn't recommend you to actually use it for anything important, but for getting to understand encryption...
http://download.cdsoft.co.uk/tutorials/xorencryption/
and if you're interested in a simple xor problem,
https://www.cis.strath.ac.uk/teachin...ncryption.html
ac

February 26th, 2005, 04:56 AM
#6
Hi
I have to disagree with the statement, not to use XOR for sensitive data,
which implies that XOR encryption per se is insecure. Such a statement
should be looked at a bit more precise. Sorry about the length of that
post, but, well, it just happened
XOR encryption can be made factual unbreakable  and is in addition used
as a simple mean to enhance the strength of other encryption methods,
such as the obsolete DES.
The strength of an encryption is, among others, based on the key size,
and the "randomness" of the key. Example:
onetime pads
Every unbreakeable cipher is equivalent to the onetime pad cipher(Shannon[1]).
This cipher has a simple description:
Code:
a) Create a random text of the same length as the plaintext
b) encryption: ciphertext[i] = plaintext[i] ^ randomtext[i]
c) decryption: plaintext[i] = ciphertext[i]^ randomtext[i]
Note: ^ is the XOR operation.
However: The onetime pad is only unbreakeable if the randomtext truly is
random (create a randomtext using your compiler's builtinrandom generator
and I eventually decrypt the ciphertext within, let's say, an hour). And,
of course, if the onetime pad is used only once ... (Russians ? )
product ciphers  DES and co.
XOR is also an excellent tool to enhance confusion and diffusion[2]
of information (yep, security through obscurity is also a part of
cryptology.)  hence, enhancing the strength of a cipher. Example:
DES.
DES was a standard starting 1976, and "unbreakeable" at that time. Nowdays,
they can be broken in less than a day due to the small key size of 56bits.
People wanted to improve DES. Yet another issue has to be taken into account:
The efficiency (in units of "speed") of the encryption/decryption process.
> TripleDES applies DES 3 times  in principle obtaining a 3*56bit=168bit
key. However, the cipher is rather inefficient ("slow") compared to
> DESX, which applies a XOR (64bit), a DES and another XOR (64bit). DESX
effectively increases the key size to 184 bits in no time (=efficient="fast").
I just realise that I drift away from the original topic. Sorry about that,
but maybe for one or another this was an interesting read ... and maybe not
Back to topic
Nevertheless, gothic_type did a good recommendation: Death_Knight,
increase your knowledge in the field, as it seems you are interested, by studying
industrial standards, such as DES[3a,3b], after accomplishing what you are doing
now and the XOR cipher. In case you have questions, I am happy to help, because
it is also one of my preferred fields of interest.
Cheers
[1] http://en.wikipedia.org/wiki/Claude_Shannon
[2] http://en.wikipedia.org/wiki/Confusion_and_diffusion
[3a] http://www.tropsoft.com/strongenc/des.htm
[3b] http://www.antionline.com/showthread...hreadid=266204
If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 190870)

February 26th, 2005, 11:42 PM
#7
XOR, unless used in a OneTime Pad, is a bit deceiving in terms of security. It isn't bad, but it falls to the Known Plaintext attack(s).
Basically if someone can find a part of the message that is similar to some known text, such as encrypting a HTML file with XOR and knowing it starts with "<HTML>" or ends with "</HTML>", you already have a chunk of the key that you can use to decrypt other parts of the message it was used at, and you can make guesses as to what other parts of the message are and see the other places the chunk you guessed is used at.
Generally the recommended way to protect against that is to compress the message, since compression works to make stuff more random (since random data, quite simply, can't be compressed). When the data is random, you don't know what "<HTML>" would have become before it was encrypted. (Okay, you actually can know what it was compressed to some times, but that is another topic in itself...). If you can't make the connections to random data, you don't know if you guessed the key correctly. Which effectively brings the security up near the stated key strength.
The onetime pad never repeats the key, so these attacks don't work. You only know the part you guessed, and you can't even be sure if you got it right...which is why XOR is commonly used for it. The only problem is you have a HUGE key the size of the data you encrypted that you need to keep safe...
I've never heard of DESX, but what happens if the first XOR key and the second one are the same? You're back at plainol DES (If I understand the execution of this correctly). But fortunately it doesn't sound like an easy task to determine if that is the case

February 26th, 2005, 11:51 PM
#8
As for the OP, most of the times those ciphers are designed to work with AlphaNumeric values. Some input systems don't like special characters, and since the data/encryption is 1:1, if you exclude those special characters you can't represent them with other characters.
If you include those special characters in it, then you can represent them with something else. Or you can simply not change them in the first place, but you might have "TIVL! EJSY YJR JRAA STR UPI YSALOMH SNPIY? TRSAAU? MP!" And someone might guess "MP!" stands for "NO!" and "SNPIY?" stands for "ABOUT?". (The message isn't worth guessing, simply some explicitives thrown into a question)
Anyways, it seems like you found a solution for your problem. Cheers.

February 27th, 2005, 12:13 AM
#9
Hi
Tim_axe, "as usual" you brought up some good points.
Compression, as diffusion, increases the "entropy" of the
system  the randomness, as you say. In DESX, "white noise"
is added by two XORs.
As it is with industrial standards, people want to map
new schemes back to the old ones. As far as I know, but I had
to do some research (... )
> In TripleDES, this is the case when either the second or the third
DESkey is identical to the first one.
> In DESX this is only the case if the two XOR keys, k2=k1=0! [1]
The reason is that DES and XOR do not commute.
Cheers.
[1] http://www.cs.ucdavis.edu/~rogaway/p...abstract.html
If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 190870)

February 28th, 2005, 05:07 PM
#10
Senior Member
t do cryptography well, one must be very good in maths ?
Posting Permissions
 You may not post new threads
 You may not post replies
 You may not post attachments
 You may not edit your posts

Forum Rules

