3 ms·

Interesting. Effectively it's base62 encoding with a fixed salt. I think saying "encrypt" and "decrypt" is sort of misleading, even though you call the non-cryp

by zrail 12y ago

Interesting. Effectively it's base62 encoding with a fixed salt. I think saying "encrypt" and "decrypt" is sort of misleading, even though you call the non-cryptographic nature of the hashing in the README files. For my own products I do something a little different. Instead, when I create a record I generate a random number (with Ruby's SecureRandom module) and store the base32 encoding in the database. With the universe set at 1bil, this reliably generates a random 6 character string that I can safely show to the customer. Edit: base62, not base82

amvp 12y ago
Base82? You mean base62 - 26(letters) x 2 (other case) +10 (digits)? Or am I missing something?
- zrail 12y ago
  Nope, you're exactly right. Need more coffee.
bazzargh 12y ago
You're storing 6-char base-32 values, so 1073741824 possibilities, but you've got 50-50 chance of collision after 38582 values - that's not a lot, the birthday paradox bites again! Using much larger random values or hashes gives you a better safety margin.
- zrail 12y ago
  I also have a unique constraint on the value and re-run the generator if there's a collision.
  - d55 12y ago
    That is something that hashid avoids.
JoshTriplett 12y ago
> this reliably generates a random 6 character string that I can safely show to the customer Are you sure about that? You might want to consider a smaller alphabet, with vowels and ambiguous letters/numerals (0/O, 1/l/I) omitted. That has two advantages: you won't accidentally generate an identifier containing meaningful words (notably profanity), and the identifiers become easier to unambiguously transcribe and interpret. And you'll still reliably get a 6-character identifier as long as you have at least 32 symbols to use.
- zrail 12y ago
  That's a fair point. So far there hasn't been any transcribing necessary because I have the customers reply to their receipt emails if they have a problem, but that's definitely something to consider if you have to do phone support.
  - mikeash 12y ago
    It's also useful for anything where they might retype the string. (Even if you tell them to copy/paste, some people will still retype.) Not that this necessarily applies to you, but for others considering similar schemes, avoiding I/1/l and such can be really handy.

by zrail 12y ago

amvp 12y ago

Base82? You mean base62 - 26(letters) x 2 (other case) +10 (digits)? Or am I missing something?

zrail 12y ago
Nope, you're exactly right. Need more coffee.

bazzargh 12y ago

You're storing 6-char base-32 values, so 1073741824 possibilities, but you've got 50-50 chance of collision after 38582 values - that's not a lot, the birthday paradox bites again! Using much larger random values or hashes gives you a better safety margin.

zrail 12y ago
I also have a unique constraint on the value and re-run the generator if there's a collision.
- d55 12y ago
  That is something that hashid avoids.

JoshTriplett 12y ago

> this reliably generates a random 6 character string that I can safely show to the customer Are you sure about that? You might want to consider a smaller alphabet, with vowels and ambiguous letters/numerals (0/O, 1/l/I) omitted. That has two advantages: you won't accidentally generate an identifier containing meaningful words (notably profanity), and the identifiers become easier to unambiguously transcribe and interpret. And you'll still reliably get a 6-character identifier as long as you have at least 32 symbols to use.

zrail 12y ago
That's a fair point. So far there hasn't been any transcribing necessary because I have the customers reply to their receipt emails if they have a problem, but that's definitely something to consider if you have to do phone support.
- mikeash 12y ago
  It's also useful for anything where they might retype the string. (Even if you tell them to copy/paste, some people will still retype.) Not that this necessarily applies to you, but for others considering similar schemes, avoiding I/1/l and such can be really handy.