LINUX.ORG.RU

История изменений

Исправление gns, (текущая версия) :

И того, апосля как я подумал.

Имеем два ключа:

K, для того что бы сформировать URL, по которому получатель может забрать с сервера сообщение и

Pk, который формируется из соли и (может быть) пароля.

Пароль мы передали сторонним каналом. К передается в открытую (ну почти).

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

Опять же, если предположить, что сообщения одноразовые и только между парой абонентов, то это работает, А что делать с циркулярной рассылкой (в групповых чатах), если у каждого свой пароль? Впрочем, это решается групповым паролем или набором паролей, распространенных заранее. Хуже другое. Если сообщение на сервере предназначено для нескольких абонентов, то нужен какой-то счетчик.

Или вот еще идея: использовать второй пароль для фломирования ключа К, что бы н стороне получателя сообщения появлялись только после ввода пароля для получения сообщений. Или предусмотреть fake-пароль, при вводе которого сообщения на сервере стираются, а отправитель получает сообщение «абонент дискредитирован». Ну такая мелкая защита от мордо-обкапотного и дубинно-почечного криптоанализа.

Исправление gns, :

И того, апосля как я подумал.

Имеем два ключа:

K, для того что бы сформировать URL, по которому получатель может забрать с сервера сообщение и

Pk, который формируется из соли и (может быть) пароля.

Пароль мы передали сторонним каналом. К передается в открытую (ну почти).

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

Опять же, если предположить, что сообщения одноразовые и только между парой абонентов, то это работает, А что делать с циркулярной рассылкой (в групповых чатах), если у каждого свой пароль? Впрочем, это решается групповым паролем или набором паролей, распространенных заранее. Хуже другое. Если сообщение на сервере предназначено для нескольких абонентов, то нужен какой-то счетчик.

Или вот еще идея: использовать второй пароль для фломирования ключа К, что бы н стороне получателя сообщения появлялись только после ввода пароля для получения сообщений. Или предусмотреть fake-пароль, при вводе которого сообщения на сервере стираются, а отправитель получает сообщение «абонент дискредитирован».

Исправление gns, :

И того, апосля как я подумал.

Имеем два ключа:

K, для того что бы сформировать URL, по которому получатель может забрать с сервера сообщение и

Pk, который формируется из соли и (может быть) пароля.

Пароль мы передали сторонним каналом. К передается в открытую (ну почти).

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

Опять же, если предположить, что сообщения одноразовые и только между парой абонентов, то это работает, А что делать с циркулярной рассылкой (в групповых чатах), если у каждого свой пароль? Впрочем, это решается групповым паролем или набором паролей, распространенных заранее. Хуже другое. Если сообщение на сервере предназначено для нескольких абонентов, то нужен какой-то счетчик.

Или вот еще идея: использовать второй пароль для фломирования ключа К, что бы н стороне получателя сообщения появлялись только после ввода пароля для получения сообщений. Или ghtlecvjnhtnm fake-пароль при вводе которого сообщения на сервере стираются, а отправитель получает сообщение «абонент дискредитирован».

Исходная версия gns, :

И того, апосля как я подумал.

Имеем два ключа:

K, для того что бы сформировать URL, по которому получатель может забрать с сервера сообщение и

Pk, который формируется из соли и (может быть) пароля.

Пароль мы передали сторонним каналом. К передается в открытую (ну почти).

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

Опять же, если предположить, что сообщения одноразовые и только между парой абонентов, то это работает, А что делать с циркулярной рассылкой (в групповых чатах), если у каждого свой пароль? Впрочем, это решается групповым паролем или набором паролей, распространенных заранее. Хуже другое. Если сообщение на сервере предназначено для нескольких абонентов, то нужен какой-то счетчик.