Здравствуйте, zsergeyz, Вы писали:


Z>Так в том то и вопрос. Рандом сделать просто. Но не хотелось бы каждый раз базу проверять на уникальность вносимого значения.
1. У вас в любом случае должен быть UQ на столбец со штрих-кодами. Вы уже потратили больше времени (и своего, и отвечавших), чем сэкономите при самом лучшем раскладе.
2. Бизнес-данные (а штрих-код — это уже часть системы) должны быть независимы от деталей реализации. Потребуется вам сменить id на GUID (например, для реплик во внешнюю систему) — что будете делать?
3. Вы хотите симметричное шифрование, соответственно, всё, что вас спасает от возможности реверса — это симметричный ключ в те же 53 бита. И надежда, что сам ID не засветится нигде снаружи, в т.ч. и в памяти клиента. Если вы хотите на этом строить безопасность — вперёд. Если не хотите — какая разница, подберут вам следующий ID или нет?
4. Правильный рэндом (со статистически равномерным заполнением 53х бит) сделать тоже не так-то и легко

Здравствуйте, zsergeyz, Вы писали:

Z>Мне не для URL нужно. И нужны именно 16-символьные последовательности. А GUID то не обрежешь. Уникальность нарушится.
Конечно-конечно. Я отвечал на конкретную фразу, не имеющую прямого отношения к топику.
Варианты:
1. GUID как раз влазит ровно в 16 8битных символов, если забить на читаемость.
2. Можно подсмотреть, как устроен сам GUID, и реализовать свою технологию для генерации более коротких последовательностей (естественно, ценой меньших гарантий уникальности).
Допустим, мы хотим утоптаться в base64. Тогда есть место для 6*16 = 96 бит. Не так уж и мало.
Если посмотреть в спецификацию GUID, то окажется, что там ничего сверхъестественного нет. Используемые сегодня GUID-ы, как правило, состоят из:
— 4х бит "версии", которые всегда одинаковые
— 1 бита "multicast", который гарантирует отстутсвие конфликтов GUID-ами, построенными на MAC-адресах
— 2 зарезервированных бит
— 14 бит "clock sequence", которые меняются относительно редко
— 60 бит таймстампа
— 47 бит "node", которые сгенерены псевдослучайным генератором

Итак, 7 бит в GUID итак никакой уникальности не добавляют. timestamp можно легко сократить: он показывает количество 100-наносекундных интервалов, прошедших с 15 октября 1582года. Можно безболезненно отрезать наиболее значимые биты. Грубо говоря, 50 бит хватит примерно на 10 лет уникальности.
Clock Sequence можно выбросить и вместо него при неудачных сдвигах времени перегенерировать node.
Таким образом:
1. 46 бит берёшь из криптоустойчивого генератора
2. 50 бит берёшь из timestamp.

Соотношение между 1 и 2 можно менять: если производительность неважна, то можно все 96 бит генерировать случайно. Если важна, то комбинируешь дешёвый timestamp и дорогой случайный генератор.

Здравствуйте, zsergeyz, Вы писали:

Z> — Алгоритм генерации UID может быть абсолютно любой. Главное, чтобы UID никогда не повторялись.

Если вам не важно, что по UID можно будет относительно просто восстановить оригинальный ID то, можно сделать XOR оригинального ID со случайной (или псевдо-случайной) маской.

Здравствуйте, zsergeyz, Вы писали:

O>>Ну и так, на всякий случай — на уникальность не забывайте проверять. Даже по-настоящему случайные числа != неповторяющиеся.

Z>Так в том то и вопрос. Рандом сделать просто. Но не хотелось бы каждый раз базу проверять на уникальность вносимого значения.

А вы так или иначе от этого никак не избавитесь. Проверять уникальность перед записью в таблицу (и, если необходимо, перегенерировать клод) или сразу пытаться записывать (и получать ошибку неуникального значения ключа) — это ваше дело. Важно то, что по теории вероятностей любой генератор — случайный или псевдослучайный (хоть монетку подбрасывайте) — может с ненулевой вероятностью вернуть один и тот же код повторно.
Вряд ли это должно быть проблемой, проверка по ключу в базе очень быстрая, даже если код в виде строки хранить.

Здравствуйте, zsergeyz, Вы писали:
Z>Мне не для URL нужно. И нужны именно 16-символьные последовательности. А GUID то не обрежешь. Уникальность нарушится.
Не нужно относиться к GUID как к магии. Представьте, что функции CreateGuid не существует. Вы что, не сможете сами написать аналог? А теперь напишите аналог для 96 бит, а не для 128.
На всякий случай напомню, что GUID не гарантированно уникальны, а статистически уникальны.
На пальцах: это означает, что шансы на совпадение двух независимо сгенерированных GUID пренебрежимо малы, хотя и не равны нулю.
На тех же пальцах: оцените вероятность совпадения GUID в вашем случае. Оцените её же для совпадения для самодельных "GUID16". Формулы подсказать?

