Байтовое шифрование (нулевая панель DES-CBC) - PullRequest
Новая
       8

Байтовое шифрование (нулевая панель DES-CBC)

0 голосов
/ 04 апреля 2010

В настоящее время пишу свой собственный AMF TcpSocketServer. Пока все работает хорошо, я могу отправлять и получать объекты, и я использую некоторый код сериализации / десериализации. Теперь я начал работать над кодом шифрования, и я не очень знаком с этим.

  • Я работаю с байтами, является ли DES-CBC хорошим способ зашифровать этот материал? Или есть другие более производительные / безопасные способы отправить мои данные? Обратите внимание, что производительность является обязательным:).
  • Когда я вызываю: ReadAmf3Object с указанным расшифровщиком, я получаю: InvalidOperationException, генерируемое моей функцией ReadAmf3Object, когда я считываю первый байт, Amf3TypeCode не указан (я думаю, они варьируются от 0 до 16 (Bool, String, Int, DateTime и т. Д.)). Я получил Typecodes от 97 до 254? Кто-нибудь знает, что происходит не так? Я думаю, что это как-то связано с шифрованием. Поскольку десериализатор работает нормально без шифрования. Я использую правильный отступ / режим / клавиша?

Я использовал: http://code.google.com/p/as3crypto/ как библиотеку шифрования / дешифрования as3. И я написал асинхронный tcp сервер с некоторым злоупотреблением пулом потоков;)

В любом случае вот какой-то код:

C # код инициализации шифратора 

System.Security.Cryptography.DESCryptoServiceProvider crypter = new DESCryptoServiceProvider();

crypter.Padding = PaddingMode.Zeros;
crypter.Mode = CipherMode.CBC;
crypter.Key = Encoding.ASCII.GetBytes("TESTTEST");

AS3 

private static var _KEY:ByteArray = Hex.toArray(Hex.fromString("TESTTEST"));
private static var _TYPE:String = "des-cbc";

public static function encrypt(array:ByteArray):ByteArray
{
 var pad:IPad = new NullPad;
 var mode:ICipher = Crypto.getCipher(_TYPE, _KEY, pad);

 pad.setBlockSize(mode.getBlockSize());
 mode.encrypt(array);

 return array;
}

public static function decrypt(array:ByteArray):ByteArray
{
 var pad:IPad = new NullPad;
 var mode:ICipher = Crypto.getCipher(_TYPE, _KEY, pad);

 pad.setBlockSize(mode.getBlockSize());
 mode.decrypt(array);

 return array;
}

C # чтение / десериализация / дешифрование кода 

public override object Read(int length)
{
    object d;

    using (MemoryStream stream = new MemoryStream())
    {
    stream.Write(this._readBuffer, 0, length);
    stream.Position = 0;

    if (this.Decrypter != null)
    {
        using (CryptoStream c = new CryptoStream(stream, this.Decrypter, CryptoStreamMode.Read))
        using (AmfReader reader = new AmfReader(c))
        {
        d = reader.ReadAmf3Object();
        }
    }
    else
    {
        using (AmfReader reader = new AmfReader(stream))
        {
        d = reader.ReadAmf3Object();
        }
    }           
    }

    return d;
}

Ответы [ 2 ]

1 голос
/ 05 апреля 2010

Определить «безопасный».

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

Если в наши дни люди используют DES, то это Triple DES, который по сути запускает DES три раза для каждого блока данных.

В наши дни алгоритм симметричного шифрования (которым является DES) является AES, который похож на духовного преемника DES.

AES с достаточно большим ключом 256 (на самом деле сегодня 512 или выше) криптографически безопасен для большинства приложений.

Несколько предостережений AES:

  1. Это по-прежнему ограничено экспортным контролем США
  2. АНБ может расшифровать вашу информацию, если они хотят (да это жесть мышление)

Что касается вашей ошибки, сначала попробуйте переключиться на AES и посмотрите, не возникла ли у вас проблема.

