Какой «хороший» алгоритм блочного шифрования имеет самый короткий выход?

Question

Я хотел бы дать клиентам случайный номер заказа, но использовать 0, 1, 2, ... в бэкэнде. Таким образом, клиент получает URL-адрес статуса заказа, не защищенный паролем, с зашифрованным номером заказа, и они не могут просматривать номера заказов других клиентов, добавляя или вычитая 1. Это может заменить схему, где генерируются случайные ключи заказа, проверенные на уникальность среди всех предыдущих заказов, и перегенерированы до уникальности. Когда веб-сервер получает запрос на просмотр заказа, он расшифровывает номер заказа и получает заказ.

Чтобы URL был коротким, какой «хороший» алгоритм шифрования имеет самый короткий размер блока? Эта схема хорошая идея? (Что если я шифрую идентификаторы сотрудников Apple, Inc., чтобы Стив Джобс не спрашивал сотрудника №0?)

Обратите внимание, что все веб-сайты отслеживания пакетов позволяют отслеживать пакеты без аутентификации. Было бы неплохо ограничить объем информации, отображаемой на странице статуса заказа без пароля.

Answer 1

В целях безопасности большинство блочных шифров используют блоки размером более 32 бит.

Однако я нашел тот, который сделан специально для того, что вы делаете: Skip32

Вы можете рассмотреть возможность использования GUID, но, возможно, у вас есть причины, по которым вы хотите этого избежать. (Скажем, ваше приложение уже сделано.)

Edit: На самом деле, если GUID допустим, то это дает вам диапазон 128 бит. Вы можете легко использовать любой другой блочный шифр. Преимущество наличия большего пространства (за счет длинных строк идентификаторов) состоит в том, что вы будете иметь намного большую защиту от людей, угадывающих идентификаторы. (Не то чтобы идентификатор заказа сам по себе должен быть маркером безопасности ...)

Answer 2

Если ваша идея заключается в том, что для получения информации о заказе достаточно просто знать номер заказа (или URL):

• Пространство номеров заказов должно быть очень большим, в противном случае злоумышленники и / или клиенты, возможно, будут искать пространство заказов, чтобы увидеть, что можно увидеть.
• Вам следует учесть, что злоумышленник может начать постепенное зондирование с множества машин и может проявить терпение.
• Проверка пространства номеров заказов может быть уменьшена путем ограничения скорости, но это очень трудно применить в веб-среде - трудно отличить доступ вашего клиента от доступа злоумышленника.
• Учтите также, что номер заказа не является большой тайной, люди могут рассылать его по электронной почте; как только он выйдет, его невозможно убрать.

Итак, для удобства проверки одним щелчком без входа в систему вы создали постоянную угрозу безопасности.

Даже если вы сделаете пространство для номера заказа огромным, у вас все еще будет проблема с тем, что эти URL распространяются повсюду, возможно, у людей, которые не должны были их получить.

Было бы намного лучше потребовать сеанс входа в систему, чтобы увидеть что-либо, а затем показать им только те заказы, на которые они уполномочены смотреть. Тогда вам не нужно беспокоиться о сокрытии номеров заказов или о том, что злоумышленники угадывают номера заказов, потому что просто номер заказа не достаточен для доступа к чему-либо.

Answer 3

Недавно я начал использовать Hashids набор небольших библиотек. Идея состоит в том, чтобы зашифровать число или список чисел в хешированную строку, например:

12345 => "NkK9"
[683, 94108, 123, 5] => "aBMswoO2UB3Sj"

Библиотеки реализованы на популярных языках программирования различными авторами. Они также являются кросс-совместимыми, что означает, что вы можете кодировать число в Python, а затем декодировать его в JavaScript. Он поддерживает соли, определение алфавита и даже исключение плохих слов.

Python:

hashids = Hashids(salt="this is my salt")
id = hashids.encode(683, 94108, 123, 5)

JS:

var hashids = new Hashids("this is my salt"),
numbers = hashids.decode("aBMswoO2UB3Sj");

Это не защищенное правительством шифрование, но вполне достаточное для некоторых непредсказуемых сайтов с постоянными ссылками.

Answer 4

Вопросы о том, должны ли вы на самом деле делать это в стороне, вот очень простой блочный шифр с фиксированным ключом (так как, похоже, вам все равно нужна только одна перестановка).

static uint permute(uint id)
{
  uint R = id & 0xFFFF, L = (id>>16) ^ (((((R>>5)^(R<<2)) + ((R>>3)^(R<<4))) ^ ((R^0x79b9) + R)) & 0xFFFF);
  R ^= ((((L>>5)^(L<<2)) + ((L>>3)^(L<<4))) ^ ((L^0xf372) + L)) & 0xFFFF;
  return ((L ^ ((((R>>5)^(R<<2)) + ((R>>3)^(R<<4))) ^ ((R^0x6d2b) + R))) << 16) | R;
}

Skip32 намного лучше, чем 32-битные блочные шифры, но немного тяжелее, чем три (длинные) строки. : -)

Answer 5

Я прототипировал эту идею, используя Blowfish, блочный шифр с 64-битными блоками.

Answer 6

Для удовлетворения требований вы можете просто использовать хеш, например, SHA-1 или MD5 в ваших индексах. Это обеспечит необходимую безопасность.

Чтобы уменьшить размер, вы можете изменить кодировку на другую; например, 64 бит.

Я бы также очень настоятельно рекомендовал настаивать на использовании соли, в противном случае хеш-значения могут быть легко нарушены.

Answer 7

Я не думаю, что эта схема - отличная идея. Почему вы не проверяете, что пользователь вошел в систему и имеет доступ для просмотра указанного заказа?

Если вы ДЕЙСТВИТЕЛЬНО хотите иметь все заказы без какой-либо аутентификации, лучше использовать GUID.

Или вы можете попытаться придумать номера заказов с префиксом, что-то о клиенте. Like (PhoneNumber) (1 ... 100)

Answer 8

Guid - это путь для этого

* редактировать *

вы можете посмотреть на это http://csharpfeeds.com/post/4382/A_shorter_and_URL_friendly_GUID.aspx