Это, собственно, основной используемый формат для хранения/обмена приватными, публичными и симметричными ключами, который может хранить кучу всяческой сопроводительной информации, относящейся к криптографии. Можно вообще извратиться и использовать его в качестве контейнера общего назначения, вместо binary1 plist или ebml.
Для расшифровки нужен же не сам секрет, а message_key. В нём «всего лишь» 16 байт.
Вот только незадача в том, что по шифротексту невозможно определить, какой message_key верен, т.е. для проверки таки придется искать 2**256 preimage-й для MD2, а его вроде еще не взломали так, чтобы атака имела практический смысл.
Боб передал Алисе публичный ключ в формате ASN.1 DER, вот сюда можно вставить дамп из примера и посмотреть, как это выглядит.
Так что факторизировать нужно следующее число —
356527243659966548693033457464923716516539456_
319730960454335082893872317336655556619514752_
052654033163046749556804944585554927982098217_
315985406413478394848605180442422330065661415_
504642348309789041002870095790088186364384614_
356226611862292009565904103583804420207453441
А, ну тогда я останавливаю брутфорс, а то мне ровно 1663168150764967181301373761365378286839988198203411906 возрастов Вселенной до конца перебора осталось.
В принципе, раз сбрутить секрет не вариант, можно попробовать факторизировать открытый ключ — не на ноутбуке, конечно же.
Собственно, автор совершил ошибку, использовав textbook RSA и 32-битное целое вместе, поэтому super_secret можно просто сбрутить — перебирать все возможные super_secret-ы и шифровать их предоставленным открытым ключом, пока результат не совпадет с тем, что отправила Алиса. Если бы использовался паддинг, или секрет был бы хотя бы 64 бита, этот сценарий бы уже не сработал.
Я не фанат разработчиков телеграмма, но даже на моем ноутбуке средней паршивости скрипт на Python, набросанный за 10 минут, получит расшифрованное содержимое сообщения самое большее через 22 часа. В чем тогда смысл?
Да, такая возможность есть (хоть со $100) и общедоступна. Т.е. на данный момент развития рынка любой (включая хомячков) может сразу начать торговать без конфликта интересов.
Подскажите, пожалуйста, каким образом это можно сделать?
Как можно было ТАК налажать в отрисовке загрузки спектрума? Я понимаю, если бы это был сюжет для первого канала, но целевой аудитории такое же как серпом по яйкам.
Я вижу несколько вариантов того, как можно получить EncryptedIV:
a) AES(plaintext = EncryptedTempIV, key = KeyIV, mode = ECB)
b) AES(plaintext = EncryptedTempIV, key = KeyIV, iv = PlainIV, mode = CBC)
c) AES(plaintext = EncryptedTempIV, key = KeyMessage, mode = ECB)
d) четвертая смешная опция
К первому варианту (a) — авторы точно уверены, что Encrypt(Encrypt(x)), где Encrypt(x) := AES(plaintext = x, key = SAME_KEY, mode = ECB) — это вообще хорошая идея? В голову сразу приходит пример с гаммированием и полной обратимостью в случае одинакового ключа — кто-то вообще проводил анализ того, что получается с данными, если их дважды зашифровать одинаковым ключом?
А можете немного подробнее объяснить, если вам не трудно: «При этом IV шифруется тем же самым ключом дважды: до шифрования и после, называется это двойным шифрованием (double encryption)» — что имеется в виду под «до шифрования» и «после шифрования»? IV ведь не является частью открытого текста, чем IV до шифрования отличается от того, что после?
Нет-нет, вы говорите о более радикальном реагировании на превышение квоты. Я же изначально думал о троттлинге — в случае превышения локальной квоты вводить задержки в функции выделения памяти путем формирования очереди этих вызовов и ожидания освобождения памяти от менее ограниченных задач. Т.о. тот, кто хочет слишком многого, все равно будет работать, но при этом не будет мешать остальным, которые памятью пользуются более разумно.
При превышении же глобальной квоты (которая на весь браузер), возможно, следует просто перенести проблему на плечи скрипта, и начать сыпать вполне обычными OutOfMemoryError-ами, которые в худшем случае вполне официально убьют скрипт, а в лучшем скрипт поймет, что что-то делает неправильно и исправит это. Или умрет :)
Так что факторизировать нужно следующее число —
356527243659966548693033457464923716516539456_
319730960454335082893872317336655556619514752_
052654033163046749556804944585554927982098217_
315985406413478394848605180442422330065661415_
504642348309789041002870095790088186364384614_
356226611862292009565904103583804420207453441
В принципе, раз сбрутить секрет не вариант, можно попробовать факторизировать открытый ключ — не на ноутбуке, конечно же.
Подскажите, пожалуйста, каким образом это можно сделать?
Версии WADов подойдут от 1.666 и выше.
— KeyIV — ключ для IV
— KeyMessage — ключ для сообщения
— PlainIV — открытый IV
— PlainMessage — открытый текст
EncryptedTempIV = AES(plaintext = PlainIV, key = KeyIV, mode = ECB)
EncryptedMessage = AES(plaintext = PlainMessage, key = KeyMessage, iv = EncryptedTempIV, mode = CBC)
EncryptedIV = ???
FinalMessage = Pack(EncryptedIV, EncryptedMessage)
Я вижу несколько вариантов того, как можно получить EncryptedIV:
a) AES(plaintext = EncryptedTempIV, key = KeyIV, mode = ECB)
b) AES(plaintext = EncryptedTempIV, key = KeyIV, iv = PlainIV, mode = CBC)
c) AES(plaintext = EncryptedTempIV, key = KeyMessage, mode = ECB)
d) четвертая смешная опция
К первому варианту (a) — авторы точно уверены, что Encrypt(Encrypt(x)), где Encrypt(x) := AES(plaintext = x, key = SAME_KEY, mode = ECB) — это вообще хорошая идея? В голову сразу приходит пример с гаммированием и полной обратимостью в случае одинакового ключа — кто-то вообще проводил анализ того, что получается с данными, если их дважды зашифровать одинаковым ключом?
Какой из вариантов используется на самом деле?
При превышении же глобальной квоты (которая на весь браузер), возможно, следует просто перенести проблему на плечи скрипта, и начать сыпать вполне обычными OutOfMemoryError-ами, которые в худшем случае вполне официально убьют скрипт, а в лучшем скрипт поймет, что что-то делает неправильно и исправит это. Или умрет :)