двухстороннее включенное шифрование/хеш-алгоритм

Шифрование и хеширование

Это проблема шифрования, так как необходимо восстановить исходную информацию. О качестве криптографического хеша судят по тому, насколько сложно отменить хэш и восстановить исходную информацию, поэтому хеширование здесь не применимо.

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

Приложение

Сфера применения здесь не ясна. Но если вы «шифруете» некоторую информацию и отправляете ее куда-то, а затем получаете ее обратно и что-то с ней делаете, то симметричное шифрование - лучший вариант. Например, вы хотите закодировать имя пользователя, IP-адрес, и некоторый идентификатор из вашего приложения в параметре, который вы включаете в ссылку в некотором HTML. Когда пользователь щелкает ссылку, этот параметр передается обратно в ваше приложение, и вы декодируете его, чтобы восстановить исходную информацию. Это отлично подходит для симметричного шифрования, потому что отправитель и получатель являются одной и той же стороной, а обмен ключами невозможен.

Общие сведения

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

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

Большим преимуществом симметричного шифрования является его скорость. Все хорошо разработанные протоколы используют симметричный алгоритм для шифрования больших объемов данных. Обратной стороной является то, что может быть сложно безопасно обмениваться ключами - что, если вы не можете «встретиться» (виртуально или физически) в безопасном месте, чтобы согласовать пароль?

Поскольку открытые ключи можно свободно передавать, два люди могут обмениваться личными сообщениями по незащищенному каналу без предварительного согласования ключа. Однако асимметричное шифрование работает намного медленнее, поэтому его обычно используют для шифрования симметричного ключа или выполнения «согласования ключей» для симметричного шифра. SSL и большинство криптографических протоколов проходят через рукопожатие, где асимметричное шифрование используется для установки симметричного ключа, который используется для защиты остальной части диалога.

Вероятно, вы не сможете.

Предположим, что w - 32 бита, x поддерживает как минимум 8 нечувствительных к регистру символов ASCII, поэтому как минимум 37 бит, а y - 32 бита ( приводит вас к 2038, а 31 бит даже не дает вам сейчас).

Итак, это всего как минимум 101 бит данных. Вы пытаетесь сохранить его в виде 8-значного числа. Математически невозможно создать обратимую функцию из большего набора в меньший набор, поэтому вам нужно будет хранить более 12,5 бит на «цифру».

Конечно, если вы перейдете к более чем 8 символам или если ваш символы - это 16-битный Unicode, тогда у вас, по крайней мере, есть шанс.

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

Если вы действительно хотите сделать то, что вы описали, вам нужно просто объединить строку и метку времени (заполните лишние пробелы символами подчеркивания или чем-то еще). Возьмите полученную строку, преобразуйте ее в ASCII или UTF-8 или что-то в этом роде и найдите ее значение по модулю наибольшего простого числа меньше 10 ^ 8.

Let's formalize your problem, to better study it.

Let k be a key from the set K of possible keys, and (w, x, y) a piece of information, from a set I, that we need to crypt. Let's define the set of "crypted-messages" as A⁸, where A is the alphabet from which we extract the characters to our crypted message (A = {0, 1, ..., 9, a, b, ..., z, ... }, depending on your specs, as you said).

We define the two functions:

crypt: I * K --> A^8.
decrypt A^8 * K --> I

The problem here is that the size of the set A^8, of crypted-messages, might be smaller than the set of pieces of information (w, x, y). If this is so, it is simply impossible to achieve what you are looking for, unless we try something different...

Let's say that only YOU (or your server, or your application on your server) have to be able to calculate (w, x, y) from z. That is, you might send z to someone, and you don't care that they will not be able to decrypt it.

In this case, what you can do is use a database on your server. You will crypt the information using a well-known algorithm, than you generate a random number z. You define the table:

Id: char[8]
CryptedInformation: byte[]

You will then store z on the Id column, and the crypted information on the corresponding column.

When you need to decrypt the information, someone will give you z, the index of the crypted information, and then you can proceed to decryption.

However, if this works for you, you might not even need to crypt the information, you could have a table:

Id: char[8]
Integer: int
Username: char[]
Timestamp: DateTime

And use the same method, without crypting anything.

This can be applied to an "e-mail verification system" on a subscription process, for example. The link you would send to the user by mail would contain z.

Hope this helps.

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

Целое число составляет 4 байта. Предположим, ваше имя пользователя ограничено 8 символами, и эти символы являются байтами. Тогда метка времени составляет как минимум еще 4 байта. Это 16 байт прямо здесь. В шестнадцатеричном формате это будет 32 цифры. Base36 или что-то в этом роде будет меньше, но и близко не будет 8.

Я не думаю, что возможно упаковать столько информации в 8-значное число таким образом, чтобы вы когда-либо снова смогли получить его.

Целое число - это 4 байта. Предположим, ваше имя пользователя ограничено 8 символами, и эти символы являются байтами. Тогда метка времени составляет как минимум еще 4 байта. Это 16 байт прямо здесь. В шестнадцатеричном формате это будет 32 цифры. Base36 или что-то вроде этого будет меньше, но и близко не будет 8.

Я не думаю, что возможно упаковать столько информации в 8-значное число таким образом, чтобы вы когда-либо снова смогли получить его.

Целое число - это 4 байта. Предположим, ваше имя пользователя ограничено 8 символами, и эти символы являются байтами. Тогда метка времени составляет как минимум еще 4 байта. Это 16 байт прямо здесь. В шестнадцатеричном формате это будет 32 цифры. Base36 или что-то вроде этого будет меньше, но и близко не будет 8.

Хеши по определению являются односторонними, после хеширования очень трудно вернуть исходное значение обратно.

Для двухстороннего шифрования я бы посмотрел на TripleDES, который запекал .net прямо с TripleDESCryptoServiceProvider .

Достаточно прямая статья о реализации.

РЕДАКТИРОВАТЬ

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