Комментарии 10
НЛО прилетело и опубликовало эту надпись здесь
Большое спасибо за неугасающий интерес.
Действительно, когда речь заходит о сервисе предоставляющим криптографические услуги, вопрос доверия встает ребром. Понимая это, мы пытаемся как можно дальше дистанцироваться от такой вещи как управление ключами. Все приватные ключи генерируются исключительно на стороне клиентов, так что мы не можем прочитать ни одно зашифрованное сообщение.
Кроме того, мы дали возможность нашим клиентам самостоятельно подтверждать ключи пользователей(подписав их своим секретным ключом), что избавит нас от возможности подмены публичных ключей. Одним словом мы постарались сделать так, чтобы ваше доверие не было беспочвенным.
Что касается нашей криптобиблиотеки, она выложена в открытом доступе. Любой желающий может провести аудит на предмет бэкдоров и потенциальных уязвимостей. Как видите, с этой стороны доверие тоже подлежит проверке.
Да, конечно, в случае форс мажора мы можем отозвать ключи. И тогда мессенджер перестанет функционировать, но давайте начистоту, от непредсказуемых ситуаций никто не застрахован. Тоже самое можно сказать про абсолютно любой сервис и услугу, вы же не будете отказываться от удобств интернета из за риска его отключения?
Публичный ключ представляет собой точку эллиптической кривой. В edDSA точки представлены координатами Монтгомери. Т.е. имеет значение только x-координата, y-координата представляется последовательностью нулей, которые и отображаются вот в таком пугающем виде.
На самом деле это приватный ключ содержит слишком много публичного:)
В rfc5915 прописана структура приватного ключа, в котором должно быть поле PublicKey.
Действительно, когда речь заходит о сервисе предоставляющим криптографические услуги, вопрос доверия встает ребром. Понимая это, мы пытаемся как можно дальше дистанцироваться от такой вещи как управление ключами. Все приватные ключи генерируются исключительно на стороне клиентов, так что мы не можем прочитать ни одно зашифрованное сообщение.
Кроме того, мы дали возможность нашим клиентам самостоятельно подтверждать ключи пользователей(подписав их своим секретным ключом), что избавит нас от возможности подмены публичных ключей. Одним словом мы постарались сделать так, чтобы ваше доверие не было беспочвенным.
Что касается нашей криптобиблиотеки, она выложена в открытом доступе. Любой желающий может провести аудит на предмет бэкдоров и потенциальных уязвимостей. Как видите, с этой стороны доверие тоже подлежит проверке.
Да, конечно, в случае форс мажора мы можем отозвать ключи. И тогда мессенджер перестанет функционировать, но давайте начистоту, от непредсказуемых ситуаций никто не застрахован. Тоже самое можно сказать про абсолютно любой сервис и услугу, вы же не будете отказываться от удобств интернета из за риска его отключения?
А чего у вас в ключах и зашифрованном сообщении так много «AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA»?
Публичный ключ представляет собой точку эллиптической кривой. В edDSA точки представлены координатами Монтгомери. Т.е. имеет значение только x-координата, y-координата представляется последовательностью нулей, которые и отображаются вот в таком пугающем виде.
И публичный ключ как то много приватного содержит в конце.
На самом деле это приватный ключ содержит слишком много публичного:)
В rfc5915 прописана структура приватного ключа, в котором должно быть поле PublicKey.
В edDSA точки представлены
В Curve25519 конечно же!
НЛО прилетело и опубликовало эту надпись здесь
Если координата Х не нужна то зачем её писать?
Используется представление точки на эллиптической кривой в байтовой последовательности без сжатия
SEC 1 Ver. 2.0 см. секцию "2.3.3 Elliptic-Curve-Point-to-Octet-String Conversion"
А если пишите то почему не писать реальные значения?
Пишется на самом деле реальное зачине, просто для Curve25519 оно всегда равно нулю.
Почему в зашифрованном сообщении много AAAA последовательностей?
Зашифрованное сообщение хранит в себе открытую часть эфемерного ключа, который генерируется в соответствии с алгоритмом ECIES, а раз так, то "AAAA" попадают и туда.
Аутентификация сообщений отсутствует?
Аутентификация сообщения обеспечивается режимом GCM алгоритма AES
Здорово, что кто-то пытается сделать простую и удобную криптографию. По поводу вашего API: получается у пользователя может быть несколько Virgil Cards для одного и того же «identity»? Как тогда оправляющая сторона поймёт какой публичный ключ использовать?
И ещё один вопрос из-за которого Я не могу спокойно спать: почему Python 2.7? Вы же не Dropbox! Вы же можете писать под Python 3.x ))
И ещё один вопрос из-за которого Я не могу спокойно спать: почему Python 2.7? Вы же не Dropbox! Вы же можете писать под Python 3.x ))
Ой, про Python снимается вопрос (Я не туда посмотрел в PyPI). Bitte entschuldigen :)
Спасибо, это действительно хороший вопрос, на самом деле все зависит от конкретной задачи. Бывает так, что в приложении требуется несколько одновременно активных публичных ключей. И мы сделали так, что разработчик в праве сам решать, сколько ключей пользователь может иметь в рамках своего приложения.
Так же ничего не мешает отправителю зашифровать данные для нескольких публичных ключей получателя, основываясь на данных в Virgil Card. Мы постарались не ограничивать разработчика в полете его фантазий :)
Поддержка у twilio работает, как бы это помягче сказать, — сомнительно.
Клиент просил настроить SIP trunk на CISCO ISR именно через этот сервис. Вылезла проблема — исходящие звонки идут, а входящие не поступают, хотя регистрация висит.
Создал тикет в поддержку: оборудование такое-то, проблема такая-то, дайте дебаги. На следующий день (через 23 часа) приходит ответ — А что у тебя, мил человек, за оборудование и АТС? И вообще — кури мануалы. На мое, резонное, отвеченное сразу, — уже курил, ответ пришел через _10_ дней: извинились за задержку и сообщили, что не видят от меня попыток регистрации (к этому времени подключил клиента к другому провайдеру, у которого все завелось с первого раза).
Может это, конечно, только что касается SIP trunk'ов, но осадочек остался.
Клиент просил настроить SIP trunk на CISCO ISR именно через этот сервис. Вылезла проблема — исходящие звонки идут, а входящие не поступают, хотя регистрация висит.
Создал тикет в поддержку: оборудование такое-то, проблема такая-то, дайте дебаги. На следующий день (через 23 часа) приходит ответ — А что у тебя, мил человек, за оборудование и АТС? И вообще — кури мануалы. На мое, резонное, отвеченное сразу, — уже курил, ответ пришел через _10_ дней: извинились за задержку и сообщили, что не видят от меня попыток регистрации (к этому времени подключил клиента к другому провайдеру, у которого все завелось с первого раза).
Может это, конечно, только что касается SIP trunk'ов, но осадочек остался.
А мне с twilio на Tele2 СМС приходят бывает через 3 дня. У нас там алертилка настроена, иногда получаю сообщения о падении серверов много после того, как их уже подняли
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создаем безопасный IP мессенджер с помощью Virgil и Twilio за 30 минут