#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2017
    Posts
    3
    Rep Power
    0

    Simple One Time Pad Concept


    Hello people,

    I've tried to do something very simple here, which is to encrypt a message with a one-time-pad (OTP) and include the next OTP as part of that same encrypted message. i.e. The first message consists of the actual text of the message, an '=' as a separator and then the next OTP. The length of the OTP should always stay the same, so I did some basic bit manipulation to squeeze more than one character into a byte.

    My main question: Is the fact that the next OTP is included at a known location in every encoded message a factor that will allow decryption of the messages given a few encrypted messages?

    Perhaps someone can try and break this for me? I can post say 3 encrypted messages and the source code.

    (I realize using an '=' as a separator isn't great and I should rather use something like PKCS7, but it's just a concept, so don't use the '=' to crack the encryption.)

    Regards,
    Sci
  2. #2
  3. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,478
    Rep Power
    1875
    So let's say you have an initial shared OTP of 200 bytes, which you use to send a message of 100 bytes and the next OTP of 100 bytes.

    The next time, you're stuck with only being able to send a 50 byte message and a further 50 bytes of OTP for next time.

    Then you're down to 25 + 25.

    Pretty soon, you're faced with the problem of how to secretly share an original OTP with your communication partner.

    Such meetings tend to be very hard to arrange, so you usually swap a LOT of OTP, like say several DVD's worth.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2017
    Posts
    3
    Rep Power
    0
    Hi Salem,

    Yes that was one of the problems I faced, but what I've done is store more than on character in each byte by using a simple bit mapping substitution.

    This allows me a certain amount of space for a message and the rest is for a new OTP that, although it fits into less bytes, is nonetheless the same length as the original pad.

    Having solved that problem, I'm now wondering if this structure causes a weakness in the whole thing.
  6. #4
  7. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,478
    Rep Power
    1875
    Sorry, I just don't see how you're not reducing the amount of pad you're sending for next time. A real OTP cannot be compressed (by definition) if it is truly random.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2017
    Posts
    3
    Rep Power
    0
    Cool thx for your input. That's not really my question though, just assume it works somehow :-)

IMN logo majestic logo threadwatch logo seochat tools logo