Which "good" block encryption algorithm has the shortest output?

Question

I would like to give customers a random-looking order number but use 0, 1, 2, ... in the backend. That way the customer gets a non-password-protected order status URL with the encrypted order number and they cannot look at other customers' order numbers by adding or subtracting 1. This might replace a scheme where random order keys are generated, checked for uniqueness among all the previous orders, and re-generated until unique. When the web server gets a request to view an order, it decrypts the order number and retrieves the order.

To keep the URL short, what "good" encryption algorithm has the shortest block size? Is this scheme a good idea? (What if I was encrypting Apple, Inc. employee ids to keep Steve Jobs from asking for Employee #0?)

Observe that all the package tracking websites allow you to track packages without authentication. It would be fine to limit the amount of information shown on the password-free order status page.

Answer 1

guid is the way to go for that

* edit *

you might want to look at this http://csharpfeeds.com/post/4382/A_shorter_and_URL_friendly_GUID.aspx

Answer 2

Why? Don't you think a UUID or a Globally Unique Identifier would be best for that? There are libraries for doing that.

Answer 3

I don't think this scheme is that great of an idea. Why aren't you verifying that a user is logged in and has access to view a specified order?

If you REALLY want to just have all orders out there without any authentication, a GUID would be best.

Or, you could try to come up with order numbers prefixed with something about the customer. Like (PhoneNumber)(1...100)

Answer 4

To meet the requirement you could simply use a hash such as SHA-1 or MD5 on your indexes. These will provide the adequate security you require.

To bring down the size you can change to a different encoding; such as 64 bit.

I'd also very strongly recommend insist on using a salt, otherwise the hash values could easily be broken.

Answer 5

Most block ciphers are going to use larger than 32-bit sized blocks, for security reasons.

However, I found one that is made specifically for what you are doing: Skip32

You may consider using a GUID, but perhaps you have reasons you want to avoid that. (Say, your app is done already.)

Edit: Actually, if a GUID is permissible, then that gives you a range of 128 bits. You could easily use any other block cipher. The benefit to having a larger space (at the cost of long ID strings) is that you'll have much more protection from people guessing IDs. (Not that it an order ID by itself should be a security token anyways...)

Answer 6

If your idea is that just knowing the order number (or URL) is enough to get information on the order then:

• The order number space needs to be extremely large, otherwise attackers and/or customers will conceivably search the order space, to see what can be seen.
• You should consider that an attacker may launch gradual probing from numerous machines, and may be patient.
• Probing the order number space can be mitigated by rate limiting, but that's very hard to apply in a web environment -- it's hard to distinguish your customer access from attacker access.
• Consider also that the order number is not much of a secret, people could be sending around in emails; once it's out, it's impossible to retract.

So, for the convenience of one-click check-my-order-without-logging-in, you have created a permanent security risk.

Even if you make the order number space huge, you still have the problem that those URLs are floating around out there, maybe in possession of folks who shouldn't have gotten them.

It would be much much better to require a login session in order to see anything, then only show them the orders they're authorized to see. Then you don't have to worry about hiding order numbers or attackers guessing order numbers, because just the order number isn't enough information to access anything.

Answer 7

I prototyped this idea using Blowfish, a block cipher with 64-bit blocks.