Относительно AES:

Важен выбор ключа, а также защита ключа.

Выбор ключа

Если вы хотите «защитить паролем» свои данные, используя AES, то вам необходимо преобразовать свой пароль в ключ AES. Это распространенная ошибка для многих разработчиков компьютерной безопасности. Adobe по существу уничтожил всю защиту AES в своих PDF-файлах, используя в качестве ключа хеш-пароль MD5 пользователя. Излишне говорить, что вы умнее всех инженеров Adobe вместе взятых, поэтому вы не совершите эту ошибку.

Правильный способ генерации ключа из пароля - это использование RFC2898 или PBKD2 (функция получения ключа на основе пароля). В .NET удобно есть метод, который делает это: Rfc2898DeriveBytes (). По сути, это криптографически надежно хэширует ваш пароль, с предоставленной солью (подробнее об этом немного), несколько раз, предоставленной пользователем. Это обеспечивает несколько уровней защиты от атак с использованием грубой силы против вашего пароля (при условии, что ваш ключ достаточно велик, чтобы предотвратить атаки с использованием грубой силы!)

  1. Каждая итерация PBKD2 занимает минимальное количество времени для запуска. Чем больше у вас интерактивности (я думаю, что рекомендуемое число> 1000), тем больше компьютерного времени требуется. Это время все еще меньше, чем человек мог бы распознать, но в компьютерное время это похоже на столетие. Таким образом, не зная точного количества итераций, это делает очень длительный процесс взлома паролем.

  2. Соль. Вместо прямого хеширования вашего пароля, соль добавляет дополнительную информацию к вашему входному паролю, создавая уникальный хеш. Это предотвращает атаки радужного стола, если вы сохраняете свою ценность соли защищенной.

Хранение ключей

Другая сторона криптографии - хранилище ключей. Если вы защищаете свои данные паролем, вам необходимо надежно сохранить пароль. Самый простой способ - использовать встроенную безопасность ОС. В Windows это использует DPAPI в реестре и Unix, filepermissions.

AES в качестве ключа сеанса

Если вы ищете безопасную передачу данных по небезопасному каналу (или даже добавляете свою собственную дополнительную защиту поверх SSL), вы можете рассмотреть возможность использования AES в качестве шифрования сеанса.

По сути, это система шифрования с двумя схемами, которая работает следующим образом:

Вы генерируете пару открытый / закрытый ключ, используя ваше любимое ассиметричное шифрование (RSA!) Для вашего сервера. Каждому доверенному клиенту предоставляется открытый ключ. Во время сеанса клиент генерирует новый случайный ключ AES 256 бит или выше. Этот ключ сеанса AES зашифрован с использованием открытого ключа RSA. Эти зашифрованные данные, содержащие сеансовый ключ AES, отправляются на сервер. Сервер расшифровывает данные, используя свой закрытый ключ RSA, и сохраняет ключ сеанса AES. В течение оставшейся части сеанса все данные шифруются с помощью ключа AES сеанса. В конце сеанса ключ AES сбрасывается.

Хотя это требует большего количества рукопожатий, это дает вам дополнительную защиту от ограничения воздействия.Поскольку ключ AES хорош только для сеанса, если он обнаружен, ущерб ограничивается только одним сеансом.

0 голосов
/ 05 апреля 2010

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

Лично я бы использовал RC4, если вам действительно нужно использовать потоковый шифр; это очень быстро Здесь есть хорошая реализация http://dotnet -snippets.com / dns / rc4-encryption-SID577.aspx

Есть несколько очень важных предостережений, о которых следует помнить при использовании потоковых шифров:

1) НИКОГДА повторно использовать ключ шифрования с потоковым шифром.

2) Поскольку вы шифруете один байт за раз, трудно определить, были ли данные подделаны, поэтому вам необходимо добавить цифровую подпись или HMAC в поток.

...