Типы ключей
Здравствуйте!
Из консоли GnuPG:
Home: D:/Program Files/GnuPG
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512
Compression: Uncompressed, ZIP, ZLIB, BZIP2
Подскажите, что означает третья строка, я имею в виду разновидности RSA с символами E и S, и чем они отличаются от RSA без «расширения»?
комментариев: 11558 документов: 1036 редакций: 4118
Плюс, если данный подключ имеет signing capability, то такой трюк вообще не сработает, т.к. на ключе в этом случае должен быть особый тип подписи — Primary Key Binding Signature — генерируемый данным подключом.
комментариев: 9796 документов: 488 редакций: 5664
Псевдофото, конечно, лучше: GnuPG всегда могут обновить и пропатчить, чтобы она некорректные ключи не принимала.
Я немного поправил свой комент. А как тогда сгенерить RSA-ключ с таким размером? Помимо странного индекса, размер ключа выглядит ещё более странно. Таких больше ни у кого нет.
P.S. В принципе, такой размер возможен: 2432 = 211 + 28 + 27. Наверное, через экспертный интерфейс его можно выбрать, тогда вопрос снят.
комментариев: 11558 документов: 1036 редакций: 4118
Вот, только что проверки ради спокойно сгенерировал ключ такой же длины:
pub 2432R/34F7AD34 2014-12-23
Без всяких expert-режимов.
комментариев: 9796 документов: 488 редакций: 5664
Спасибо, теперь можно спать спокойно. Любое число можно разложить в двоичный ряд, но почему-то казалось, что в GnuPG ограничения на минимальный шаг в степенях двоек.
Осталось придумать, как удобнее цеплять произвольное количество бинарников под видом PhotoID и вообще с этим работать.
Не совсем понятно, какая практическая польза от этого и зачем передавать в ключах сообщения.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
По типу такого, только вместо tinyurl, см. последний абзац в /comment80997. Чтобы с отдельными анонимными/псевдонимными адресатами вообще не пользоваться почтой, а только обмениваться ссылками на файлопомойки. Или сделать небольшой твиттер через серверы GnuPG, или анонимно переслать ключ к Bitcoin-кошельку, или для какого-то «походного» ключа повесить под видом открытого ключа запароленную версию закрытого. Можно много чего придумать.
комментариев: 1079 документов: 58 редакций: 59
Размер картинки при --addphoto 7Кб (240x288), туда можно много всего напихать, вплоть до текста и застеганографить.
комментариев: 9796 документов: 488 редакций: 5664
7 кб — относительно много текста, если его заархивировать и представить бинарником с jpeg-заголовком.
А вот для этого там практически места не останется. Будет ясно, что никакое это не фото.
комментариев: 1079 документов: 58 редакций: 59
Вот я об этом же, что текста много, а остальные условности о передачи его – можно завуалировать очень сильно. Ну там адресат, время и тд.
Почему? Нужно провести эксперемент, у меня в период беглого знакомства со стеганографией как раз и получалось, что jpeg урезался до немогу. Пусть и с потерей качества, не обязательно ставить туда сверхкачественные фото. Гору в тумане или улицу в дождливую ночь и все – никто ничего не поймет. Тем же DarkJPEG. Просто если вставлять простой, пошифрованный текст – нужно же будет долго и нудно рассказывать собеседникам о том, что ему нужно сделать и как для дешифровки. А я подразумеваю то, что собеседники могут быть совсем далекими от ИТ, соответственно – скачали фото, запихнули ее в DarkJPEG, который залит по указанному заранее адресу и все.
Я к тому, что мне изначально понравились твои идеи и на счет маскировки gpg-переписки под тот же PDF и тд, что в моем понимании очень даже не плохо спасает от глобального наблюдателя, т.к. никто вручную не будет заголовки проверять. Но опять таки – это нужно либо автоматизировать как-то с обеих сторон, либо проводить ликбез, что муторно и порой просто невозможно.
комментариев: 9796 документов: 488 редакций: 5664
Подразумевается, что одна сторона создаёт свой псевдонимный ключ, сообщает его отпечаток другой стороне, которая делает также в ответ. Затем, каждая сторона по мере надобности вешает новые УИДы с псевдокартинками для сообщений на свой ключ и периодически проверяет наличие новых УИД-овых картинок на ключе другой стороны. Всё это через Tor, чтобы не спалиться с принадлежностью ключа.
Само по себе появление на общедоступных серверах таких ключей с кучей картинок привлекает внимание, так что нет смысла там чего-то стеганографировать, лучше иметь возможность запихать больше текста в виде откровенно псевдорэндомных данных. А другой стороне можно выслать и скрипт для автоматизации этого всего на баше/питоне/etc.
комментариев: 1079 документов: 58 редакций: 59