2013-02-13 2 views
3

Я пишу файловый сервер в Java на Windows, используя шифрование, которое устойчиво к алгоритму Shor.Java TLS, который не зависит от DLP или простой факторизации

Мой камнем преткновения является SSL/TLS. Из того, что я могу собрать, я не могу использовать стандартные java-библиотеки, поскольку шифрование сокетов использует обмен ключами Диффи-Хеллмана, который опирается на проблему дискретного логарифма.

Я изучил Salsa20, новый (ish) потоковый шифр, но проблема безопасного обмена ключами остается. Я также посмотрел на cyaSSL, но поставщик услуг Java не поддерживает окна, и использование C не является вариантом.

Может ли кто-нибудь указать направление?

+1

TLS в названии подразумевает использование стандартных процедур безопасности. Создание методов, устойчивых к КК, далеко не глупо по моему скромному мнению. –

+0

@CaptainGiraffe Исследование постквантового обмена ключами важно для ИМО. Я просто не буду его использовать. – CodesInChaos

+0

@CaptainGiraffe Это уникальный проект года (мы делаем большой проект вместо тезиса), поэтому это скорее доказательство концепции, чем то, что на самом деле будет иметь реальное использование в мире. – Saf

ответ

3

Есть два основных подхода:

  1. не Используйте предварительный общий ключ

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

  2. Используйте квантовое доказательство обмен ключами

    Для примера здесь является спецификация для NTRU (только проект, никакого реального стандарта, и остерегайтесь патентов)

    Но в целом асимметричной после квантовой криптографии похоже, не готово к производству.

+0

Ключевой размер может быть проблемой. Если Шор в игре, мы должны ожидать, что каждый другой метод взлома будет одинаково продвинут. ОТП будет нашим единственным спасителем. –

+0

@CaptainGiraffe Нет никаких указаний на то, что квантовый компьютер может сломать симметричный крипто с достаточно большими ключами (256 бит должен быть точным). Кажется маловероятным, что квантовый компьютер будет предлагать больше, чем половину эффективного размера ключа, используя альфа-альфа. – CodesInChaos

+0

Я очень сомневаюсь в рассмотрении квантовых вычислений. Хотя я знаком с алгоритмами, мое личное чувство заключается в том, что любая проблема с QC все еще находится в области [Pathological | NP]. Если только перейти на аппаратную часть. Также защищенная квантовая связь - это только ссылка. –

1

Перспектива мрачная.

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

Что касается подключения подписи GGH и Lamport в Java в качестве поставщика SSL, это еще одна проблема. Вам нужно будет узнать, как работает JCE, и много работы.

+1

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

Смежные вопросы