encryption with python

[Paul Rubin]

James Stroud <jstroud at mbi.ucla.edu> writes:
> Yes and no. Yes, you are theoretically correct. No, I don't think
> you have the OP's original needs in mind (though I am mostly
> guessing here).  The OP was obviously a TA who needed to assign
> students a number so that they could "anonymously" check their
> publicly posted grades and also so that he could do some internal
> record keeping.

If that's all it's about, it's not a big deal.  If it's for some central
administrative database that's more of a target, more care is warranted.

> The idea of combining ID information and encrypting it to create

The info to be combined was the student's birthdate.  Why would the TA
have access to either that or the SSN?

> import sha
> def encrypt(x,y, password):
>     def _dosha(v): return sha.new(str(v)+str(password)).hexdigest()
>     return int(_dosha(_dosha(x)+_dosha(y))[5:13],16)
> 
> So now what is the criticism? That its still a "secret algorithm"
> because the password is "secret"?

That's sort of reasonable as long as the password really is secret and
you don't mind a small chance of two students getting the same ID
number once in a while.  If the password is something that a TA types
into a laptop when entering grades and which goes away after the
course ends, it's not such a big deal.  If it's a long-term key that
has to stay resident in a 24/7 server through the students' entire
time at the university and beyond, then the algorithm is the trivial
part and keeping the key secret is a specialized problem in its own
right.  For example, financial institutions use special, tamper
resistant hardware modules for the purpose.

Could the OP please say what the exact application is?  That might get
more useful responses if the question still matters.