Asymmetric algorithms require the creation of a public key and a private key. The public key can be made public to anyone, while the private key must known only by the party who will decrypt the data encrypted with the public key. This section describes how to generate and manage keys for both symmetric and asymmetric algorithms. Symmetric Keys.
Ranch Hand
posted 10 years agoIn Java, how can a create a Unique ID from a particular string?
I have gone through the UUID class but could not find anything, also googled this but to find nothing.
Can any one please Help me on this?
I have gone through the UUID class but could not find anything, also googled this but to find nothing.
Can any one please Help me on this?
Ranch Hand
posted 10 years agoTry permutation and combination of a string element appended with some Randomized generated string/number.
[LEARNING bLOG] | [Freelance Web Designer] | [and 'Rohan' is part of my surname]
Ranch Hand
posted 10 years ago Try permutation and combination of a string element appended with some Randomized generated string/number.
I think this doesn't work, because, the next time when i want to generate the Unique ID for the same string then this randomized generation doesn't work as the same Unique id doesn't get generated.
Here one more thing is the length of the generated Unique ID must be less than the original String.
Author
posted 10 years agoSounds like you want a guaranteed hash code for a string, that's guaranteed to be 'shorter' than the string. Not sure how possible that will be--what is the reason for this requirement?
Marshal
posted 10 years agoToo difficult a question for us beginners. Moving.
Ranch Hand
posted 10 years agoIn Java 1.5, static UUID UUID.fromString(String name);
As mentioned previously, what about the hashcode converted into a String?
Integer.toString( myString.hashcode() );
As mentioned previously, what about the hashcode converted into a String?
Integer.toString( myString.hashcode() );
Ranch Hand
posted 10 years ago In Java 1.5, static UUID UUID.fromString(String name);
Here fromString creates a UUID for a valid UUID string and not any string.
Ranch Hand
posted 10 years agoThe String class may not have a hashCode() method, but Object does, and String is a subclass of Object. The same goes for Integer class and toString().
D'oh, previous post was edited. I'm still leaving my post up though.
D'oh, previous post was edited. I'm still leaving my post up though.
SCJA
When I die, I want people to look at me and say 'Yeah, he might have been crazy, but that was one zarkin frood that knew where his towel was.'
When I die, I want people to look at me and say 'Yeah, he might have been crazy, but that was one zarkin frood that knew where his towel was.'
Marshal
posted 10 years agoBharadwaj Adepu wrote:Here one more thing is the length of the generated Unique ID must be less than the original String.
So how should this work for the empty string? (There are no strings with length less than zero.)
And how should it work for strings of one character? (All strings of length zero are the same, so you can't have a unique representation.)
Ranch Hand
posted 10 years ago Integer class doesn't have toString(java.lang.String) Method and String class doesn't have any hashcode() method.
From java.lang.Integer: public static String toString(int i)
A simple method name typo. java.lang.String: public int hashCode()
But this doesn't meet your later criteria of unique ID length less then String length. It would seem that you need to write your own mapping function.
Ranch Hand
posted 10 years ago So how should this work for the empty string? (There are no strings with length less than zero.)
Here in my usage/application, i'll not create the Unique id for empty strings.
Here actually what i want to do is, insert the generated unique id in the database, so if length of my string is more than 4000 and if generated unique string will have the length same as the original string(larger than 4000) then i cant insert that.
Ranch Hand
posted 10 years ago @Fred Integer.toString( myString.hashCode() );
I think this serves my purpose, i have tested this and the hashCode generated is an number of around 10 to 12 digits, some times negative.
Thanks a LOT
But am not sure if this method creates a same hashCode for same string, i have tested this but not sure...
Author
posted 10 years agoBharadwaj Adepu wrote:But am not sure if this method creates a same hashCode for same string, i have tested this but not sure...
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#hashCode()
AFAIK it's not guaranteed to be unique.
Ranch Hand
posted 10 years agoBharadwaj Adepu wrote:
But am not sure if this method creates a same hashCode for same string, i have tested this but not sure...
But am not sure if this method creates a same hashCode for same string, i have tested this but not sure...
If you read the contract of the hashCode method, it states:
http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode() wrote: Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
This means that it will not necessarily produce the same hash code for the same object between runs of your JVM. Also, you stated you need a Unique ID for each String. Again, reading the hashCode contract, we learn:
http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode() wrote: It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results.
So there is no guarantee that you will get a unique ID for two different Strings. Although the odds are low, there is a possibility you might get the same ID for two different Strings. The documentation for the String's overriding of the hashCode method does not give any indication that these warnings do not apply to its implementation. (I have not studied the String class's implementation to know either way.) Common sense would indicate that given that you are dealing with Strings of 4000 characters (8000 bytes) and bigger that you can not uniquely represent all possible permutations in only 4 bytes (the size of an int).
It sounds to me what you want is a compression method/process and not necessarily a 'unique ID'. You want to be able to store Strings over 4000 characters in less space, and always want the same result for the same string. Do you need the ability to reverse for this 'ID' to the original String? Or just get the same ID so you can look up related data in the database? I would suggest you look into compression methods and APIs.
Ranch Hand
posted 10 years agop.s. Of course another option might be to change your database field's data type to a CLOB rather than a VARCHAR(4000). It would probably be much easier and more reliable in the long run.
best scout
posted 10 years agoHi Bharadwaj,
I think what you need is a hash function. In general any kind of hash is a surjective projection (hope this is the correct mathematical name for it in English) which in your case means you're trying to map a given string consisting of a (large) number of characters to some kind of value which consists of a much smaller number of characters or bytes. This simply can't be done without collisions! Maybe you can reduce the size of the original string to some degree without loss with a compression function. But I guess it won't be possible to compress 4000 characters to 4 bytes without some information loss :-)
So obviously the only way to go is to use a hash function and even if it theoretically may sound like a problem to have collisions it's often not a problem in reality. In fact there may be collisions which will map different strings to the same hash code. The only question is how likely it is for a collision to happen! A good cryptographic hash function should really make it very unlikely to get collisions.
Of course you have to decide what 'good enough' means regarding your requirements!
Marco
I think what you need is a hash function. In general any kind of hash is a surjective projection (hope this is the correct mathematical name for it in English) which in your case means you're trying to map a given string consisting of a (large) number of characters to some kind of value which consists of a much smaller number of characters or bytes. This simply can't be done without collisions! Maybe you can reduce the size of the original string to some degree without loss with a compression function. But I guess it won't be possible to compress 4000 characters to 4 bytes without some information loss :-)
So obviously the only way to go is to use a hash function and even if it theoretically may sound like a problem to have collisions it's often not a problem in reality. In fact there may be collisions which will map different strings to the same hash code. The only question is how likely it is for a collision to happen! A good cryptographic hash function should really make it very unlikely to get collisions.
Of course you have to decide what 'good enough' means regarding your requirements!
Marco
Ranch Hand
posted 10 years agoBharadwaj Adepu wrote:
Try permutation and combination of a string element appended with some Randomized generated string/number.
I think this doesn't work, because, the next time when i want to generate the Unique ID for the same string then this randomized generation doesn't work as the same Unique id doesn't get generated.
Generate String Of Length
of course, it will work if you append/prepend/insert the random generated integer. And for the same string, I don't think the random generated number is same.
Bharadwaj Adepu wrote:
Here one more thing is the length of the generated Unique ID must be less than the original String.
Here one more thing is the length of the generated Unique ID must be less than the original String.
With permutations you can restrict the length of resulted string.
[LEARNING bLOG] | [Freelance Web Designer] | [and 'Rohan' is part of my surname]
Hi Barun Parichha,
This is not my field of expertise but I may be able to help?
I assume that you are looking for a 16-digit (not 16 byte) hex number in 4x2 byte decimated hex notation to denote a unique number? I also assume that this unique number MUST be unique from all other numbers generated? Something like a serial number generator, but in 4x2 hex decimated notation.
Your idea of using a random number generator, seeded by current time, although innovative, I don't believe will guarantee you a unique number, with respect to numbers previously generated.
Your second suggestion would be the method that I would consider, especially if you have the flexibility of 8 bytes (16 hex digits) to play with. Providing the unique number is only ever generated on a single system where you can guarantee that the clock will always be accurate in terms of ‘real world’ time, timezone and daylight savings etc, this should guarantee you a unique number. Before I go further, 2 explanations are required:
1. Single system: If you have multiple systems generating a number based purely on time, there is always the chance that both systems may generate the same number. If you are using multiple systems, you will need to consider this and perhaps incorporate a unique feature of each system into the number generation equation, such as MAC address etc.
2. Real world time: Should the system generating this unique number, based on time, not be accurate with its time keeping, there is the risk of producing duplicate numbers. Also be aware of daylight savings and its time transitions!
Assuming a single system with good clock keeping skills, no daylight saving, single timezone and delays of at least 10 seconds, to get a simple 4 bytes of 'unique' hex output, my approach might be:
#include <stdio.h>
#include <ctype.h>
#include <sys/time.h>
void stoupper (char *src) {
// Convert chars in string to upper case
while (*src != '0')
*(src++) = toupper (*src);
}
int main (int argc, char *argv[]) {
struct timeval tv;
struct timezone tz;
char seq[6];
union {
unsigned int t;
unsigned char ct[4];
} u;
gettimeofday (&tv,&tz);
u.t=(unsigned int)tv.tv_sec;
// Number of seconds since the Epoch – 1 Jan 1970 00:00:00
// Write time as 2x4 byte hex values
// Include byte-reversal for Intel architecture
sprintf (seq,'%02x%02x.%02x%02x',(unsigned char)u.ct[3],(unsigned char)u.ct[2],(unsigned char)u.ct[1],(unsigned char)u.ct[0]);
// Convert the hex values to upper case
stoupper (seq);
printf ('8bit hex time = (%s)n',seq);
return (0);
}
You still have 4 bytes to use if you wish to incorporate multiple systems, time issues etc.
I hope that helps,
BitBuster.
This is not my field of expertise but I may be able to help?
I assume that you are looking for a 16-digit (not 16 byte) hex number in 4x2 byte decimated hex notation to denote a unique number? I also assume that this unique number MUST be unique from all other numbers generated? Something like a serial number generator, but in 4x2 hex decimated notation.
Your idea of using a random number generator, seeded by current time, although innovative, I don't believe will guarantee you a unique number, with respect to numbers previously generated.
Your second suggestion would be the method that I would consider, especially if you have the flexibility of 8 bytes (16 hex digits) to play with. Providing the unique number is only ever generated on a single system where you can guarantee that the clock will always be accurate in terms of ‘real world’ time, timezone and daylight savings etc, this should guarantee you a unique number. Before I go further, 2 explanations are required:
1. Single system: If you have multiple systems generating a number based purely on time, there is always the chance that both systems may generate the same number. If you are using multiple systems, you will need to consider this and perhaps incorporate a unique feature of each system into the number generation equation, such as MAC address etc.
2. Real world time: Should the system generating this unique number, based on time, not be accurate with its time keeping, there is the risk of producing duplicate numbers. Also be aware of daylight savings and its time transitions!
Assuming a single system with good clock keeping skills, no daylight saving, single timezone and delays of at least 10 seconds, to get a simple 4 bytes of 'unique' hex output, my approach might be:
#include <stdio.h>
#include <ctype.h>
#include <sys/time.h>
void stoupper (char *src) {
// Convert chars in string to upper case
while (*src != '0')
*(src++) = toupper (*src);
}
int main (int argc, char *argv[]) {
struct timeval tv;
struct timezone tz;
char seq[6];
union {
unsigned int t;
unsigned char ct[4];
} u;
gettimeofday (&tv,&tz);
u.t=(unsigned int)tv.tv_sec;
// Number of seconds since the Epoch – 1 Jan 1970 00:00:00
// Write time as 2x4 byte hex values
// Include byte-reversal for Intel architecture
sprintf (seq,'%02x%02x.%02x%02x',(unsigned char)u.ct[3],(unsigned char)u.ct[2],(unsigned char)u.ct[1],(unsigned char)u.ct[0]);
// Convert the hex values to upper case
stoupper (seq);
printf ('8bit hex time = (%s)n',seq);
return (0);
}
You still have 4 bytes to use if you wish to incorporate multiple systems, time issues etc.
I hope that helps,
BitBuster.