get hexadecimal hash string for a number

M

Magnus Warker

What is your database key?

If it's 1, 2, 3, 4, ... then encrypting it will simply reveal your
encryption key.

It's an incrementing integer. What's the reason for revealing the key?
Is it the shortness of the number or is it the fact, that the number
increments?

If it's the shortness, what about padding?
If characters aren't efficient for your keys, simply use
a translation table between the random and sequential values. Use the
randomized value as a database key on all traffic leaving and entering
your server. It prevents the public from guessing new database keys.

create table urlparams
{
param char(16) primary key,
id integer unique not null references main_table (id)
}
-- param is the outside database key made of random characters
-- id is the local primary key

Ok thanks...

Magnus
 
M

markspace

Could you please explain this? I haven't used encryption in Java, but I
would expect that the encryption method should be independend of the
size of the data to encrypt?


It's really too complicated to do here. C.f.:

<http://www.wrox.com/WileyCDA/WroxTitle/Beginning-Cryptography-with-Java.productCd-0764596330.html>


That is a really good book on using the crypto package in Java for
anyone, beginner or advanced, btw. Two thumbs up from me. If you are
100% conversant with Java's cryptography, get that book, it will teach
you something.
 
A

Arne Vajhøj

What about Kevin's posting? He noted that encrypting sequential numbers
would reveal the encryption key?

That type of attack is called a known plaintext attack. The most
common symmetric encryption algorithm AES should not be vulnerable
to that.

But as previous stated then I only consider that second best solution.
Could you please explain this? I haven't used encryption in Java, but I
would expect that the encryption method should be independend of the
size of the data to encrypt?

DES operates on 8 byte blocks and AES on 16 byte blocks.

For data that is not a multipla of that padding is required.

But I would suggest AES and padding.
Well, I would simply choose the size of SQL standard integer (64)...

In many databases INTEGER is only 32 bit.

64 bit is called BIGINT or something similar.

Arne
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top