Как стать автором
Обновить

Комментарии 10

Информацию можно зашифровать приватным ключом, а расшифровать публичным. Но зашифровать публичным нельзя.
Ошибаетесь. Зашифровать публичным ключом можно — и зашифрованное публичным ключом дешифруется только приватным ключом.

Если шифровать приватным ключом — это «электронная подпись»: любой может дешифровать общедоступным публичным ключом и удостовериться, что шифровал именно владелец приватного ключа.

Если шифровать публичным ключом — это собственно шифрование: прочитать зашифрованное может только владелец приватного ключа.
Определение дал в контексте статьи. Конечно, полное определение будет значительно больше, но для статьи этого не нужно. Немного исправил определение

Где же вы исправили - у вас по-прежнему этот каламбур написан. Этот настолько же бессмысленно, как предложить такую конструкцию сейфа, что ключ для его открывания есть у каждого прохожего.

Тут можно сочинить немало способов борьбы с этим. Возможно в комментариях подскажут ещё какие-то. Но например: можно хранить ключ в шифрованном виде и расшифровывать его только при использовании. Можно шифровать БД отдельным ключом так что злоумышленнику понадобится вычислить ещё и этот ключ. Можно хранить ключи тоже в DHT и менять их периодически или на сайте. Способов столько на сколько фантазия богата. Поэтому нельзя точно сказать, что это уязвимость.
Все перечисленные способы хранения ключей доступны злоумышленнику. Так что это уязвимость.

Единственный способ использовать DHT как вы хотите безопасно, это если правами PUT будет обладать один клиент, а правами GET все остальные.
Много буковок, а вот кода 0.

Есть распределенная бд на ipfs

вы не можете сделать так, чтобы пользователь, располагая программой, мог пользоваться приватным ключом, но не мог его извлечь. Точнее, целая индустрия DRM посвящена этой проблеме, и пока что не совсем успешно. В opensource-же проектах это тривиально невозможно (т.к. исходный текст доступен).

Желаю вам удачи во взломе подобных систем.

Каких именно?


apt-get source deluge или apt-get source transmission`?

Способов столько на сколько фантазия богата.

Только ни один не защищает...

Можно получить отдалённое приближение, используя цепочку доверенности, начиная с железа: допустим, есть TPM-чип или read-only прошивка, которые при загрузке ОС проверяют цифровой подписью или хешами целостность ОС, а сама ОС, в свою очередь, должна быть устроена так, чтобы разрешать общаться с вашим сервисом только подписанным приложениям. Но это по-прежнему только полрешения, потому что этим мы только отсекли "недоверенный код на доверенных устройствах". Для устранения "недоверенный код на недоверенных устройствах" понадобится ещё, например, снова положиться на TPM и аутентифицировать устройство с помощью зашитого в него ключа. Всё это в сумме даёт хоть как-то безопасное решение, хотя и оно полагается только на то, что взломать TPM затратно по времени и усилиям.

То, что получилось - называется remote attestation. Дело за малым - обеспечить лэптопы TPM-чипами, своей OS и клиент-серверной архитектурой для протокола remote attestation. Дополнительно ещё парочку слоёв крипографии для обеспечения не только безопасности, но и хоть какого-то уровня анонимности.

Кто-то всё это получившееся может потянуть (см. статью в IEEE "On Remote Attestation for Google Chrome OS"), ну а та защита, что описана тут в хабростатье - это детский лепет какой-то...

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории