Encrypting a short string?

Discussion in 'Python' started by erikcw, Feb 11, 2008.

  1. erikcw

    erikcw Guest

    Hi,

    I'm trying to devise a scheme to encrypt/obfuscate a short string that
    basically contains the user's username and record number from the
    database. I'm using this encrypted string to identify emails from a
    user. (the string will be in the subject line of the email).

    I'm trying to figure out which approach I should use to encrypt the
    data. The string will be less than 20 characters long, and I'd like
    the encrypted version to be about the same size.

    I tried DES in the Crypto module, but the cipher text was to long to
    be usable in this case.

    Any suggestions?

    Thanks!
    erikcw, Feb 11, 2008
    #1
    1. Advertising

  2. erikcw

    Guest

    erikcw napisal(a):
    > Hi,
    >
    > I'm trying to devise a scheme to encrypt/obfuscate a short string that
    > basically contains the user's username and record number from the
    > database. I'm using this encrypted string to identify emails from a
    > user. (the string will be in the subject line of the email).
    >
    > I'm trying to figure out which approach I should use to encrypt the
    > data. The string will be less than 20 characters long, and I'd like
    > the encrypted version to be about the same size.
    >
    > I tried DES in the Crypto module, but the cipher text was to long to
    > be usable in this case.
    >
    > Any suggestions?
    >
    > Thanks!


    How about:
    >>> hashlib.sha256("|2937267834").hexdigest()[:20]


    Regards,
    Marek
    , Feb 11, 2008
    #2
    1. Advertising

  3. erikcw

    erikcw Guest

    On Feb 11, 3:07 pm, wrote:
    > erikcw napisal(a):
    >
    >
    >
    > > Hi,

    >
    > > I'm trying to devise a scheme to encrypt/obfuscate a short string that
    > > basically contains the user's username and record number from the
    > > database. I'm using this encrypted string to identify emails from a
    > > user. (the string will be in the subject line of the email).

    >
    > > I'm trying to figure out which approach I should use to encrypt the
    > > data. The string will be less than 20 characters long, and I'd like
    > > the encrypted version to be about the same size.

    >
    > > I tried DES in the Crypto module, but the cipher text was to long to
    > > be usable in this case.

    >
    > > Any suggestions?

    >
    > > Thanks!

    >
    > How about:
    >
    > >>> hashlib.sha256("|2937267834").hexdigest()[:20]

    >
    > Regards,
    > Marek


    Thanks Marek,

    But that can't be reversed, right? I'd like to be able to decrypt the
    data instead of having to store the hash in my database...
    erikcw, Feb 11, 2008
    #3
  4. erikcw

    Paul Rubin Guest

    erikcw <> writes:
    > database. I'm using this encrypted string to identify emails from a
    > user. (the string will be in the subject line of the email).


    1. I hope you're not trying to spam anyone.
    2. What happens if the user edits the subject line?

    > I'm trying to figure out which approach I should use to encrypt the
    > data. The string will be less than 20 characters long, and I'd like
    > the encrypted version to be about the same size.


    Under normal security requirements you cannot do this. The ciphertext
    has to be longer than the plaintext since you don't want the opponent
    to be able to tell whether two plaintexts are the same. Therefore you
    have to attach some random padding to each plaintext. Also, you
    presumably want the ciphertext to be encoded as printing characters,
    while normally you'd treat the input as binary, so there is some
    further expansion.
    Paul Rubin, Feb 11, 2008
    #4
  5. erikcw

    Guest

    erikcw napisal(a):
    > But that can't be reversed, right? I'd like to be able to decrypt the
    > data instead of having to store the hash in my database...

    In such case it seems you have no choice but to use a symmetric
    encryption algorithm - in other words, your original method. If the
    strings are ~20 bytes long (3 DES blocks), then the base64-encoded
    ciphertext will have 32 characters. In case of AES, that'll be up to
    45 characters. Wouldn't such length be acceptable?

    Paul Rubin napisal(a):
    > 2. What happens if the user edits the subject line?
    > Under normal security requirements you cannot do this. The ciphertext
    > has to be longer than the plaintext since you don't want the opponent
    > to be able to tell whether two plaintexts are the same. Therefore you
    > have to attach some random padding to each plaintext. Also, you
    > presumably want the ciphertext to be encoded as printing characters,
    > while normally you'd treat the input as binary, so there is some
    > further expansion.

    If what erikcw is looking for is a cryptographically secure protocol,
    there are more things to be careful about, like authentication or
    replay attacks. But indeed, I'm wondering now what his use-case is.
    > I'm using this encrypted string to identify emails from a
    > user. (the string will be in the subject line of the email).

    Why not use "From" field to identify emails from a particular user?

    Regards,
    Marek
    , Feb 11, 2008
    #5
  6. erikcw

    erikcw Guest

    On Feb 11, 4:07 pm, wrote:
    > erikcw napisal(a):> But that can't be reversed, right? I'd like to be able to decrypt the
    > > data instead of having to store the hash in my database...

    >
    > In such case it seems you have no choice but to use a symmetric
    > encryption algorithm - in other words, your original method. If the
    > strings are ~20 bytes long (3 DES blocks), then the base64-encoded
    > ciphertext will have 32 characters. In case of AES, that'll be up to
    > 45 characters. Wouldn't such length be acceptable?
    >
    > Paul Rubin napisal(a):> 2. What happens if the user edits the subject line?
    > > Under normal security requirements you cannot do this. The ciphertext
    > > has to be longer than the plaintext since you don't want the opponent
    > > to be able to tell whether two plaintexts are the same. Therefore you
    > > have to attach some random padding to each plaintext. Also, you
    > > presumably want the ciphertext to be encoded as printing characters,
    > > while normally you'd treat the input as binary, so there is some
    > > further expansion.

    >
    > If what erikcw is looking for is a cryptographically secure protocol,
    > there are more things to be careful about, like authentication or
    > replay attacks. But indeed, I'm wondering now what his use-case is.> I'm using this encrypted string to identify emails from a
    > > user. (the string will be in the subject line of the email).

    >
    > Why not use "From" field to identify emails from a particular user?
    >
    > Regards,
    > Marek


    In essence what I'm doing is trying to manage tickets for a helpdesk.
    I want the ticket identifier to be short enough to fit in the subject
    line along with the normal subject chosen by the user. So
    cryptographic security isn't really important. I can't use the from:
    field because a single user could have multiple tickets.
    erikcw, Feb 11, 2008
    #6
  7. Hi,

    On 2/11/08, erikcw <> wrote:
    > In essence what I'm doing is trying to manage tickets for a helpdesk.
    > I want the ticket identifier to be short enough to fit in the subject
    > line along with the normal subject chosen by the user. So
    > cryptographic security isn't really important. I can't use the from:
    > field because a single user could have multiple tickets.


    I've always wondered why such systems don't use the Message-ID or
    Reference headers - I know they aren't preserved by all mailers but I
    think that having this info in the subject line is

    a) visually disturbing (subjective)
    b) I guess that the risk of a user modifying the subject line is the
    same than finding a programm that doesn't to some extent honor the
    headers i mentioned...
    <flame>
    c) Personally whenever I find a mail that says please keep this in the
    subject I delete that number on purpose...
    </flame>

    martin
    --
    http://noneisyours.marcher.name
    https://twitter.com/MartinMarcher
    http://www.xing.com/profile/Martin_Marcher
    http://www.linkedin.com/in/martinmarcher

    You are not free to read this message,
    by doing so, you have violated my licence
    and are required to urinate publicly. Thank you.
    Martin Marcher, Feb 11, 2008
    #7
  8. En Mon, 11 Feb 2008 19:19:00 -0200, erikcw <>
    escribió:

    > In essence what I'm doing is trying to manage tickets for a helpdesk.
    > I want the ticket identifier to be short enough to fit in the subject
    > line along with the normal subject chosen by the user. So
    > cryptographic security isn't really important. I can't use the from:
    > field because a single user could have multiple tickets.


    And you don't like [bug12345] or even [12345]? To the user, it's a lot
    clear its purpose, and anybody will understand what you mean if you say
    "Please maintain the bug number in the subject line" or similar.

    --
    Gabriel Genellina
    Gabriel Genellina, Feb 11, 2008
    #8
  9. erikcw

    Carl Banks Guest

    On Feb 11, 4:19 pm, erikcw <> wrote:
    > On Feb 11, 4:07 pm, wrote:
    > > erikcw napisal(a):> But that can't be reversed, right? I'd like to be able to decrypt the
    > > > data instead of having to store the hash in my database...

    >
    > > In such case it seems you have no choice but to use a symmetric
    > > encryption algorithm - in other words, your original method. If the
    > > strings are ~20 bytes long (3 DES blocks), then the base64-encoded
    > > ciphertext will have 32 characters. In case of AES, that'll be up to
    > > 45 characters. Wouldn't such length be acceptable?

    >
    > > Paul Rubin napisal(a):> 2. What happens if the user edits the subject line?
    > > > Under normal security requirements you cannot do this. The ciphertext
    > > > has to be longer than the plaintext since you don't want the opponent
    > > > to be able to tell whether two plaintexts are the same. Therefore you
    > > > have to attach some random padding to each plaintext. Also, you
    > > > presumably want the ciphertext to be encoded as printing characters,
    > > > while normally you'd treat the input as binary, so there is some
    > > > further expansion.

    >
    > > If what erikcw is looking for is a cryptographically secure protocol,
    > > there are more things to be careful about, like authentication or
    > > replay attacks. But indeed, I'm wondering now what his use-case is.> I'm using this encrypted string to identify emails from a
    > > > user. (the string will be in the subject line of the email).

    >
    > > Why not use "From" field to identify emails from a particular user?

    >
    > > Regards,
    > > Marek

    >
    > In essence what I'm doing is trying to manage tickets for a helpdesk.
    > I want the ticket identifier to be short enough to fit in the subject
    > line along with the normal subject chosen by the user. So
    > cryptographic security isn't really important. I can't use the from:
    > field because a single user could have multiple tickets.


    Shouldn't you have a database associating a ticket ID with an email
    address (among other things)?


    Carl Banks
    Carl Banks, Feb 11, 2008
    #9
  10. erikcw

    Paul Rubin Guest

    erikcw <> writes:
    > In essence what I'm doing is trying to manage tickets for a helpdesk.
    > I want the ticket identifier to be short enough to fit in the subject
    > line along with the normal subject chosen by the user.


    I think you should use a database to maintain the email addresses
    since you already have to maintain the contents and history of the
    help ticket anyway. If the contents of the database is private, then
    assign the ticket numbers in an unpredictable sequence--I can tell you
    how to do that cryptographically if you want (I've posted code for it
    a few times before). That is to stop users from guessing ticket
    numbers that are valid but belong to other users. If it's a public
    database (e.g. a bug tracker for a free software project) or if
    accessing a particular ticket needs a user credential associated with
    that ticket, then you may as well use sequential numbers.
    Paul Rubin, Feb 11, 2008
    #10
  11. erikcw

    Lie Guest

    On Feb 12, 2:45 am, erikcw <> wrote:
    > Hi,
    >
    > I'm trying to devise a scheme to encrypt/obfuscate a short string that
    > basically contains the user's username and record number from the
    > database.  I'm using this encrypted string to identify emails from a
    > user. (the string will be in the subject line of the email).
    >
    > I'm trying to figure out which approach I should use to encrypt the
    > data.  The string will be less than 20 characters long, and I'd like
    > the encrypted version to be about the same size.
    >
    > I tried DES in the Crypto module, but the cipher text was to long to
    > be usable in this case.
    >
    > Any suggestions?
    >
    > Thanks!


    There is a simple encryption, called ROT13 (Rotate 13). This is very
    unsecure for any cryptographical purpose, but enough to make
    uninformed user to think it's just a random piece of letters.

    The ROT13 is done by adding 13 to each character, so
    A => N,
    B => O,
    C => P,
    D => Q, etc

    the neat trick to this encryption is the algorithm is really simple
    and you don't need a separate decoding algorithm as text ==
    ROT13(ROT13(text)). This algorithm also guarantees that any two
    different text would have two different ciphertext
    Lie, Feb 16, 2008
    #11
  12. Lie wrote:

    > There is a simple encryption, called ROT13 (Rotate 13). This is
    > very unsecure for any cryptographical purpose,


    For enhanced security use TROT13 (triple ROT13).

    > but enough to make uninformed user to think it's just a random
    > piece of letters.


    Security by obscurity doesn't work. If it needs to be protected,
    protect it well. If it doesn't need to, you don't need to obscure
    it at all.

    Regards,


    Björn

    --
    BOFH excuse #372:

    Forced to support NT servers; sysadmins quit.
    Bjoern Schliessmann, Feb 16, 2008
    #12
  13. erikcw

    Brian Guest

    Hi Erik,

    I really don't recommend the ROT13 cipher, as this is extremely easy to
    crack. Most grade school kids could break this one in seconds. ;-)

    If the project that you are working upon has low security needs, (in
    other words, it's not a financial institution), than you might try
    something quite basic such as a Vigenere, transposition, or even a
    playfair. These encryption methodologies are not secure and can be
    cracked by hackers. Yet, for the average Joe, it will keep them away
    from the information / data stored inside.

    One thing that seems to work well is to use to ciphers together. For
    example, encrypt the data using the playfair cipher -- and then run a
    transposition cipher. This will erase most of the "data signatures"
    that are needed for most hackers to crack the code. At this point,
    brute force is what most people have to resort upon -- and it's mostly
    "governments" that have this ability. ;-)

    Best wishes!

    Dusty
    ---


    Bjoern Schliessmann wrote:
    > Lie wrote:
    >
    >> There is a simple encryption, called ROT13 (Rotate 13). This is
    >> very unsecure for any cryptographical purpose,

    >
    > For enhanced security use TROT13 (triple ROT13).
    >
    >> but enough to make uninformed user to think it's just a random
    >> piece of letters.

    >
    > Security by obscurity doesn't work. If it needs to be protected,
    > protect it well. If it doesn't need to, you don't need to obscure
    > it at all.
    >
    > Regards,
    >
    >
    > Björn
    >
    Brian, Feb 19, 2008
    #13
  14. On Tue, 19 Feb 2008 09:25:52 -0700, Brian wrote:

    > Hi Erik,
    >
    > I really don't recommend the ROT13 cipher, as this is extremely easy to
    > crack. Most grade school kids could break this one in seconds. ;-)



    I think you missed the point. Any recommendation to use ROT13 is likely
    to be a joke. A recommendation to use Triple ROT13 is *absolutely* a joke.


    > If the project that you are working upon has low security needs, (in
    > other words, it's not a financial institution),


    That's rubbish. Do you think that banks are the only companies that care
    about the security of their data? How would you feel if your doctor
    accidentally published your medical records onto the Internet, so
    everybody can see the embarrassing social diseases you've got?

    (Disclaimer: I don't have any reason to think Brian actually has any
    embarrassing social diseases, or any other diseases for that matter. I
    was just making a rhetorical point.)


    > than you might try
    > something quite basic such as a Vigenere, transposition, or even a
    > playfair. These encryption methodologies are not secure and can be
    > cracked by hackers. Yet, for the average Joe, it will keep them away
    > from the information / data stored inside.


    It's an awful lot of work to do those when it is so simple to call an
    already existing library that is much stronger. Why do a lot of work to
    get an insecure result, when you can do a little bit of work to get a
    secure result?

    I don't recommend any of these obsolete ciphers except as a learning
    exercise, or possibly as a challenge: e.g. you *want* people to crack the
    cipher, but you don't want it too easy for them.


    > One thing that seems to work well is to use to ciphers together. For
    > example, encrypt the data using the playfair cipher -- and then run a
    > transposition cipher. This will erase most of the "data signatures"
    > that are needed for most hackers to crack the code. At this point,
    > brute force is what most people have to resort upon -- and it's mostly
    > "governments" that have this ability. ;-)


    That's absolute rubbish.

    (1) There are well-understood techniques for breaking all these ciphers,
    individually or in combination. Often, putting two of them together
    doesn't make the encryption any harder to break than just using one of
    them.

    (2) It's not just "governments" who can break ciphers by brute force.
    Anyone can do it. I could probably write a Python function to crack any
    Caesar cipher in a few minutes, and it would probably run in seconds or
    minutes. More complex ciphers need more work, but it's certainly
    feasible: dictionary attacks are simple. Brute force only becomes
    infeasible when the key is long enough. To brute force a short enough key
    is within the grasp of *pencil and paper*, if you care enough.



    --
    Steven
    Steven D'Aprano, Feb 19, 2008
    #14
  15. erikcw

    David H Wild Guest

    In article <>,
    Steven D'Aprano <> wrote:
    > > I really don't recommend the ROT13 cipher, as this is extremely easy to
    > > crack. Most grade school kids could break this one in seconds. ;-)



    > I think you missed the point. Any recommendation to use ROT13 is likely
    > to be a joke. A recommendation to use Triple ROT13 is *absolutely* a
    > joke.


    ROT13 does have a legitimate use, but it's not as a cypher. It is really
    the equivalent of the newspaper quiz where the answers are upside down at
    the bottom of the page. By doing this you stop seeing the answers too
    early.

    --
    David Wild using RISC OS on broadband
    www.davidhwild.me.uk
    David H Wild, Feb 19, 2008
    #15
  16. erikcw

    Steve Holden Guest

    David H Wild wrote:
    > In article <>,
    > Steven D'Aprano <> wrote:
    >>> I really don't recommend the ROT13 cipher, as this is extremely easy to
    >>> crack. Most grade school kids could break this one in seconds. ;-)

    >
    >
    >> I think you missed the point. Any recommendation to use ROT13 is likely
    >> to be a joke. A recommendation to use Triple ROT13 is *absolutely* a
    >> joke.

    >
    > ROT13 does have a legitimate use, but it's not as a cypher. It is really
    > the equivalent of the newspaper quiz where the answers are upside down at
    > the bottom of the page. By doing this you stop seeing the answers too
    > early.
    >

    Of course, but ROT13 ^ (2n*1) is equivalent to ROT13 for all positive
    integer n. Hence the confident assertion that "A recommendation to use
    Triple ROT13 is *absolutely* a joke".

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
    Steve Holden, Feb 20, 2008
    #16
  17. erikcw

    Roy Smith Guest

    In article <>,
    Steve Holden <> wrote:

    > Of course, but ROT13 ^ (2n*1) is equivalent to ROT13 for all positive
    > integer n.


    Why restrict that to positive integers? I believe it works for all
    integers. But I do think you meant 2n+1, not 2n*1.
    Roy Smith, Feb 20, 2008
    #17
  18. erikcw

    Steve Holden Guest

    Roy Smith wrote:
    > In article <>,
    > Steve Holden <> wrote:
    >
    >> Of course, but ROT13 ^ (2n*1) is equivalent to ROT13 for all positive
    >> integer n.

    >
    > Why restrict that to positive integers? I believe it works for all
    > integers. But I do think you meant 2n+1, not 2n*1.


    Yes, I did. "*" and "+" are much closer in my mind than they are on the
    keyboard :)

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
    Steve Holden, Feb 20, 2008
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Onur Bozkurt

    encrypting query string

    Onur Bozkurt, Jul 23, 2003, in forum: ASP .Net
    Replies:
    8
    Views:
    584
    Munsifali Rashid
    Jul 24, 2003
  2. David Geering

    longs, long longs, short short long ints . . . huh?!

    David Geering, Jan 8, 2007, in forum: C Programming
    Replies:
    15
    Views:
    544
    Keith Thompson
    Jan 11, 2007
  3. Replies:
    4
    Views:
    798
    Kaz Kylheku
    Oct 17, 2006
  4. Ioannis Vranos

    unsigned short, short literals

    Ioannis Vranos, Mar 4, 2008, in forum: C Programming
    Replies:
    5
    Views:
    657
    Eric Sosman
    Mar 5, 2008
  5. Andre
    Replies:
    5
    Views:
    517
    Keith Thompson
    Jul 17, 2012
Loading...

Share This Page