This question already has answers here:
YouTube-like GUID
(9 answers)
Closed 7 years ago.
Is it possible to the Hash or digest of a GUID so it is shorter in length while maintaining it's uniqueness?
No. A GUID needs all 128 bits to be globally unique. The bits describe the time, location, and uniqueness identifier (an incrementing key used to prevent the same GUID from being generated if the clock hasn't moved or has been artificially manipulated).
If you have some requirement short of global uniqueness, then yes, you can create locally unique identifiers that are less than 128 bits. There are likely better ways to do this than generating a 128 bit GUID and then coming up with some kind of awesome hashing algorithm that maintains pretty good uniqueness at less than 128 bits.
Related
This question already has answers here:
What is the maximum possible length of a .NET string?
(8 answers)
Closed 4 years ago.
I know in C# you can do int.MaxValue or long.MaxValue to get the maximum for these two types, I was wondering if there are similar ways to get the maximum length for the string.
I don't see it here.
Also, I am aware that there are already questions being asked on max string length. Max string length in C#
I am asking if there is an existing function that comes in handy where you can use it to set the condition when and when not to truncate your string to avoid program crashing.
Or what is the normal approach?
E.g. Maybe something as easy as Max(string.length)?
No. In the same way that there is no known method to find the max length of an array you can allocate. Until you try to allocate the memory, you can't know if there is enough virtual address space and enough physical memory to contain it. Theorically you could VirtualAlloc (Windows API) greater and greater memory blocks until it fails, deallocate the block and then try to allocate the same amount of memory in .NET, knowing that the memory is there so the .NET should be able to allocate it.
Note that this is true at 32 bits... I haven't ever seen an out-of-memory error at 64 bits.
This question already has answers here:
Is a GUID unique 100% of the time?
(24 answers)
Are GUID collisions possible?
(19 answers)
Closed 9 years ago.
I generate keys for my software as:
Guid.NewGuid().ToString();
that returns something like: 15c6bd70-8d3c-42d0-bb24-40da6e08ed9d
anyways everytime someone purchases a new software I generate a new key. can it be possible that I generate the same key twice? Everytime someone purchase the software I call the method: Guid.NewGuid().ToString() Should I append a counter at the end of each guid to be 100% sure that there cannot be duplicates?
Edit
A constructor of the Guid class takes a byte array of 16 bytes as a parameter. If you serialize the current date (8 bytes) then append another 8 random bytes to the constructor of the GUID will that be 100% secure? I am just asking for learning based on your answers I will probably just have Guid.NewGuid()
An excerpt from one of the best blog series ever written about the Guid:
There are a number of possible strategies for making a unique GUID, and in fact information about the strategy used is encoded in the first four bits of the third "group"; almost every GUID you see will be of the form {xxxxxxxx-xxxx-1xxx-xxxx-xxxxxxxxxxxx} or {xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx}.
If there is a one in that place then the algorithm used to guarantee uniqueness is essentially a variation on the ISBN strategy. The GUID is guaranteed to be unique "in space" by choosing some of the bits as the MAC address of the network card in the machine. (The tricky problem of ensuring that no two network cards in the world have the same MAC address is solved somehow by someone else; how that problem is solved, we don't particularly care. The cost of solving that problem is passed on to you, the consumer, in the purchase cost of the network card.)
In short, it's very unlikely that they would ever collide.
Yes, it's possible, but extremely unlikely. The probability for a GUID collision is about as likely as a bit in the GUID changing spontaneously in memory, and that kind of thing is not something that you normally worry about.
You can already be 100% sure, that is of course if you dont mean that you need to be 100.000000000000000000000000000000000000% sure.
Just use the Guid.. no need to append anything. Unless you expect to sell more copies than there are atoms in the universe (unlikely).
This question already has answers here:
Why does SignHash need to know what hash algorithm was used?
(2 answers)
Closed 9 years ago.
Since RSACryptoServiceProvider.SignHash signs an already hashed message - why does it need to know which hash algorithm was used?
It seems that in order to make the signature more useful to the recipient, the OID of the hashing algorithm that was used is included in the signature (per PKCS1). That way, it does not have to be communicated separately.
This question already has answers here:
YouTube URL algorithm?
(11 answers)
Closed 3 years ago.
I noticed on YouTube their keys look like this "BwgT06NY1FE". I was just wondering how is this type of key created? Is this based on a GUID?
This is most likely Base36. All letters and numbers. It's pretty common, because you can use a "SERIAL" in a database and just increment it, and then just parse from Base36 in your URL.
It makes for nice URLs (bit.ly also uses this format), but has some drawbacks. Ie, you wouldn't want to use it for any sort of private data because people can just type in a random number and get a result (it's unlikely someone could guess a GUID in use by your database unless they try a few billion)..
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is a GUID unique 100% of the time?
Basically:
Guid.NewGuid() - Does it loop around or generate through some algorithm?
I want to use Guid because it offers 2^128 possibilities. According to the MSDN:
The chance that the value of the new
Guid will be all zeros or equal to any
other Guid is very low.
The problem is they don't say why it is low. Is it low because the chances are unlikely or is it low because it is unlikely to loop all the way around?
This is a pseudo unique value. The algorithm exists of course, but the probability of getting the same value twice is super small.
They certainly can collide, but MS implementation is quite stable and uses several iterations of hashing (including BIOS timers etc), so that the value is something you can actually rely on.
Update.
There are many more GUID/UUID implementations performed for other purposes (e.g. Guid.comb algorithm for DB surrogate keys) - they actually can collide and I faced this myself in high loaded environments.
Check out: http://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
In the OSF-specified algorithm for
generating new (V1) GUIDs, the user's
network card MAC address is used as a
base for the last group of GUID
digits... Most
of the other digits are based on the
time while generating the GUID.