С криптографией у меня похоже пробел.

Надо преобразовать id в строку макс. 16 символов, но чем меньше, тем лучше. Хэш не катит, т.к. нужно обратное преобразование. При этом желательно максимально затруднить подбор валидной строки, т.е. не все комбинации символов допустимые (может проверочный код добавить).

Подскажите что из алгоритмов мне подойдет. Желательна реализация в стандартной библиотеке.

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

D>С криптографией у меня похоже пробел.

D>Надо преобразовать id в строку макс. 16 символов, но чем меньше, тем лучше. Хэш не катит, т.к. нужно обратное преобразование. При этом желательно максимально затруднить подбор валидной строки, т.е. не все комбинации символов допустимые (может проверочный код добавить).

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

D>Подскажите что из алгоритмов мне подойдет. Желательна реализация в стандартной библиотеке.

если же речь просто о "нечитаемом" виде числа, то преобразовывай его в строку с выбранным от 16 до 36 radix (и обратно) и будет тебе счастье

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

C0s>это не криптография, раз нужно обратное преобразование
видимо не только у меня пробел здесь

C0s>хотя, конечно, если добавить пару чисел, которые будут даваться "извне", то что-то можно смонстрить
ну да ключ шифрования — не проблема

C0s>если же речь просто о "нечитаемом" виде числа, то преобразовывай его в строку с выбранным от 16 до 36 radix (и обратно) и будет тебе счастье
легко поддается анализу на больше-меньше

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

C0s>>это не криптография, раз нужно обратное преобразование
D>видимо не только у меня пробел здесь

я, признаться, не имел в виду формальную сторону, а хотел лишь сказать, что стойкость любого симметричного алгоритма, применяемого к 4-8 байтам стремится к нулю

C0s>>хотя, конечно, если добавить пару чисел, которые будут даваться "извне", то что-то можно смонстрить
D>ну да ключ шифрования — не проблема

а он-таки будет извне? в смысле задаваться интерактивно пользователем в нужный момент (при шифровании и при дешифровании) или как-то ещё?

C0s>>если же речь просто о "нечитаемом" виде числа, то преобразовывай его в строку с выбранным от 16 до 36 radix (и обратно) и будет тебе счастье
D>легко поддается анализу на больше-меньше

ну, как я уже заметил, преобразования 4-8 байт вообще поддаются анализу, разве нет?

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

C0s>а он-таки будет извне? в смысле задаваться интерактивно пользователем в нужный момент (при шифровании и при дешифровании) или как-то ещё?

предполагается, что я буду иметь возможность сгенерить некий ключ, с временем жизни достаточным для шифрования и потом расшифрования

C0s>ну, как я уже заметил, преобразования 4-8 байт вообще поддаются анализу, разве нет?

зашититься от серьезного анализа — цель не стоит

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

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

D>собственно, суть задачи: скрыть на страничках и в адресах id-шники так, чтобы ссылки гарантированно работали только в пределах сессии, плюс затруднить подбор, но это уже перестраховка. Случайное попадание на страничку допустимо, а вот позволить пользователю свободное перемещение по контенту без входа в каталог нельзя.

может быть, можно так:
— при открытии сессии (при входе в каталог) ей присваивается случайная последовательность из, скажем, 32 байт — session_id. её никто не видит, кроме сервера
— у каждой позиции каталога есть свой private_id, который также никто не видит, и public_id, оба уникальные. можно сделать так, что public_id — 8-байтовое (long) число из последовательности, а сопоставленный ему private_id при создании записи вычисляется как version 1 UUID
— при выдаче списка позиций каталога на страницу каждая позиция маркируется параметром id, значение которого составляется из сконкатенированных public_id и auth_id=md5(private_id+session_id)
— при обращении к позиции каталога из id вынимается public_id и auth_id, при этом по public_id внтури вынимается private_id и берётся session_id из сессии. auth_id и md5(private_id+session_id) сравниваются и при совпадении — статья каталога выдаётся, при несовпадении — идёт редирект на login в каталог

md5 емнип в java реализован, врпочем, подойдёт любой надёжный алгоритм вычисления hash

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

C0s>Здравствуйте, dimok@, Вы писали:

D>>собственно, суть задачи: скрыть на страничках и в адресах id-шники так, чтобы ссылки гарантированно работали только в пределах сессии, плюс затруднить подбор, но это уже перестраховка. Случайное попадание на страничку допустимо, а вот позволить пользователю свободное перемещение по контенту без входа в каталог нельзя.

C0s>может быть, можно так:
C0s>- при открытии сессии (при входе в каталог) ей присваивается случайная последовательность из, скажем, 32 байт — session_id. её никто не видит, кроме сервера
C0s>- у каждой позиции каталога есть свой private_id, который также никто не видит, и public_id, оба уникальные. можно сделать так, что public_id — 8-байтовое (long) число из последовательности, а сопоставленный ему private_id при создании записи вычисляется как version 1 UUID
C0s>- при выдаче списка позиций каталога на страницу каждая позиция маркируется параметром id, значение которого составляется из сконкатенированных public_id и auth_id=md5(private_id+session_id)
C0s>- при обращении к позиции каталога из id вынимается public_id и auth_id, при этом по public_id внтури вынимается private_id и берётся session_id из сессии. auth_id и md5(private_id+session_id) сравниваются и при совпадении — статья каталога выдаётся, при несовпадении — идёт редирект на login в каталог

C0s>md5 емнип в java реализован, врпочем, подойдёт любой надёжный алгоритм вычисления hash

структура базы уже сформирована, id-шники надо прятать нескольких сущностей, не хотелось бы наворачивать что-то в бизнес-логике ради конкретной задачи в представлении (если со временем потребуется какой-то изыск, типа обмена ссылками между зарегистрированными пользователями или еще что-то)

я искал готовую реализацию или алгоритм симметричного шифрования, подходящую под совсем короткие последовательности

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

D>собственно, суть задачи: скрыть на страничках и в адресах id-шники так, чтобы ссылки гарантированно работали только в пределах сессии, плюс затруднить подбор, но это уже перестраховка. Случайное попадание на страничку допустимо, а вот позволить пользователю свободное перемещение по контенту без входа в каталог нельзя.

Есть, наверное, "глупый" вариант, запользовать какой-нибудь Spring WebFlow. Вообще, это его минус, что он параметры прячет за большим ключем в урле, но в вашем случае это, похоже, даже плюс

D>Надо преобразовать id в строку макс. 16 символов, но чем меньше, тем лучше. Хэш не катит, т.к. нужно обратное преобразование. При этом желательно максимально затруднить подбор валидной строки, т.е. не все комбинации символов допустимые (может проверочный код добавить).
D>Подскажите что из алгоритмов мне подойдет. Желательна реализация в стандартной библиотеке.
Можно конвертнуть в число с основанием например 36
пример программы описан в статье http://www.berdaflex.com/ru/other/articles/num_converter/default.html
если произвольно переставить исходный массив символов, то получим более стойкое к взламыванию число.