Большое спасибо за неугасающий интерес.
Действительно, когда речь заходит о сервисе предоставляющим криптографические услуги, вопрос доверия встает ребром. Понимая это, мы пытаемся как можно дальше дистанцироваться от такой вещи как управление ключами. Все приватные ключи генерируются исключительно на стороне клиентов, так что мы не можем прочитать ни одно зашифрованное сообщение.
Кроме того, мы дали возможность нашим клиентам самостоятельно подтверждать ключи пользователей(подписав их своим секретным ключом), что избавит нас от возможности подмены публичных ключей. Одним словом мы постарались сделать так, чтобы ваше доверие не было беспочвенным.
Что касается нашей криптобиблиотеки, она выложена в открытом доступе. Любой желающий может провести аудит на предмет бэкдоров и потенциальных уязвимостей. Как видите, с этой стороны доверие тоже подлежит проверке.
Да, конечно, в случае форс мажора мы можем отозвать ключи. И тогда мессенджер перестанет функционировать, но давайте начистоту, от непредсказуемых ситуаций никто не застрахован. Тоже самое можно сказать про абсолютно любой сервис и услугу, вы же не будете отказываться от удобств интернета из за риска его отключения?
А чего у вас в ключах и зашифрованном сообщении так много «AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA»?
Публичный ключ представляет собой точку эллиптической кривой. В edDSA точки представлены координатами Монтгомери. Т.е. имеет значение только x-координата, y-координата представляется последовательностью нулей, которые и отображаются вот в таком пугающем виде.
И публичный ключ как то много приватного содержит в конце.
На самом деле это приватный ключ содержит слишком много публичного:)
В rfc5915 прописана структура приватного ключа, в котором должно быть поле PublicKey.
1. Нет, pgp не поддерживается (мы используем ECIES).
2. Нет, не будет, поскольку в сборке под Android отсутствуют нативные библиотеки под десктопные платформы (Windows, Linux, Mac os). Для не-Андроид рекомендуется использовать Virgil Client.
4. Зависимостей на Java security нет, мы используем собственную библиотеку Crypto. Нативные библиотеки упакованы в JAR, так что нет необходимости что-либо доставлять.
Здравствуйте!
Прежде всего позвольте поблагодарить за развернутый комментарий. Мы очень хорошо относимся к аргументированной критике и одной из причин нашего появления на Хабре было как раз таки желание выслашать как можно больше точек зрения.
Совсем не так. Хоть это и прозвучит как тавтология, но безопасность должна в первую очередь быть именно БЕЗОПАСНОЙ. Ни удобной, ни кроссплатформенной, ни какой либо ещё, а именно безопасной.
Вы совершенно правы. Безопасность не имеет пограничных состояний. Безопасность либо есть либо ее, простите, нет. Но скажите, разве удобство системы снижает вероятность ее безопасности? Мы уверены что одно не противоречит другому и стремимся достичь двух различных целей: безопасность наших решений и простота и удобство их использования. Обратите внимание, мы предлагаем вовсе не «черный ящик». Все наши протоколы и исходные коды совершенно открыты.
Много людей проверяют код той-же OpenSSL?
Пример OpenSSL в этом плане весьма показателен. Благодаря открытому исходному коду исследователям удалось найти не одну критическую уязвимость: раз, два, три.
В шифровании кода должно быть мало, очень мало. Нужно стремиться сделать только самый необходимый минимум возможностей, режимов и т.д.
И в этом вашем утверждении все совершенно правильно, поэтому наша криптобиблиотека содержит тот самый необходимым минимум, о котором вы говорите. А большое количество SDK делают возможным использование этого минимума на разных языках и платформах.
Использование элиптики это спорное решение.
У криптографии на эллиптических кривых есть большое преимущество, связанное с размерами ключей и подписи. Для обеспечения приемлемого уровня стойкости в 128 бит вам потребуется 3072 битный RSA ключ или 256 битный ECDSA. Принимая во внимание закон Мура можно сказать, что использование RSA может оказаться в будущем слишком хлопотным делом.
Зачем? Алгоритм или надёжный, тогда меняют только ключи, или нет, тогда зачем он нужен?
Нужно принимать во внимание, что надежный сегодня алгоритм, завтра может оказаться фатально уязвимым.
я лично против вас ничего не имею, но обоснованно не доверяю никому кто обещает мне решить мои проблемы, особенно в сфере безопасности, за просто так.
И это абсолютно правильно! Мы сами никому не доверяем, поэтому и создали свой собственный сервис с блэкджеком и Curve25519:) Мы и не хотим, чтобы нам доверяли. Вы вполне можете использовать наш PKI, но при никогда не предавать нам своих приватных ключей. Более того, при этом вы можете даже подписывать ключи своей собственной реализацией RSA и отвергать все ключи лишенные вашей подписи.
Вопросы более, чем приветствуются и мы рады вашему интересу.
Что касается Pricing, как видите, на данный момент все бесплатно и в открытом доступе наш код. Но у нас, безусловно, есть Terms of Service и Privacy Policy.
В Curve25519 конечно же!
Действительно, когда речь заходит о сервисе предоставляющим криптографические услуги, вопрос доверия встает ребром. Понимая это, мы пытаемся как можно дальше дистанцироваться от такой вещи как управление ключами. Все приватные ключи генерируются исключительно на стороне клиентов, так что мы не можем прочитать ни одно зашифрованное сообщение.
Кроме того, мы дали возможность нашим клиентам самостоятельно подтверждать ключи пользователей(подписав их своим секретным ключом), что избавит нас от возможности подмены публичных ключей. Одним словом мы постарались сделать так, чтобы ваше доверие не было беспочвенным.
Что касается нашей криптобиблиотеки, она выложена в открытом доступе. Любой желающий может провести аудит на предмет бэкдоров и потенциальных уязвимостей. Как видите, с этой стороны доверие тоже подлежит проверке.
Да, конечно, в случае форс мажора мы можем отозвать ключи. И тогда мессенджер перестанет функционировать, но давайте начистоту, от непредсказуемых ситуаций никто не застрахован. Тоже самое можно сказать про абсолютно любой сервис и услугу, вы же не будете отказываться от удобств интернета из за риска его отключения?
Публичный ключ представляет собой точку эллиптической кривой. В edDSA точки представлены координатами Монтгомери. Т.е. имеет значение только x-координата, y-координата представляется последовательностью нулей, которые и отображаются вот в таком пугающем виде.
На самом деле это приватный ключ содержит слишком много публичного:)
В rfc5915 прописана структура приватного ключа, в котором должно быть поле PublicKey.
1. Нет, pgp не поддерживается (мы используем ECIES).
2. Нет, не будет, поскольку в сборке под Android отсутствуют нативные библиотеки под десктопные платформы (Windows, Linux, Mac os). Для не-Андроид рекомендуется использовать Virgil Client.
4. Зависимостей на Java security нет, мы используем собственную библиотеку Crypto. Нативные библиотеки упакованы в JAR, так что нет необходимости что-либо доставлять.
Прежде всего позвольте поблагодарить за развернутый комментарий. Мы очень хорошо относимся к аргументированной критике и одной из причин нашего появления на Хабре было как раз таки желание выслашать как можно больше точек зрения.
Вы совершенно правы. Безопасность не имеет пограничных состояний. Безопасность либо есть либо ее, простите, нет. Но скажите, разве удобство системы снижает вероятность ее безопасности? Мы уверены что одно не противоречит другому и стремимся достичь двух различных целей: безопасность наших решений и простота и удобство их использования. Обратите внимание, мы предлагаем вовсе не «черный ящик». Все наши протоколы и исходные коды совершенно открыты.
Пример OpenSSL в этом плане весьма показателен. Благодаря открытому исходному коду исследователям удалось найти не одну критическую уязвимость: раз, два, три.
И в этом вашем утверждении все совершенно правильно, поэтому наша криптобиблиотека содержит тот самый необходимым минимум, о котором вы говорите. А большое количество SDK делают возможным использование этого минимума на разных языках и платформах.
У криптографии на эллиптических кривых есть большое преимущество, связанное с размерами ключей и подписи. Для обеспечения приемлемого уровня стойкости в 128 бит вам потребуется 3072 битный RSA ключ или 256 битный ECDSA. Принимая во внимание закон Мура можно сказать, что использование RSA может оказаться в будущем слишком хлопотным делом.
Нужно принимать во внимание, что надежный сегодня алгоритм, завтра может оказаться фатально уязвимым.
И это абсолютно правильно! Мы сами никому не доверяем, поэтому и создали свой собственный сервис с блэкджеком и Curve25519:) Мы и не хотим, чтобы нам доверяли. Вы вполне можете использовать наш PKI, но при никогда не предавать нам своих приватных ключей. Более того, при этом вы можете даже подписывать ключи своей собственной реализацией RSA и отвергать все ключи лишенные вашей подписи.
Что касается Pricing, как видите, на данный момент все бесплатно и в открытом доступе наш код. Но у нас, безусловно, есть Terms of Service и Privacy Policy.