https://www.opennet.ru/openforum/vsluhforumID3/117696.html Дэмиен Миллер (djm @) добавил (https://marc.info/?l=openbsd-cvs&m=156109087822676&w=2) в OpenSSH улучшение, которое должно помочь защитить от различных атак по сторонним каналам, таким как Spectre, Meltdown (https://www.opennet.ru/opennews/art.shtml?num=47856), RowHammer (https://www.opennet.ru/opennews/art.shtml?num=41340) и RAMBleed (https://rambleed.com/). Добавленная защита призвана предотвратить восстановление приватного ключа, находящегося в оперативной памяти, пользуясь утечками данных по сторонним каналам.<br><br><br>Суть защиты в том, что приватные ключи, в моменты, когда они не используются, зашифровываются с помощью симметричного ключа, который получен из относительно большого &#171;предварительного ключа&#187; (prekey), состоящего из случайных данных (в настоящее время его размер - 16 КБ).<br>С точки зрения реализации, приватные ключи шифруются при загрузке в память, а затем автоматически и прозрачно расшифровываются при использовании для подписей или при сохранении/сериализации.<br><br><br>Для успешной атаки зло https://www.opennet.ru/openforum/vsluhforumID3/117696.html#11 Wed, 26 Jun 2019 23:44:09 GMT Ещё раз: в твоей схеме достаточно читать по одному байту из каждого блока и один байт из закрытого ключа чтобы восстановить один байт закрытого ключа.<br>Это как в вин98 xintruder пароль ломал на сетевую шару: венда ему сообщала сколько символов пароля введено правильно, в итоге время подбора пароля падало до смешних значений.<br>Не нужны никакие шифры, есть kdf для этого, вот только для этого. И легковестность всем побоку, впрочем нынче тот же sha1, sha2-256 уже аппаратный в райзенах, а aes-ni и вообще много где.<br> https://www.opennet.ru/openforum/vsluhforumID3/117696.html#10 Sun, 23 Jun 2019 14:31:43 GMT Впрочем, это была всего лишь быстрая идея, так чтобы сделать секретную информацию зависимой от всего первого буфера. Вместо xor можно использовать какой-нибудь легковесный шифр, типа speck (или aes, если аппаратное ускорение доступно), чтобы блок n-1 становился ключём для блока n, а результат - ключём для блока n+1.<br> https://www.opennet.ru/openforum/vsluhforumID3/117696.html#9 Sun, 23 Jun 2019 12:44:58 GMT &gt; атакующим может не спеша вычитывать по байту "мусор"[1234n] и потом "скрытый секрет" и получать один байт закрытого ключа.<br><br>Как? Ведь его содержимое постоянно меняется? И после каждого изменения то, что было прочитано раньше теряет смысл.<br><br>&gt; При этом после каждого расшифрования можно легко генерить новый одноразовый ключ на хх кб и им шифровать секретный.<br><br>Фишка-то как раз в том, что расшифровывание может быть процедурой редкой.<br> https://www.opennet.ru/openforum/vsluhforumID3/117696.html#8 Sun, 23 Jun 2019 00:21:56 GMT НУДНО!<br><br>Берём рандому на хх килобайт, пихаем в KDF, результат используем для шифрования и расшифрования секретного ключа в памяти.<br>При этом после каждого расшифрования можно легко генерить новый одноразовый ключ на хх кб и им шифровать секретный.<br><br>Твоя схема с ксором - очень плоха, вот почему:<br>атакующим может не спеша вычитывать по байту "мусор"[1234n] и потом "скрытый секрет" и получать один байт закрытого ключа.<br>Те ему не придётся собирать все 16к или сколько там мусора чтобы узнать хотя бы один байт ключа, в итоге скажем по байту в день/неделю ключ будет прочитан.<br> https://www.opennet.ru/openforum/vsluhforumID3/117696.html#7 Sat, 22 Jun 2019 21:35:59 GMT Подумал. И пока выходит что сложные схемы городить вообще нет смысла. Конечно это нарушает заповедь "не изобретать собственную криптографию", но одноразовый шифроблокнот видится мне достаточно простым и надёжным.<br><br>Шаг 1. Надо увеличть размер секретных данных, чтобы осложнить их извлечение по сторонним каналам. Для этого выделяем буфер в скажем 16 кб (размер взять из исходного поста), в конец помещаются секретные данные, а начало заполняется с crng. Теперь блоками равными длине секретных данных мы последовательно ксорим эти блоки, а в конце ксорим сами данные.<br><br>[мусор1][мусор2][мусор2]...[секрет] т.е. в итоге [скрытый секрет] = мусор1 ^ мусор 2 ^ мусор3 ^ ...<br><br>Т.е. мы добились того, что для чтения секретных данных нужно получить весь 16 к блок. На этот моменте не параноики могут и успокоиться. Просто достаточно вспомнить сколько времени потребуется на кражу такого объяма. А ведь можно увеличить длину буфера до 64 кб, мегабайта и т.д.<br><br>Но мы параноики.<br><br>Шаг 2. Выделяем второй буфер той же длины и запо https://www.opennet.ru/openforum/vsluhforumID3/117696.html#6 Sat, 22 Jun 2019 19:22:49 GMT Ну как, подумали?<br> https://www.opennet.ru/openforum/vsluhforumID3/117696.html#5 Sat, 22 Jun 2019 12:39:23 GMT Перешифровывать не обязательно, некоторые алгоритмы обладают частичной гомоморфностью. По идее можно покумекать и как-нибудь циклицески домножать (rsa вроде как раз гомоморфен к умножению) ключ и шифротекст на какое-нибудь значение, чтобы синхронно измменять их.<br><br>Надо будет подумать на досуге.<br> https://www.opennet.ru/openforum/vsluhforumID3/117696.html#4 Sat, 22 Jun 2019 11:20:40 GMT Надо еще по cron'у пинать сигналом на перешифрование новым ключом с частотой выше, чем можно вычитать<br> https://www.opennet.ru/openforum/vsluhforumID3/117696.html#3 Sat, 22 Jun 2019 08:20:52 GMT Там и без шифрования восстановить маловероятно<br>