Encryption / Description Alphanumeric 16 digits |
[eluser]henlee[/eluser]
Hi, I hope somebody can help me out with something. I need an encryption method/function to generate a 16 digit alpha numeric character string which I'm able to decrypt later on. Only conditions is that if I change one number in the encrypted string the decrypting should fail. Idea's, examples anyone?
[eluser]stef25[/eluser]
From Stackoverflow Code: $key = 'password to (en/de)crypt';
[eluser]WanWizard[/eluser]
That doesn't give you a 16-digit alpha numeric string. The result (length) of any encryption routine depends on the input. As per the manual (encrypt library), expect the result to be more than 2.5 times the input length. Any reason for the 16-char restriction? What are you trying to accomplish? In general, you should try to avoid using encryption, as it is expensive, and often doesn't add anything. Most of the time you can use a hash combined with a database lookup.
[eluser]henlee[/eluser]
I'm trying to encrypt id's so I can create url's like www.mydomain.com/5874658745213549 when 5874658745213549 is decrypted it should contain $a_id = 100; $b_id = 256; $c_id = 351; I don't mind serializing a array or simply encrypt a string like '100:256:351'
[eluser]WanWizard[/eluser]
Isn't it easier to genarate a hash, and store the rest in the database? Like p.e. the search option on this forum does? Anyway, you can't limit the result of the encryption to a fixed length string, it is always going to depend on the input length. A hash always has a fixed length. You could even decide to use only the first 16 characters of a hash, but than you will have to do some collision detection. Otherwise, just use the encrypt library's encode/decode methods (see the docs).
[eluser]henlee[/eluser]
thing is, I really want to do it without a lookup (db or xml) and I'm limited to numbers only
[eluser]stef25[/eluser]
You say "you can’t limit the result of the encryption to a fixed length string". Isn't that contradictory to "A hash always has a fixed length". I agree with the method you propose. It's still an interesting question though. What I'd do is what you say, to use the first X characters of the hash with collision detection. The chance that this ads more than one or two queries to your app is pretty low.
[eluser]WanWizard[/eluser]
Hashing != Encryption. Altough you could say that the encoding bit is similar, hashes can not be decoded. Hashes are used in lookup tables, and therefore you have to deal with duplicates. Depending on the hash algorithm and entropy of the input, collisions are more or less likely. If you then shorten the hash, you increase the chance of collisions. If you encode, you don't have to do a lookup, so duplicates are not an issue. The only point I was trying to make is that encoding/decoding is pretty expensive (CPU and depending on the algorithm also memory), so from a performance point of view you want to avoid encryption if possible.
[eluser]henlee[/eluser]
Which will be faster in general, decoding or look it up in a database (hash)? (I'm not that familiar with PHP)
[eluser]WanWizard[/eluser]
Depends on your environment, so you'll have to test that. It also depends on the number of encode/decode cycles you have to do. If I look at the xdebug profiler output (with cachegrind) of a typical CI request, I see that most of the processing time of the request is spend encrypting and decrypting the session cookie. Much more than the CI profiler tells me a simple query takes. |
Welcome Guest, Not a member yet? Register Sign In |