| 1.4, Аркагоблин (?), 21:39, 28/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> Код поставляется под собственной разрешительной лицензией, разрешающей ... без ограничений
Ну не сказать чтобы без ограничений. Она похожа на Apache 2.0, только ещё больше бюрократическая. Без ограничений - это 0BSD или MIT-0 например
| | |
| 1.13, Аноним (-), 23:04, 28/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Почитал изложенное в https://gitflic.ru/project/red-stars-systems/crypto-gost/blob?file=README.md
1) Автор библиотеке демонстрирует определённую вменяемость и знакомство с рядом техник, которыми создаётся такой софт. Поскольку существует множество требований, которым должна соответствовать библиотека реализующая крипто-примитивы или режимы шифрования с помощью таковых.
2) Это не похоже на студента решившего написать pet-project'ом нечто такое, что вынудило бы разобраться с ГОСТ-овой критографией. Однако, надо смотреть кодовую базу, красивы и праведные слова в README.md в зачёт не идут.
3) Тесты на корректность работы (кросс-валидация) якобы проводились в наиболее официальном окружении из возможных (OpenSSL 3.3.x с ГОСТ-провайдером в AltLinux p11). Это важно, т.к. финтех (банки) в нескольких регионах РФ очень плотно использует именно AltLinux (чуть ли не поголовно).
Однако, внимание на тесты реализации ГОСТ Р 34.10-2012.
• Производительность: на двух видах кривых (256 и 512).
• Валидация с BouncyCastle: все семь кривых.
• Валидация с OpenSSL (ГОСТ): три кривых.
Т.е. отсутствует валидация с кривыми TC26-A-256, TC26-A-512, TC26-B-512, TC26-C-512
В целом очень неплохо. Видимо в РФ будет TLS 1.3 через MGM, что лучше нежели GCM :)
| | |
| |
| 2.22, Аноним83 (?), 02:38, 29/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это Бернштейн нагонял, чтобы продвинуть свою ED25519 вместо ECDSA.
ECDSA в принципе очень трудно сделать за постоянное время, и это сильно уронит производительность, ибо придётся выкинуть кучу оптимизаций в математике.
| | |
| |
| 3.27, Аноним (-), 03:49, 29/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Это Бернштейн нагонял, чтобы продвинуть свою ED25519 вместо ECDSA.
ЧСВ Бернштейн в отличие от экспертов опеннета - криптограф. И так то, дорогой эксперт,
1) Он в основном продвигал 25519, не в эдвардовской версии, как DH-like key exchange в основном. Для начала. Хотя оно достаточно близко, но это разные штуки. Хотя кого волнует что эдвардовские координаты в обычные конвертить надо, эт ж опеннет, главное что-нибудь "умное" сказать. Например можно блеснуть отличным "знанием" крипто.
2) Внезапно ED25519 - тоже ECDSA. Как странно! Ибо ECDSA означает "Elliptic Curve Digital Signature Algorithm". Под это определение попадает много чего. Включая ED25519. Ну так, небольшая ремарка по теме. Т.е. эксперт по крипто буквально рассказал нам про пчел против меда...
3) Почему-то DJB смог. А остальные видите ли не могут. Все что он сделал - написал базовые операции на кривых правильно. Если для кого-то это рокетсайнс, может, ему просто не надо свои кривые лапки в крипто совать?
4) По части постоянного времени DJB и в обычном крипто - заморочился. Потому что утечка клчевого материала и симметричное крипто может нагнуть на отлично. Если вместо взлома 256 бит ключа удалось его угадать по косвенным признакам - сами понимаете, драматическая разница в сложности атаки. Брутфорсом симметричные 256 бит даже на квантах - тухляк. А если тут такое упрощение, что померял времянки, статы набрал, множество вероятных ключей стало обозримым - это ДРУГОООООЕ! Так что да - salsa/chacha имеет некое преимущество над AES в этом смысле. И над сабжем, ага. И кстати salsa/chacha достаточно просты чтоб накодить их по формальным спекам. Даже попроще AES так то. И грабель при usage - поменьше, в общем случае. Собственно для этого профессионализм криптографа и требуется. Сделать удачную конструкцию с хорошими свойствами, понятную в использовании и без глупых прострелов пяток на ровном месте.
| | |
|
| 2.25, Аноним (-), 02:52, 29/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> А как на Java можно реализовать криптографию, как обеспечивается защита от того,
> чтобы в успешном и не успешном случае код бы выполнялся одинаковое время
Путем покладания х... на проблему. Учитывая что секурность этого алго вообще ниоткуда не следует ибо малоизученный недоспецифицированный зверек, это явно не хучшая из ваших проблем.
К тому же оно само по себе так структурировано что фиксированых таймингов не будет иметь даже в хороших реализациях. Ну типа как с AES современным. Хотя на жабе это конечно специальный перк, будет круто если оно будет инфо о ключе течь по side channel в неожиданном объеме.
| | |
|
| 1.17, Tron is Whistling (?), 23:15, 28/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
А на фига оно вообще в глобальном масштабе надо, с учётом того, что в этом счастье предопределённые блоки подстановок - алгоритмические, и фиг его знает какие дыры в них зарыты?
| | |
| |
| |
| 3.26, Аноним (6), 03:20, 29/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Так вы почитайте про их криптостойкость (*на вики со ссылками на исследования).
| | |
|
|
| 1.18, Аноним (18), 23:22, 28/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Жаль что код опять явно с помощью нейронок написан. Я уж думал хоть такие серьезные проекты люди пишут сами.
| | |
| |
| 2.29, Аноним (29), 04:46, 29/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Так людишки уже всё, того. Сейчас все, кроме си-шных дидов, пишут нейронками в основном. Просыпаемся.
| | |
|
| 1.21, Аноним (21), 01:23, 29/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>повышена производительность шифрования алгоритмом "Кузнечик",
За счёт официально недокументированной структуры?
>red-stars-something
Это для Red Star OS? Ну логично, нас скоро до уровня КНДР опустят.
| | |
| 1.24, Аноним83 (?), 02:39, 29/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> ГОСТ Р 34.10-2012 (RFC 7091) - электронная подпись 256 и 512 бит.
Представляю как знатно тормозит реализация на джава :)
У меня на С пришлось кучу усилий приложить чтобы оно шустро работало.
| | |
|
