Encrypting a short string?

[erikcw]

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!

[marek.rocki]

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("jo********@example.com|293726783 4").hexdigest()[:20]

Regards,
Marek

[erikcw]

On Feb 11, 3:07 pm, [e-mail] 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("[e-mail]|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...

[Paul Rubin]

erikcw <er***********@gmail.comwrites:

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.

[marek.rocki]

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

[erikcw]

On Feb 11, 4:07 pm, [e-mail] 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.

[Martin Marcher]

Hi,

On 2/11/08, erikcw <er***********@gmail.comwrote:

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.

[Gabriel Genellina]

En Mon, 11 Feb 2008 19:19:00 -0200, erikcw <er***********@gmail.com>
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

[Lie]

On Feb 12, 2:45*am, erikcw <[e-mail]:

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

[Bjoern Schliessmann]

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.

[David H Wild]

In article <13*************@corp.supernews.com>,
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrote:

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

[Roy Smith]

In article <ma*************************************@python.or g>,
Steve Holden <st***@holdenweb.comwrote:

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.

[Steve Holden]

Roy Smith wrote:

In article <ma*************************************@python.or g>,
Steve Holden <st***@holdenweb.comwrote:

>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 [phone] [phone]
Holden Web LLC http://www.holdenweb.com/