Simple Encryption
Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Simple Encryption

  1. #1
    Senior Member
    Join Date
    May 2003
    Posts
    226

    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. #2
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    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 <-> 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 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
    your ciphertext.

    Cheers.
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  3. #3
    Senior Member
    Join Date
    May 2003
    Posts
    226
    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. #4
    Senior Member
    Join Date
    Jul 2003
    Posts
    634
    or just use the ASCII values, that works, ive done that before

    i2c

  5. #5
    Custom User
    Join Date
    Oct 2001
    Posts
    503
    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

  6. #6
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    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:


    one-time pads


    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.

    -> Triple-DES 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, 1908-70)

  7. #7
    Senior Member
    Join Date
    Oct 2001
    Posts
    786
    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 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. #8
    Senior Member
    Join Date
    Oct 2001
    Posts
    786
    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. #9
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    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 Triple-DES, this is the case when either the second or the third
    DES-key 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, 1908-70)

  10. #10
    Senior Member
    Join Date
    May 2003
    Posts
    226
    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
  •