1,2 Мб, 900x632Двачик, назови мне самые надежные методы криптографии.
бамп!!!
помоги двач!
>>6824 (OP)
Если ты про шифры, то шифр Вернама, - самый надежный. Абсолютная криптостойкость. Но он сосет по ряду причин. Открывай вики, читай. Там и на sha256 наткнешься, и на гост 28147-89 aka магма. В путь-дорогу, анон.
Если ты про шифры, то шифр Вернама, - самый надежный. Абсолютная криптостойкость. Но он сосет по ряду причин. Открывай вики, читай. Там и на sha256 наткнешься, и на гост 28147-89 aka магма. В путь-дорогу, анон.
>>6824 (OP)
Есть шифр Вернама в компьютере это XOR с длинной ключа равной длине шифруемых данных но он семеричный и очень неудобный зато очень надежный.
Симметричное шифрование использует один и тот же ключ и для зашифровывания, и для расшифровывания. Асимметричное шифрование использует два разных ключа: один для зашифровывания (который также называется открытым), другой для расшифровывания (называется закрытым).
Есть более удобный и менее надежный асимметричный RSA но и длина ключа там от 2048 бит и выше.
все зависит от кого и зачем ты пытаешься спрятать информацию.
Есть шифр Вернама в компьютере это XOR с длинной ключа равной длине шифруемых данных но он семеричный и очень неудобный зато очень надежный.
Симметричное шифрование использует один и тот же ключ и для зашифровывания, и для расшифровывания. Асимметричное шифрование использует два разных ключа: один для зашифровывания (который также называется открытым), другой для расшифровывания (называется закрытым).
Есть более удобный и менее надежный асимметричный RSA но и длина ключа там от 2048 бит и выше.
все зависит от кого и зачем ты пытаешься спрятать информацию.
>>6919
Вера? Надежда и Любовь?
Вера? Надежда и Любовь?
>>6824 (OP)
Многократное например AES-Twofish-Serpent или Serpent-Twofish-AES
Многократное например AES-Twofish-Serpent или Serpent-Twofish-AES
>>6827
>>6837
Шифр Вернама - потоковый шифр.
https://ru.wikipedia.org/wiki/Потоковый_шифр#История
Из статьи, очевидно, что он обладает доказанной абсолютной криптостойкостью.
Впрочем, это понятно и интуитивно.
Ключ, длиной в сообщение x бит, имеет значение от 0 до 2^x бит,
и чтобы расшифровать сообщение, надо ПОДОБРАТЬ ключ. Попробуй подбери прямым перебором!
Даже если удастся подобрать часть ключа - будет доступна лишь часть сообщения.
Шифр Вернама, позволяет побитово шифровать два потока - поток ключа и поток сообщения.
Раньше подобное шифрование использовали на перфолентах.
Операция XOR, очень быстрая и легко-реализуемая, с помощью стандартных логических элементов.
Однако, из-за большой длины ключа, длиной в сообщение,
появляется ряд проблем.
Если такой ключ передавать, то его не возможно спрятать из-за ебической длины, а значит, перехватив его - можно расшифровать сообщение.
Если ключ генерировать, то на это надо время - это вторая проблема.
Впрочем, ключ Вернама, можно генерировать как последовательность хэшей:
Грубо-говоря, так:
Но, вычисление хэшей в цикле - медленное.
Можно также использовать PRNG, чем впрочем, и является вышеописанный пример с хэшами,
однако случайно-сгенерированный ключ Вернама, значительно более криптостойкий, если вероятность появления бит в нём - распределена равномерно.
Если же, использовать PRNG, тогда взломщику не нужно будет перебирать весь ключ, а зная алгоритм, достаточно будет только подобрать StartHash или Seed, что может быть под силу суперкомпьютерам. То есть, еспользование PRNG, уменьшает криптостойкость, но зато снижает необходимость передачи длинного ключа, по открытому каналу, ведь можно просто передать начальное значение - seed для PRNG.
Для обмена начальным значением, без его передачи по открытому каналу, может использоваться Diffie-Hellman Key Exchange, или ECDH, с прешаренными публичными ключами, чтобы исключить MITM-атаку.
Впрочем, вместо того, чтобы генерировать длиннющий ключ Вернама, можно использовать просто DH+AES.
У AES длина блока 16 байт, это 128 бит, и 2^128 - это такое ебически большое число комбинаций, что хуй подберёшь этот ёбанный ключ, даже на суперкомпах, наверное, блядь.
Хотя, насколько я знаю, есть алго, которые могут, за счет кэширования, снизить число вариантов перебора, до корня из числа комбинаций.
Гугли Baby Step Giant Step, чтобы понять как это, примерно работает.
Но если до корня производить вычислительные операции, то ипамяти надо там выделить, для хранения промежуточных значений - ещё от нуля до корня числа комбинаций, лол.
В общем, нереально перебрать все 2^128 комбинаций, поэтому AES (Rijndael) достаточно годный, вроде. Не даром это American Encryption Standart (AES).
>>6837
Шифр Вернама - потоковый шифр.
https://ru.wikipedia.org/wiki/Потоковый_шифр#История
Из статьи, очевидно, что он обладает доказанной абсолютной криптостойкостью.
Впрочем, это понятно и интуитивно.
Ключ, длиной в сообщение x бит, имеет значение от 0 до 2^x бит,
и чтобы расшифровать сообщение, надо ПОДОБРАТЬ ключ. Попробуй подбери прямым перебором!
Даже если удастся подобрать часть ключа - будет доступна лишь часть сообщения.
Шифр Вернама, позволяет побитово шифровать два потока - поток ключа и поток сообщения.
Раньше подобное шифрование использовали на перфолентах.
Операция XOR, очень быстрая и легко-реализуемая, с помощью стандартных логических элементов.
Однако, из-за большой длины ключа, длиной в сообщение,
появляется ряд проблем.
Если такой ключ передавать, то его не возможно спрятать из-за ебической длины, а значит, перехватив его - можно расшифровать сообщение.
Если ключ генерировать, то на это надо время - это вторая проблема.
Впрочем, ключ Вернама, можно генерировать как последовательность хэшей:
Грубо-говоря, так:
>StartHash - 32 байта начального хэша, 256 бит
>CurrentHash = StartHash; - 32 байта текущего хэша
>vernamkey - длинный ключ.
>for(int i=0; i<message.Length/32; i+=32){
> CurrentHash = sha256(CurrentHash);
> VernamKey += CurrentHash
>}
Но, вычисление хэшей в цикле - медленное.
Можно также использовать PRNG, чем впрочем, и является вышеописанный пример с хэшами,
однако случайно-сгенерированный ключ Вернама, значительно более криптостойкий, если вероятность появления бит в нём - распределена равномерно.
Если же, использовать PRNG, тогда взломщику не нужно будет перебирать весь ключ, а зная алгоритм, достаточно будет только подобрать StartHash или Seed, что может быть под силу суперкомпьютерам. То есть, еспользование PRNG, уменьшает криптостойкость, но зато снижает необходимость передачи длинного ключа, по открытому каналу, ведь можно просто передать начальное значение - seed для PRNG.
Для обмена начальным значением, без его передачи по открытому каналу, может использоваться Diffie-Hellman Key Exchange, или ECDH, с прешаренными публичными ключами, чтобы исключить MITM-атаку.
Впрочем, вместо того, чтобы генерировать длиннющий ключ Вернама, можно использовать просто DH+AES.
У AES длина блока 16 байт, это 128 бит, и 2^128 - это такое ебически большое число комбинаций, что хуй подберёшь этот ёбанный ключ, даже на суперкомпах, наверное, блядь.
Хотя, насколько я знаю, есть алго, которые могут, за счет кэширования, снизить число вариантов перебора, до корня из числа комбинаций.
Гугли Baby Step Giant Step, чтобы понять как это, примерно работает.
Но если до корня производить вычислительные операции, то ипамяти надо там выделить, для хранения промежуточных значений - ещё от нуля до корня числа комбинаций, лол.
В общем, нереально перебрать все 2^128 комбинаций, поэтому AES (Rijndael) достаточно годный, вроде. Не даром это American Encryption Standart (AES).
>>6827
>>6837
Шифр Вернама - потоковый шифр.
https://ru.wikipedia.org/wiki/Потоковый_шифр#История
Из статьи, очевидно, что он обладает доказанной абсолютной криптостойкостью.
Впрочем, это понятно и интуитивно.
Ключ, длиной в сообщение x бит, имеет значение от 0 до 2^x бит,
и чтобы расшифровать сообщение, надо ПОДОБРАТЬ ключ. Попробуй подбери прямым перебором!
Даже если удастся подобрать часть ключа - будет доступна лишь часть сообщения.
Шифр Вернама, позволяет побитово шифровать два потока - поток ключа и поток сообщения.
Раньше подобное шифрование использовали на перфолентах.
Операция XOR, очень быстрая и легко-реализуемая, с помощью стандартных логических элементов.
Однако, из-за большой длины ключа, длиной в сообщение,
появляется ряд проблем.
Если такой ключ передавать, то его не возможно спрятать из-за ебической длины, а значит, перехватив его - можно расшифровать сообщение.
Если ключ генерировать, то на это надо время - это вторая проблема.
Впрочем, ключ Вернама, можно генерировать как последовательность хэшей:
Грубо-говоря, так:
Но, вычисление хэшей в цикле - медленное.
Можно также использовать PRNG, чем впрочем, и является вышеописанный пример с хэшами,
однако случайно-сгенерированный ключ Вернама, значительно более криптостойкий, если вероятность появления бит в нём - распределена равномерно.
Если же, использовать PRNG, тогда взломщику не нужно будет перебирать весь ключ, а зная алгоритм, достаточно будет только подобрать StartHash или Seed, что может быть под силу суперкомпьютерам. То есть, еспользование PRNG, уменьшает криптостойкость, но зато снижает необходимость передачи длинного ключа, по открытому каналу, ведь можно просто передать начальное значение - seed для PRNG.
Для обмена начальным значением, без его передачи по открытому каналу, может использоваться Diffie-Hellman Key Exchange, или ECDH, с прешаренными публичными ключами, чтобы исключить MITM-атаку.
Впрочем, вместо того, чтобы генерировать длиннющий ключ Вернама, можно использовать просто DH+AES.
У AES длина блока 16 байт, это 128 бит, и 2^128 - это такое ебически большое число комбинаций, что хуй подберёшь этот ёбанный ключ, даже на суперкомпах, наверное, блядь.
Хотя, насколько я знаю, есть алго, которые могут, за счет кэширования, снизить число вариантов перебора, до корня из числа комбинаций.
Гугли Baby Step Giant Step, чтобы понять как это, примерно работает.
Но если до корня производить вычислительные операции, то ипамяти надо там выделить, для хранения промежуточных значений - ещё от нуля до корня числа комбинаций, лол.
В общем, нереально перебрать все 2^128 комбинаций, поэтому AES (Rijndael) достаточно годный, вроде. Не даром это American Encryption Standart (AES).
>>6837
Шифр Вернама - потоковый шифр.
https://ru.wikipedia.org/wiki/Потоковый_шифр#История
Из статьи, очевидно, что он обладает доказанной абсолютной криптостойкостью.
Впрочем, это понятно и интуитивно.
Ключ, длиной в сообщение x бит, имеет значение от 0 до 2^x бит,
и чтобы расшифровать сообщение, надо ПОДОБРАТЬ ключ. Попробуй подбери прямым перебором!
Даже если удастся подобрать часть ключа - будет доступна лишь часть сообщения.
Шифр Вернама, позволяет побитово шифровать два потока - поток ключа и поток сообщения.
Раньше подобное шифрование использовали на перфолентах.
Операция XOR, очень быстрая и легко-реализуемая, с помощью стандартных логических элементов.
Однако, из-за большой длины ключа, длиной в сообщение,
появляется ряд проблем.
Если такой ключ передавать, то его не возможно спрятать из-за ебической длины, а значит, перехватив его - можно расшифровать сообщение.
Если ключ генерировать, то на это надо время - это вторая проблема.
Впрочем, ключ Вернама, можно генерировать как последовательность хэшей:
Грубо-говоря, так:
>StartHash - 32 байта начального хэша, 256 бит
>CurrentHash = StartHash; - 32 байта текущего хэша
>vernamkey - длинный ключ.
>for(int i=0; i<message.Length/32; i+=32){
> CurrentHash = sha256(CurrentHash);
> VernamKey += CurrentHash
>}
Но, вычисление хэшей в цикле - медленное.
Можно также использовать PRNG, чем впрочем, и является вышеописанный пример с хэшами,
однако случайно-сгенерированный ключ Вернама, значительно более криптостойкий, если вероятность появления бит в нём - распределена равномерно.
Если же, использовать PRNG, тогда взломщику не нужно будет перебирать весь ключ, а зная алгоритм, достаточно будет только подобрать StartHash или Seed, что может быть под силу суперкомпьютерам. То есть, еспользование PRNG, уменьшает криптостойкость, но зато снижает необходимость передачи длинного ключа, по открытому каналу, ведь можно просто передать начальное значение - seed для PRNG.
Для обмена начальным значением, без его передачи по открытому каналу, может использоваться Diffie-Hellman Key Exchange, или ECDH, с прешаренными публичными ключами, чтобы исключить MITM-атаку.
Впрочем, вместо того, чтобы генерировать длиннющий ключ Вернама, можно использовать просто DH+AES.
У AES длина блока 16 байт, это 128 бит, и 2^128 - это такое ебически большое число комбинаций, что хуй подберёшь этот ёбанный ключ, даже на суперкомпах, наверное, блядь.
Хотя, насколько я знаю, есть алго, которые могут, за счет кэширования, снизить число вариантов перебора, до корня из числа комбинаций.
Гугли Baby Step Giant Step, чтобы понять как это, примерно работает.
Но если до корня производить вычислительные операции, то ипамяти надо там выделить, для хранения промежуточных значений - ещё от нуля до корня числа комбинаций, лол.
В общем, нереально перебрать все 2^128 комбинаций, поэтому AES (Rijndael) достаточно годный, вроде. Не даром это American Encryption Standart (AES).
>>7874
Если аппаратным ГСЧ сгенерируешь ключ, состоящий из рандома,
то его надо будет передать, этот ключ.
А если ГСПЧ использовать, то не надо будет передавать ключ, достаточно будет передать только семя (seed), а дальше уже - засунуть его в PRNG и сгенерить ключ любой нужной длины.
Если аппаратным ГСЧ сгенерируешь ключ, состоящий из рандома,
то его надо будет передать, этот ключ.
А если ГСПЧ использовать, то не надо будет передавать ключ, достаточно будет передать только семя (seed), а дальше уже - засунуть его в PRNG и сгенерить ключ любой нужной длины.
>>6824 (OP)
Кузнечик))
Кузнечик))
>>6824 (OP)
One Time Pad, OTP. Надежнее быть не может не представляю.
> самые надежные методы криптографии
One Time Pad, OTP. Надежнее быть не может не представляю.
А почему шифр Винжера - хуйня, в случае если ключ больше сообщения?
symetric - AES 1024 byt.
asymetric - RSA 12288 byt.
asymetric - RSA 12288 byt.
>>6824 (OP)
Надежных дохуя, никто не устраивает атаки на алгоритмы, проще на фвабру посадить или ключи спиздить. Так что безопасность = совокупность мер.
Надежных дохуя, никто не устраивает атаки на алгоритмы, проще на фвабру посадить или ключи спиздить. Так что безопасность = совокупность мер.
>>6824 (OP)
Никому ничего не рассказывать.
Никому ничего не рассказывать.