AES256-GCM + IPSEC + AES-NI = fail?

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

Да, я тоже думал, но нет. Dmcrypt блочные устройства шифрует на ура с любой длиной ключа. Похоже это именно ограничение режима GCM

в режиме GCM

А какая там скорость в сравнении с другими вариантами? И да - intel AES требует или нет? В линуксе есть поддержка этого режима?

Ну собсно про линукс речь и идёт))

AES-NI требуется опционально, работает и без него, но скорость сильно падает.

Судя по вот этот бумажульке http://download.intel.com/design/intarch/papers/324238.pdf у них получилось на процах 2010 года выжать почти 10Гбит шифрования. Там помимо AES-NI требуется еще PCLMULQDQ для ускорения самого режима GCM.

На реальном железе у меня проверить пока не получилось, но на виртуалках (в хостах процы X5650) с 4 процами в каждой 1.3Гбит/сек шифрует на ура, алгоритм aes128gcm128 в strongswan.

Так 1.3Гбита это с AES-NI или без?

И я так и не понял, GCM (с таким приростом скорости, как у тебя) требует поддержки аппаратного AES процом или нет? Т.е. можно ли получить на старых i5/i7 без AES-NI такую же производительность или нет?

Это с AES-NI. Без него я думаю реально получить где-то 400-500Мбит на реальном железе. См. интелевскую пдфку, там есть графики.

А есть ли алгоритмы в разы быстрее AES, но менее стойкие? DES не предлагать, т.к. в реальности (в текущей реализации в линуксе) он медленнее AES. 3DES ещё медленнее.

Косяк в том, что в режиме GCM

*facepalm.png*

Иногда все-таки полезно учить матчасть. Хоть иногда, блин.

А есть ли алгоритмы

Есть. Только не блочные. Например, проект eSTREAM c портфелем потоковых шифров (4 «программных», 3 «аппаратных»).

Хотя за реализацией нужен глаз да глаз. Как только один ключ используется на паре разных наборов данных - все, карета превращается в тыкву.

Нужно как-раз для шифрования высокоскоростных туннелей (vpn). Есть ли у них для этого готовый клиент-сервер?

И что не так топикстартер сказал про режим?

Есть ли у них для этого готовый клиент-сервер?

Реализации HC-128 и RABBIT есть в CyaSSL. Но ИМХО что для TLS, что для IKE нет RFC, определяющих стандартные криптонаборы.

Какие-то алгоритмы eSTREAM реализованы в ядре (сейчас нет под рукой, чтобы посмотреть какие именно).

И что не так топикстартер сказал про режим?

Размер блока у GCM - 128 бит ;)

Надо внимательнее читать сообщение. Про размер блока я ничего не писал, а писал про размер ключа шифрования.

Strongswan поддерживает режимы aes{128,192,256}gcm{64,96,128}, где первое число - размер ключа, а второе число - размер ICV.

И еще раз - без AES-NI всё работает с любой длиной ключа, с ним - только 128.

Strongswan поддерживает режимы

Действительно, погорячился, прошу прощения.

без AES-NI всё работает с любой длиной ключа

Размер блока у GCM - 128 бит, т.е. на фазе 2 по-любому должен согласовываться 128-битный ключ. И, видимо, реализация которая использует AES-NI понимает aes256 «слишком буквально».