Inspiring

Question

Calculating combinations of a key

Forum|Forum|14 years ago
June 30, 2011
2 replies
2899 views

I want to protect accounds by introducing a key, and I need to calculate the potential combinations

so that I am happy with the amount of potential combinations.

I will use numbers 0-9 and characters A to Z .. so 36 characters in each column.

Example: 65TG9

Does anybody know where I might find an online calculator that I can use to check the number of combinations?

I need to let it know there are 36 characters, and then test the length of the string to get it up to a big enough number. I'm just trying to stop overkill, no point having a huge UUID if I don't need it

Thanks

Mark

Advanced techniques

This topic has been closed for replies.

D

Dan_Bracuk

Inspiring

Regarding " no point having a huge UUID if I don't need it"

They aren't that big, and they are available.

A

ACS LLCAuthor

Inspiring

Hi Dan,

I just don't think I need it. I'm planning on a large amount of users, and each one will need a record. This will be publically available, so I don't want to use actual CF generated UUID's because they are too similar when they come from the same server, so if you have one, you're halfway there on another one.

What I'm going to do is seed and make my own random string, and match that with the UID of the user, so the UID and string would have to match, that way it won' matter if in some bizzare situation it randomly creates two identical strings, because the UID's would not match you'd need both

I want to guage the number of combinations based on a much smaller string.

36 characters (0-9 and A-Z) and maybe just 8 or 10 characters. I have a feeling that would give me millions of combo's which would work and cut down the storage requirements at the same time

Thanks

Mark

A

Adam Cameron.

Inspiring

This will be publically available, so I don't want to use actual CF generated UUID's because they are too similar when they come from the same server, so if you have one, you're halfway there on another one.

Oh dear. UUIDs are called UUIDs for a reason. Universally Unique... errr... IDs. But the key part is "universally unique". And really? They are.

To suggest that a person could possibly intuit one UUID based on another UUID from the same server is... um... "ill-informed" shall I say.

There are UUID algorithms that use the server's MAC address as a part of the result (hence the similarity you're seeing on a given server), but the rest of it is based on (for example) the clock ticks in 100s of nanoseconds, a random component, and a sequence number in case there's a crazy situation in which the same random number is resolved in the same 100 nanosecond period. So very very very (and continue the "verys" for a while) unlikely to repeat. And also bear in mind that UUIDs are absolutely *not* random (universally unique != random), so there's a strong guarantee of non-randomness there.

Contrast this with your idea of a ten-character base-36 random number as a key. At any given moment there's a chance that one number will the the same as the previous number (or another already-used number), and the maximum combinations are 3656158440062976 (statistically: not many). Compared to the odds of two UUIDs matching being 3.4x10^38. And that's all UUIDs ever generated. On all computers. Ever. Over 20 orders of magnitude less likely to be reused that your idea. Even if you remove the random element and just use a sequence (which would be more unique than doing it randomly).

As far as storage concerns go... a UUID is a 128-bit number. 16 bytes. You could store 65000 of them in one MB. Remember those: megabytes? It's what we had before gigabytes, just before we went to terabytes. I think 1MB is 1/2000th of the storage my fairly mundane laptop's video card has. Storage is never a concern when it comes to primary keys.

So... yeah... using a UUID is much better.

However... UUIDs are unwieldy @ 32 hexadecimal characters long. If one needs to give one's users an ID that they can remember (but really? No-one bothers, they just copy and paste) then perhaps take the current time stamp to the millisecond (eg: yyyymmddhhnnsslll), then convert it to base-36 for brevity. The IDs will be sequential, but not really guessable (given the granularity of the base ID).

But whatever you do:

1) don't use random numbers;

2) don't reinvent the - industry-established, tried-and-true - wheel.

--

Adam

Owainnorth

Inspiring

Surely it's just 26 (letters in alphabet) multiplied by 26 again 35 times, ie 3.34E49?

Unless I've misunderstood. Or my maths is crap.

A

ACS LLCAuthor

Inspiring

I'm not so sure

Let's go with an easy example

Let's say I have a combination lock that has 1 and 2 on the barrel, and I have two barrels

that would give a potential

1 - 1

1 - 2

2 - 1

2 - 2

So 4 combinations. If I add an extra barrel

1,1,1

1,1,2

1,2,1

1,2,2

2,1,1

2,1,2

2,2,1

2,2,2

So 8 possible combinations, unless I messed that up

so 2 with 2 = 4

2 with 3 = 8

ummm

I think there is a formula that involves a triangle LOL.. I was not listening in school that day.. something about having to minus 1 for every row

Maybe it involves "to the power of - minus something or other"

There must be an online calculator somewhere!

Mark

-

-__cfSearching__-

Inspiring

I think there is a formula that involves a triangle LOL..

Ooh. Math flashbacks ...

http://mathforum.org/dr.math/faq/faq.pascal.triangle.html

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded