All streams
Search
Write a publication
Pull to refresh
4
0
Андрей @UncleAndy

User

Send message
Пишу еще раз — для данной конкретной задачи IM менеджера с защитой передаваемых данных, все можно сделать очень удобно для пользователей. Не сложнее чем в обычных IM менеджерах. В принципе, вообще всю работу с криптографией можно спрятать во внутренней логике приложения, так что пользователь с нею не будет иметь никакого дела.
А когда пользователи емэйлами обмениваются, они разве не понимают что именно они делают?
Думаю, многие мне позавидуют, т.к. я только сейчас приобрел Portal (т.к. он появился под Linux), а за ним и Protal 2 (второй еще не прошел до конца). Игрушки действительно уникальные. Странно почему я раньше не обращал на них внимания.
Вы знаете что такое идентификатор ключа и что такое сервера публичных ключей? Поинтересуйтесь.

При передаче такого ключа, ее надежность будет целиком определяться тем, насколько надежный канал связи вы хотите получить. Хотите надежный — озаботьтесь тем, что-бы удостовериться в том, что идентификатор ключа вам передает именно его владелец. Позвоните ему по телефону или встречайтесь лично. В большинстве случаев такая надежность не нужна. Тем не менее, если она вам понадобиться — все в ваших руках.

Прелесть открытого ключа как раз в том, что его можно распространять публично. Если вам нужна привязка этого ключа к конкретному человеку — это ваша личная задача ее обеспечить. И это никак не задача ПО.
Вы с другом или знакомым списываетесь любым образом — по емэйлу или в другом IM (может быть встречаетесь живьем) и передаете друг другу любым образом строку с идентификатором ключа. Эта процедура будет служить вашей личной привязкой данного человека к данному ключу. Вы можете сами выбрать надежность такой передачи используя живой контакт или виртуальный через сеть — все в вашей власти. Ну и кроме этого, не забывайте о наличии такого механизма в OpenGPG, как сеть доверия. Она там несколько корявая, но вполне работоспособная.

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

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

И все это можно реализовать удобным для пользователя способом.
По моему, вы что-то путаете. Для работы защищенного IM нужно только шифрование. Такое, что-бы отправляемое сообщение было доступно только одному получателю. В данной задаче не стоит вопрос о том, что-бы обеспечивать соответствие определенного ключа определенному источнику. Такое соответствие будет обеспечиваться на бытовом уровне. Например, через передачу идентификатора ключа по обычным каналам связи. А такой вариант реализовать удобным для пользователя вполне возможно.
Эта проблема решается открытыми исходниками и мнениями экспертов о них. У пользователя будет выбор — или доверять мнению экспертов, или разбираться в исходниках самому.
Хоть и не очень много программировал на node.js, но он мне очень нравится. Для продакшена делал только конвертер синхронных запросов в асинхронную систему. Сервис на node.js держал входящие соединения, пока с запросами производилась сложная асинхронная обработка, и в асинхронном-же режиме отдавалась конвертеру результат, который возвращался в исходный запрос. Простота реализации такого на node.js просто зашкаливает. На данный момент, хоть я на нем и не пишу, но он в тройке моих любимых языков. :)
Ну так задача разработчика и состоит в том, что-бы облегчить пользователям работу с этими инструментами. И сделать это более чем просто. Честно говоря, меня удивляют такие заявления. Криптография ничем не сложнее чем любые остальные вычислительные задачи и я не вижу принципиальных проблем с тем, чтобы сделать их удобными для обычного пользователя.
По уму, надо-бы и регистрацию на таких сервисах отменить и регистрироваться только по хэшу GPG ключа. Своим контактам просто скидывать свой открытый GPG ключ и сразу иметь защищенную связь с ними.
Спасибо за позитив! Его сейчас очень не хватает.
Есть такое свойство у некоторых программистов. Ключевое слово здесь — «у некоторых». Причем, у начинающих, которые входят в период ложной опытности. Не стоит распространять это на всех.
Из своего опыта проведения собеседований со стороны работодателя могу сказать, что неумение кандидата написать пару строк кода на бумаге во время собеседования, практически, сводит на нет возможность его принятия.
Не совсем понятно как они в вашем варианте могут интерферировать при том что они у вас локализованы в частице.
Я имею ввиду интерференцию при отсутствии детекторов у щелей и две полосы без интерференции при наличии детектора у одной из щелей (или у обеих).
И еще вопрос — как ваша теория объясняет двухщелевой эксперимент с наблюдателем?
По вашей теории, в каких случаях фотон ведет себя как волна, а в каких — как частица? Чем именно это определяется?
«Опыта внедрения пока что нет»

Как-то это странно видеть, учитывая сколько народа работает на удаленке в постоянном режиме. Конечно для такой работы нужна самодисциплина, но ничего невозможного в этом нет.
«5. Почему крышки на канализационных люках круглые? (Software engineer)

Ответ: чтобы не спотыкаться об углы»

Это шутка такая? Я думал что люки круглые что-бы у крышки не было возможности провалиться в люк.

А! Извиняюсь. Это кто-то пытался ответить на вопросы. Я думал что это правильные ответы размещены. :)
Тоже люблю Mag-Lite. Приобрел два «охранницких» фонарика — LED на батарейках и галогенный на аккумуляторах. Очень доволен. Пока еще ни разу не подводили.

Information

Rating
Does not participate
Location
Подгорица, Подгорица, Черногория
Date of birth
Registered
Activity

Specialization

Backend Developer, Database Developer
From 500,000 ₽
Golang
Docker
PostgreSQL
Git
Nginx
High-loaded systems
Kubernetes
Linux
MySQL
Redis