Насколько мне известно, на JS Noise еще никто не сделал. Можете стать первым ) Спека самого нойза приятно читается и реализовывать её одно удовольствие. Пока поддерживается только C, Java, Go, Haskell и Rust.
Мы можем не смочь прочитать первый payload, потому что там могут быть
1) разные кривые, хэши и алгоритмы
2) Noise_IK, у которого payload сразу зашифрован
мы должны знать паттерн и алгоритмы заранее, иначе ничего не прочитается. NN конечно можно было бы сделать, но это лишний раундтрип и нагрузка на CPU.
Есть-то оно есть, но во-первых там, условно, «AES», я ничего не нашел про нормальную ассиметричную криптографию. Во-вторых на беспроводным IoT мир не заканчивается, есть еще PLC и там тоже нужна защита
пролог! Это не negotiation_data, это, условно, строка, которую мы скармливаем фреймворку, чтобы состояние на обоих концах было одинаковое. Её передавать не нужно, её нужно сконкатенировать
Ну не Ascii, просто данные в открытом виде. Но ведь нужно как то согласовать используемые алгоритмы пока еще не было никакого обмена ключами. Можно этого и не делать, если вы заранее знаете что к вам придёт. А иначе как?
Кроме одноразового блокнота ни один из алгоритмов не имеет 100% доказательства стойкости, по сути мы все верим криптографам на слово. Я это имел в виду
Ну и раз уж на то пошло, то транспортный пакет — это всего лишь AEAD шифротекст с длиной спереди. Да, в либах этого нет, но по сути можно делать эти шифротексты хоть по гигабайту размером и спереди писать не 2, а 3 или 4 байта длины. Как вы можете видеть, NoiseSocket больше концепция, а не законченный протокол.
Вон оно что, я сразу не понял вопроса. Потому что IoTшники наборот хотят, чтобы пакет был не больше 2х кб, например.
Вообще да, разбивать придется в любом случае, т.к. подразумевается что мы там и гигабайты можем слать. Это не так уж и сложно, вполне соответствует семантике ReadXXX/WriteXXX. Вот как я например сделал в go
А читать из этого коннекшена и писать в него можно буферами любого размера.
Спецификация протокола позволяет писать друг другу любые данные во время хэндшейка внутри полезной нагрузки. Можно добавить туда максимальный размер пакета и учитывать его во время транспортной фазы.
Справедливо. Но тут так же работает презумция невиновности. По ссылке есть критерии слабых кривых, 25519 под них очевидно не подходит. Если есть какие то другие критерии, то они ударят не только по ней, но скорее и по всем остальным
А это на самом деле легко делается, можно о размере пакета договориться во время хэндшейка. В спеку не вошло, но никто не мешает сделать самому. Мы тоже скоро выложим «наш» вариант NoiseSocket, возможно там появится в том числе и ограничение на размер пакета
Это не «какая-то еще одна кривая», а вполне себе обычная кривая монтгомери, у которой порядок — простое число 2255 — 19. Одного этого факта достаточно, чтобы утверждать о её безопасности. Есть конечно слабые кривые, но их довольно просто вычислить. Вот еще доп информация на этот счет
1) разные кривые, хэши и алгоритмы
2) Noise_IK, у которого payload сразу зашифрован
мы должны знать паттерн и алгоритмы заранее, иначе ничего не прочитается. NN конечно можно было бы сделать, но это лишний раундтрип и нагрузка на CPU.
Заходите в Noise Mailing List, там можно это дальше обсудить
Вообще да, разбивать придется в любом случае, т.к. подразумевается что мы там и гигабайты можем слать. Это не так уж и сложно, вполне соответствует семантике ReadXXX/WriteXXX. Вот как я например сделал в go
А читать из этого коннекшена и писать в него можно буферами любого размера.