1. ## 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

2. Hi

Let's look at it in another way:

Your plaintext consists of elements of an alphabet A(usually a-z, A-Z, 0-9, ",", ".", "!", ...).
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 &lt;-&gt; i
b &lt;-&gt; m

. &lt;-&gt; .```
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 well-defined 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

Cheers.

3. 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

4. or just use the ASCII values, that works, ive done that before

i2c

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...

and if you're interested in a simple xor problem,

https://www.cis.strath.ac.uk/teachin...ncryption.html

ac

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:

Every unbreakeable cipher is equivalent to the one-time 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 one-time pad is only unbreakeable if the randomtext truly is
random (create a randomtext using your compiler's built-in-random generator
and I eventually decrypt the ciphertext within, let's say, an hour). And,
of course, if the one-time 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.

-&gt; Triple-DES applies DES 3 times - in principle obtaining a 3*56bit=168bit
key. However, the cipher is rather inefficient ("slow") compared to

-&gt; 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

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

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 "&lt;HTML&gt;" or ends with "&lt;/HTML&gt;", 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 "&lt;HTML&gt;" 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 plain-ol 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

8. As for the OP, most of the times those ciphers are designed to work with Alpha-Numeric 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.

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"

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 (... )
-&gt; In Triple-DES, this is the case when either the second or the third
DES-key is identical to the first one.
-&gt; 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

10. t do cryptography well, one must be very good in maths ?

Page 1 of 2 12 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•