Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Encrypting a short string?

Reply
Thread Tools

Encrypting a short string?

 
 
erikcw
Guest
Posts: n/a
 
      02-11-2008
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!
 
Reply With Quote
 
 
 
 
marek.rocki@wp.pl
Guest
Posts: n/a
 
      02-11-2008
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 Removed)|2937267834" ).hexdigest()[:20]


Regards,
Marek
 
Reply With Quote
 
 
 
 
erikcw
Guest
Posts: n/a
 
      02-11-2008
On Feb 11, 3:07 pm, (E-Mail Removed) 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 Removed)|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...
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      02-11-2008
erikcw <(E-Mail Removed)> 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.
 
Reply With Quote
 
marek.rocki@wp.pl
Guest
Posts: n/a
 
      02-11-2008
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
 
Reply With Quote
 
erikcw
Guest
Posts: n/a
 
      02-11-2008
On Feb 11, 4:07 pm, (E-Mail Removed) 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.
 
Reply With Quote
 
Martin Marcher
Guest
Posts: n/a
 
      02-11-2008
Hi,

On 2/11/08, erikcw <(E-Mail Removed)> 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.
 
Reply With Quote
 
Gabriel Genellina
Guest
Posts: n/a
 
      02-11-2008
En Mon, 11 Feb 2008 19:19:00 -0200, erikcw <(E-Mail Removed)>
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

 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      02-11-2008
On Feb 11, 4:19 pm, erikcw <(E-Mail Removed)> wrote:
> On Feb 11, 4:07 pm, (E-Mail Removed) 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
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      02-11-2008
erikcw <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Difference of extern short *x and extern short x[]? Andre C Programming 5 07-17-2012 07:38 PM
unsigned short, short literals Ioannis Vranos C Programming 5 03-05-2008 01:25 AM
longs, long longs, short short long ints . . . huh?! David Geering C Programming 15 01-11-2007 09:39 PM
unsigned short short? slougheed@gmail.com C++ 4 10-16-2006 11:25 PM
Wireless Network Encrypting + Problems =?Utf-8?B?Sm9lbC1ERA==?= Wireless Networking 2 08-12-2005 05:44 PM



Advertisments