Здравствуйте, zsergeyz, Вы писали:

Z>Нельзя. Нужно спрятать ID объекта. Чтобы следующий штрих-код не был "0000000000035135". Может какими-то битовыми сдвигами сделать. Нужно сделать так, чтобы штрихкод был похож на случайную последовательность. Хорошо бы подошел какой-нибудь алгоритм симметричного шифрования, для которого бы можно было задавать длину результата шифрования и символы, которые бы на выходе получались. (Если конечно такой алгоритм существует). Хэширование не подходит, т.к. оно не подразумевает уникальности генерируемых значений.
Используйте алгоритм RC4, применяемый при генерации GUID.
Вот здесь приведён подробный разбор — вместе с недостатками.

Здравствуйте, Sinclair, Вы писали:

S>Формулы подсказать?

Было бы здорово!

Z>Задача следующая:
Z> — Для объекта необходимо задавать уникальный 16-символьный UID (используя цифры от 0 до 9)
Z> — ID объектов в базе данных сейчас имеют значения от 1 до чисел 5-го порядка (1 ... 100001, 100002 и т.д.). Дойдут максимум до 8 порядка.
Z> — Алгоритм генерации UID может быть абсолютно любой. Главное, чтобы UID никогда не повторялись.

Z>В данный момент есть задумка:
Z>1) преобразовать DB ID объекта в строку
Z>2) добить ее нулями до 16 символов (как пример "0000000000035134")
Z>3) зашифровать строку, используя алгоритм шифрации, который даст на выходе такое же количество символов. Притом строка также будет состоять из десятичных цифр.

А насколько этот шифр должен быть стойким? Можно например взять эти 8 цифирок, расставить их на четные места. А на нечетные расставить что-то совершенно случайное. Полученную кашу из 16 символов и считать UID. Посложнее — на четные места расставить ID xor 55 по каждому байту. Учитывая что нечетные места никогда не будут повторяться, то UID бутут разные. А что вписывать в четные места — придумайте сами. Можно timespamp какой-нибудь или еще какую-то информацию.

Здравствуйте, zsergeyz, Вы писали:

Z>Здравствуйте, Sinclair, Вы писали:

S>>Формулы подсказать?

Z>Было бы здорово!

Мне думаюется вам нужен некий сдвиговый регистр (в сущности RC4 его и использует)?

Здравствуйте, hardcase, Вы писали:

H>Мне думаюется вам нужен некий сдвиговый регистр (в сущности RC4 его и использует)?

Упс. Не туда ссылку дал. Вот правильная.

Здравствуйте, zsergeyz, Вы писали:
Z>Было бы здорово!
http://en.wikipedia.org/wiki/Birthday_problem

Здравствуйте, Pavel_Agurov, Вы писали:
P_A>А насколько этот шифр должен быть стойким? Можно например взять эти 8 цифирок, расставить их на четные места. А на нечетные расставить что-то совершенно случайное. Полученную кашу из 16 символов и считать UID. Посложнее — на четные места расставить ID xor 55 по каждому байту. Учитывая что нечетные места никогда не будут повторяться, то UID бутут разные. А что вписывать в четные места — придумайте сами. Можно timespamp какой-нибудь или еще какую-то информацию.
Я так понял, что не хочется иметь возможность предсказывать следующий ID. Предлагаемый способ даст злоумышленнику шанс увидеть закономерность по нескольким UID.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel_Agurov, Вы писали:
P_A>>А насколько этот шифр должен быть стойким? Можно например взять эти 8 цифирок, расставить их на четные места. А на нечетные расставить что-то совершенно случайное. Полученную кашу из 16 символов и считать UID. Посложнее — на четные места расставить ID xor 55 по каждому байту. Учитывая что нечетные места никогда не будут повторяться, то UID бутут разные. А что вписывать в четные места — придумайте сами. Можно timespamp какой-нибудь или еще какую-то информацию.
S>Я так понял, что не хочется иметь возможность предсказывать следующий ID. Предлагаемый способ даст злоумышленнику шанс увидеть закономерность по нескольким UID.

Закономерность можно будет увидеть только в половине цифирок. В остальных 8 закономерности не будет, если стандартный Random не использовать. Собственно и вопрос-то в том — насколько это все должно быть стойким...