MD5 выдает 32 разрядную уникальную строку.
Как сделать, что-то подобное, но на 8 разрядов? Например, используя цифры и регистрозависимые буквы.
Может есть уже готовые функции, алгоритмы или решения?

Да, и хотелось бы чтобы также как в MD5 вычислять эту строку и она также "лавинообразно" изменялась при изменении одного символа во входном параметре. :)

an0nymAIS,

MD5 - это не генератор случайных чисел. MD5 подвержен коллизиям. У вас явно неправильно выбрано средство реализации под задачу.
В том то и дело, что мне не надо как в MD5 "миллионы-миллиардов" значений, в которых можно найти коллизии.
Мне достаточно миллион, который будет формироваться на основе конкретного ряда значений (например, чисел от 0 до 1млн.), и который без труда можно будет в конце перед применением проверить на коллизии.

Идея состоит в том, чтобы заменить id_строк в таблице БД, которые сейчас числа, на вот такой ряд уникальных идентификаторов.

Спасибо всем за такое живое участие.
Постараюсь ответить сразу всем и повторюсь ещё раз про идею:
Есть БД FireBird_embed в открытом виде. Коль её нельзя защитить штатными средствами (т.к. их нет), а внешние средства защиты платные либо не подходят, то есть идея воспользоваться методом "Обфускации", т.е. запутать на сколько это возможно БД, чтобы она работала только с одним моим ПО.
На первом этапе есть желание в ключевых таблицах поменять РК, чтобы разорвать явную видимость отношений между таблицами.
an0nym...Обеспечение гарантии отсутствия коллизий хотя бы на 1 млн. разных значений вам встанет достаточно дорого. Но 1 млн. закончится достаточно быстро.
Есть таблица в которой id_pk числа от 1 до N, где планируется что N<1млн.
Каждому значению id_pk будет соответствовать 8 символьная строка из цифр и регистрозависимых букв. В цикле прогнать id_pk и проверить наличие коллизий не составит труда.
Siemargl1. в 8 бит миллион не помещается.
2. читаем в википедии про хэш и связанные алгоритмы - может найдете подходящий
1. в 8 разрядов (точнее символов в строке) поместится намного больше.
Обратите внимание - это 8 регистрозависимых символов. Собственно это и нужно, чтобы было значительно больше и не было видимой связи между id_pk/цифрой и id_pk/строкой. Конечно длину id_pk/строки можно ещё уменьшить при необходимости.
2. Читаю, ищу. :)
softwarerПроверьте у специалистов по используемой БД, что эту идею стоит реализовывать.
У специалистов взгляды на такого рода проблему координально расходятся с моими на предмет наличия штатной защиты у FB.

AIS ,
сам себя поправлю: имелось ввиду

an0nymAIS,

ИМХО, такая обфускация бессмысленна. Всё равно связи отследить будет достаточно легко.

Если вы пытаетесь защитить БД с данными пользователя от воровства с компьютера пользователя - зашифруйте её.

Если вы пытаетесь защитить свои данные в БД, которую вы полностью передаете на компьютер пользователю... ИМХО, миссия невыполнима.
Любое что затруднит несанкционированные действия с БД и отсечет какое-нибудь количество "взломщиков", уже имеет смысл. Как раз в этом, как я пониманию, и есть польза обфускации.
Данные в БД действительно шифруються, но только ключевые, т.к. это влияет на производительность, а остальное хочется "запутать" и "логику понимания" этого запутанного разместить непосредственно в ПО.
Есть уверенность, что "малой кровью" можно отсечь всех "любознательных", "интересующихся" и "жадных". :)

maytonAIS, может быть лучше подумать над юридической чистотой всего этого.
Это Вы про что именно?
maytonВ конце-концов должна быть заявлена особенность данного ПО.
О-о, это сверх узкоспециализированное ПО+БД и ориентированна на такую же специфичную целевую аудиторию.

maytonТы занимаешся безнадёжным и неблагодарным делом ИМХО.

По теме - если тебе надо однозначно преобразовывать primary keys, или прочие keys в шифрованные - используй любой блочный шифр. Размер блока можно выбрать минимальным или кратным макс. длине ключа. Но это всё равно мера временная. Если база очень ценна и интересна - твой код можно разобрать на атомы и понять что к чему.
По этому проекту всё парадоксально просто: очередь ведь не стоит и интересно это только узкому кругу специалистов, а они и не планируют взламывать либо тиражировать - это не их бизнес. А разобрать на детальки конечно могут, но специалист отдает предпочтение легальному продукту, т.к. верит PR-мероприятиям, что "только легальный продукт" может гарантировать достоверность данных, которые они потом используют в своих расчетах. Ошибка в расчетах - это не просто большие финансовые потери, но и зачастую потеря доверия и имиджа.
Но защищаться всегда надо по возможности. Я в этом уверен.
ShSergeЧёт совсем не понятно. Файрбёрд - серверная база. Ну, запаролить её и все дела.
ПО+БД распространяется как настольная версия, а FB в открытом виде и пароли здесь не помогают. Для FB они помогут только, когда БД физически на сервере разработчика. :)
SiemarglИдея за две копейки:

-средние 4 байта - или сколько нужно - оригинальный ИД, или простая функция от него (XOR const)
-остальные 4 - рандом

И уникальность есть и фиг поймешь (до дизассемблера).
С сортировкой по ид только фигово )
1. Подобного рода подход быстро вскрывается даже визуально.
2. Просматривается последовательность РК и т.д.