6.18 Алгоритм вычисления дайджеста сообщения (SHA1, RFC-3174, сентябрь 2001)

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Алгоритм SHA-1 (Secure Hash Algorithm) предназначен для вычисления дайджеста документа, файла или сообщения. Когда входное сообщение имеет произвольную длину 64 бит, программа SHA-1 выдает 160-битовый код, называемый дайджестом сообщения. Дайджест сообщения может стать, например, исходной информацией для для алгоритма электронной подписи, которая формируется для верификации сообщения. Подпись сообщения улучшает эффективность процесса, так как дайджест обычно имеет размер много меньше размера сообщения. Тот же самый алгоритм используется при верификации цифровой подписи. Любая модификация сообщения при транспортировке с крайне высокой вероятностью приведет к тому, что дайджест изменится и подпись не будет верифицирована.

Позднее были разработаны более эффективные версии SHA-2 (2001, 256-512 бит) и SHA-3 (Йоан Даймен, 2013, 256-512 бит).

Алгоритм SHA-1 называется безопасным, так как на его основе невозможно вычислить сообщение, которому соответствует дайджест, или найти другое сообщение, которое может соответствовать полученному дайджесту. Любое изменение сообщения при передаче приведет с большой вероятностью к существенному изменению дайджеста, что исключит успешную сверку цифровой подписи.

В разделе 2 определены терминология и функции, использованные при построении формы SHA-1.

2. Определение битовых строк и целых

В описании используются обозначения для битовых последователей и целых чисел:

3. Операция над словами

Со словами будут производиться следующие операции:

4. Дополнение сообщений

SHA-1 используется для вычисления дайджеста сообщения или информационного файла, который поступает на вход. Сообщение или информационный файл должны рассматриваться как битовая строка. Длина сообщения является числом бит в сообщении (пустое сообщение имеет длину 0). Если число бит в сообщении кратно 8, ради компактности будем представлять сообщение в hex-формате. Целью дополнения сообщения является желание сделать полную длину сообщения кратной 512. В процессе расчета дайджеста сообщения SHA-1 последовательно обрабатывает блоки последовательность 512 бит. Далее специфицируется, как осуществляется дополнение исходного сообщения. Добавляется 1, за которой следует m «0» и 64-битное целое, чтобы получить сообщение с длиной, кратной 512. 64-битное целое характеризует длину исходного сообщения. Дополненное сообщение затем обрабатывается SHA-1 как n 512-битных блоков.

Пример: Предположим, что оригинальное сообщение является строкой бит

После шага (a) это дает

01100001 01100010 01100011 01100100 01100101 1.

Так как l = 40, число бит в строке вше равно 41 и добавляется 407 «0», доводя длину сообщения до 448. Это дает в шестнацатеричном представлении

Пример: Предположим, что мы имеем исходное сообщение (b). Тогда l = 40 (заметим, что l вычисляется до выполнения дополнений). Представление двух слов 40 в hex-формате 00000000 00000028. Следовательно дополненное сообщение в окончательном hex-формате будет иметь вид

Дополненное сообщение будет содержать 16 * n слов для некоторого n > 0. Дополненное сообщение рассматривается как последовательность из n блоков M(1), M(2), первые символы (или биты) сообщения.

5. Используемые функции и константы

Рис. 1. Алгоритм вычисления дайджеста SCH1 [5]

Методы, представленные в разделах 6.1 и 6.2, выдают идентичные дайджесты сообщения. Хотя, использование метод 2 позволяет сэкономить 64 32-битовых слов в памяти, он вероятно удлинит время исполнения из-за усложнения вычисления адресов для < Wа[t] >на шаге (c). Существуют другие методы вычисления, которые дают идентичные результаты.

6.1. Метод 1

Дайджест сообщения вычисляется с использованием дополненного сообщения, как это описано в разделе 4. Вычисление описано для случая двух буферов, каждый из которых содержит пять 32-битных слов, и последовательность из восьмидесяти 32-битовых слов. Слова первого 5-словного буфера помечены как A,B,C,D,E. Слова второго 5-словного буфера помечены как H0, H1, H2, H3, H4. Слова массива из 80 слов помечены, как W(0), W(1). W(79). Используется также буфер для одного слова TEMP.

Чтобы сгенерировать дайджест сообщения, блоки из 16-слов M(1), M(2). M(n), определенные в разделе 4, обрабатываются последовательно. Обработка каждого M(i) включает в себя 80 шагов.

Прежде чем обрабатывать какой-либо блок, все H инициализируются следующим образом: в hex-представлении:

После обработки M(n), дайджест сообщения является 160-битовой строкой, в виде 5 слов:

6.2 Метод 2

7. C Code

7.3 Тестовый драйвер

Ниже приведен код основной программы тестового драйвера для проверки кода sha1.c.

Ссылки

[1] «Secure Hash Standard», United States of American, National Institute of Science и Technology, Federal Information Processing Standard (FIPS) 180-1, April 1993.

[3] Rivest, R., «The MD4 Message-Digest Algorithm», RFC1320, April 1992.

[4] [RFC 1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC1321, April 1992.

[5] Eastlake, D., Crocker, S. и J. Schiller, «Randomness Requirements for Security», RFC 1750, December 1994.

Источник

Sha1 digest что это

1. Set up working folder from ROM
2. Add root permissions
3. Add BusyBox
4. Disable boot screen sounds
5. Add wireless tethering
6. Zipalign all *.apk files to optimize RAM usage
7. Change wipe status of ROM
8. Change name of ROM
9. Check update-script for errors
10. Show working folder information

0. Advanced Options
99. Build ROM from working folder

00. About/Update kitchen
0. Exit

1. Создать рабочую папку из ROM’а
2. Добавить root права
3. Добавить BusyBox
4. Отключить экран загрузки звуков
5. Добавить фунцию создания Wi-Fi роутера из телефона
6. Zipalign все «.apk» фаилы, проще говоря сжать
7. Сменить wipe статус ROM
8. Сменить название версии ROM
9. Проверить update-scrypt на наличие ошибок
10. Посмотреть информацию рабочей папки

0. Дополнительные функции
99. Собрать ROM из рабочей папки

00. О кухне/обновить
0. Выход

В теме нет куратора. Если в теме есть пользователь, желающий стать Куратором и соответствующий Требованиям для кандидатов, он может подать заявку в теме Хочу стать Куратором (предварительно изучив шапку темы и все материалы для кураторов).
До назначения куратора, по вопросам наполнения шапки, обращайтесь к модераторам раздела через кнопку под сообщениями, на которые необходимо добавить ссылки.

Тема постепенно будет наполнятся по мере накопления знаний.

Внимательно читайте инструкцию, не задавайте глупых вопросов.

может быть не совсем по теме, НО. вопрос такой: есть ли прога какая нибудь или способ изменить набор частот ядра, т.е. например:

пс. спасибо за гайд.

Источник

Русские Блоги

Подробное объяснение процесса подписи механизма подписи Android (1)

Перепечатано с: http://blog.csdn.net/jiangwei0910410003/article/details/50402000

Введение

Прежде чем говорить о сигнатурах Android, мы должны знать несколько моментов знания

1. Сводка данных (данные отпечатков пальцев), файл подписи, файл сертификата

2. Подпись инструмента Jarsign и подпись инструмента signapk

3. Связь между файлом хранилища ключей, файлом pk8 и файлом x509.pem

4. Как вручную подписать апк

Четыре пункта знаний, представленные выше, являются основой сегодняшнего введения. Давайте посмотрим на эти вопросы по очереди.

Во-вторых, подготовить знания

Сначала посмотрите на пункты знания сводки данных, файла подписи, файла сертификата

1. Сводка данных

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

2. Файлы подписи и сертификаты

Файл подписи и сертификат появляются попарно. Они неразделимы, и из исходного кода мы увидим позже, что два файла имеют одно и то же имя, но суффиксное имя отличается.

3. инструменты jarsign и signapk

После изучения пунктов знаний о трех файлах в подписи, давайте продолжим рассмотрение двух инструментов для подписи в Android: jarsign и signapk

Вначале легко спутать эти два инструмента, как вы думаете, есть ли разница между ними?

4. Разница между файлом хранилища ключей и файлом pk8, x509.pem

Выше мы узнали, что как jarsign, так и signapk могут использоваться для входа в Android, тогда разница между ними заключается в том, что файлы, используемые при подписании, различаются.

Файл ключей используется, когда инструмент jarsign подписывает

Инструмент Signapk использует файл pk8, x509.pem при подписании

Среди них, когда мы используем инструмент Eclipse для написания программы, когда пакет Debug отсутствует, инструмент jarsign по умолчанию используется для подписи, а в Eclipse есть файл подписи по умолчанию:

Мы можем видеть файл хранилища ключей, который подписан по умолчанию, конечно, мы можем выбрать файл хранилища ключей, который мы указали сами.

Есть также пункт знания:

Мы видим сводку MD5 и SHA1 выше. Это сводка данных закрытого ключа в файле хранилища ключей. Эта информация также является информацией, которую нам необходимо заполнить при подаче заявки на многие учетные записи платформы разработки.Например, при подаче заявки на карту Baidu, WeChat SDK и т. Д. Вам нужно будет заполнить данные приложения MD5 или SHA1.。

5. Вручную подписать пакет Apk

1 «Используйте Keytool и Jarsigner для подписи

Конечно, когда мы выпускаем пакет в официальном месте подписи, нам нужно создать наш собственный файл хранилища ключей:

Здесь мы можем присвоить собственное имя файлу хранилища ключей, а имя суффикса не имеет значения. После создания файла будут также сгенерированы значения MD5 и SHA1, которые можно не указывать, а значения MD5 и SHA1 файла хранилища ключей можно проверить с помощью команды.

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

Здесь мы видим, что Eclipse автоматически подписывает и генерирует файл хранилища ключей, и мы также можем использовать инструмент keytool для генерации файла хранилища ключей. Этот метод доступен онлайн, поэтому я не буду здесь подробно рассказывать. Тогда мы можем использовать jarsign, чтобы подписать пакет apk.

Мы можем вручную создать файл хранилища ключей:

Эта команда немного длинная, и есть несколько важных параметров, которые необходимо объяснить:

-alias для определения псевдонима, здесь отладка

Войдите с помощью инструмента jarsigner

Таким образом, мы успешно подписали апк.

Проблемы, возникающие в процессе подписания:

1. Проблема в том, что цепочка сертификатов не может быть найдена.

Это потому, что последний псевдоним параметра является неправильным псевдонимом хранилища ключей.

2. Ошибка запроса пароля при создании файла хранилища ключей.

Причина в том, что в текущем каталоге уже есть debug.ketystore. Если генерируется debug.keystore, будет сообщено об ошибке

3 not Проблема не найти псевдоним

Причиной этой проблемы является то, что когда мы использовали keytool для генерации хранилища ключей, использовался псевдоним отладки. Эта проблема беспокоила меня в течение длительного времени. Наконец, я сделал много примеров, чтобы выяснить, что, пока псевдоним нашего файла хранилища ключей является отладочным, тогда Сообщит о такой ошибке. Это должно быть связано с отладкой по умолчанию в системе. Псевдоним в хранилище ключей отладочный, верно? Исходный код jarsigner не найден, поэтому я могу только догадываться, но эти три проблемы отмечены здесь на случай, если они возникнут в будущем.

Примечание: Android позволяет нескольким хранилищам ключей подписывать apkЯ не буду вставлять команду здесь, я создал несколько хранилищ ключей, чтобы подписать АПК:

Здесь я также могу заметить, что мы использовали алгоритм DSA при подписании, суффикс имени файла здесь DSA

И имя файла является псевдонимом хранилища ключей

Эй, здесь ясно, как мы используем keytool для генерации хранилища ключей и jarsigner для подписи.

2》 Используйте Signapk для подписи

Давайте посмотрим на инструмент signapk для подписи:

Если вы подпишетесь здесь, вы не будете в демоверсии, здесь нет проблем.

Но вот что требует внимания:Имена трех файлов в папке META-INF в apk после подписи signapk похожи на это, потому что signapk не похож на jarsigner, который будет автоматически использовать псевдоним для имени файла в начале, вот имя CERT, которое записано мертвым. Однако имя файла не влияет. Позже, во время анализа процесса проверки Apk в Android, будет сказано, что файл будет найден только по имени суффикса.

3》 В чем разница между двумя методами подписи

Итак, здесь мы выяснили разницу и связь между этими двумя инструментами подписи.

В-третьих, проанализируйте механизм процесса подписи в Android

Ниже мы начнем смотреть на механизм подписи и принцип потока в Android с точки зрения исходного кода

Поскольку исходный код jarsigner не найден в сети, но найден исходный код signapk, давайте посмотрим на исходный код signapk:

Местоположение источника:com/android/signapk/sign.java

Посредством вышеуказанной подписи мы видим, что после apk подписи Android будет папка META-INF, в которой будут три файла:

MANIFEST.MF

CERT.RSA

CERT.SF

Давайте посмотрим, для чего нужны эти три файла?

1、MANIFEST.MF

Давайте посмотрим на исходный код:

В основной функции мы видим, что нам нужно ввести четыре параметра, а затем мы делаем три вещи:

Посмотрите на метод ввода:

Логика кода все еще очень проста, в основном зависит от смысла цикла:

В дополнение к трем файлам (MANIFEST.MF, CERT.RSA, CERT.SF) другие файлы будут выполнять алгоритм SHA1 для содержимого файла, то есть вычислять сводную информацию о файле, а затем использовать Base64 для кодирования, мы используем инструмент ниже Давайте рассмотрим случай, если это так:

Сначала установите инструмент: HashTab

Тогда есть еще один сайт, который рассчитывает Base64 онлайн:http://tomeko.net/online_tools/hex_to_base64.php?lang=en

Тогда давайте начнем нашу работу по проверке:

Давайте проверим файл AndroidManifest.xml, сначала найдем эту запись в файле MANIFEST.MF и запишем значение SHA1.

Затем после установки HashTab найдите файл AndroidManifest.xml, щелкните правой кнопкой мыши и выберите «Hashtab»:

Скопируйте значение SHA-1: 9C64812DE7373B201C294101473636A3697FD73C, перейдите на приведенный выше веб-сайт преобразования Base64 и выполните преобразование:

Это точно так же, как содержание записи в MANIFEST.MF

Тогда мы знаем из вышеприведенного анализа, что в действительности хранится в MANIFEST.MF:

Перебирайте все записи в нем одну за другой. Если это каталог, пропустите его. Если это файл, используйте алгоритм дайджеста сообщения SHA1 (или SHA256), чтобы извлечь дайджест файла, а затем закодируйте его как значение атрибута «SHA1-Digest» BASE64. Запись в блок в файле MANIFEST.MF. Блок имеет атрибут «Имя», значением которого является путь к файлу в пакете apk.

Примечание. Для лучшего понимания здесь используется шестнадцатеричное представление sha-1 файла AndroidManifest.xml, 9C64812DE7373B201C294101473636A3697FD73C;

Возьмите SHA1-дайджест в файле MANIFEST.MF и извлеките nGSBLec3OyAcKUEBRzY2o2l / 1zw =, который является представлением SHA-1 Base64, соответствующим AndroidManifest.xml, и преобразуйте его в шестнадцатеричное 9C64812DE7373B201C294101473636A36973697.

2. Давайте посмотрим на содержимое файла CERT.SF

Содержимое здесь аналогично содержимому MANIFEST.MF, давайте посмотрим на код:

Введите метод writeSignatureFile:

Прежде всего, мы видим, что нам нужно создать SHA1 для всего содержимого предыдущего файла MANIFEST.MF и поместить его в поле SHA1-Digest-Manifest:

Давайте посмотрим на переменную manifest, которая была только что записана в файл MANIFEST.MF.

Мы можем проверить это:

Видите, это так же, как значение в файле

Ниже мы продолжаем смотреть на код, есть цикл:

Здесь мы по-прежнему используем только что переданную переменную mainfest, просматриваем содержимое его записи и затем вычисляем алгоритм SHA в Base64:

Фактически, это сделать SHA для каждой записи в файле MANIFEST.MF, просто сохраните ее и проверьте это на примере:

Используя в качестве примера AndroidManifest.xml, мы копируем и сохраняем записи в файле MANIFEST.MF в текстовый файл:

Здесь следует отметить, что после сохранения нам нужно добавить две новые строки, мы можем увидеть логику в коде:

Затем мы вычисляем значение SHA документа txt:

Видите, значения, рассчитанные здесь, одинаковы

Здесь мы знаем, что делает файл CERT.SF:

1 «Рассчитайте общее значение SHA1 этого файла MANIFEST.MF и после кодирования BASE64 запишите его в значение атрибута» SHA1-Digest-Manifest «основного блока атрибута (в заголовке файла) файла CERT.SF.

3. Наконец, мы смотрим на файл CERT.RSA

Все, что мы видим здесь, это двоичные файлы, потому что файл RSA зашифрован, поэтому нам нужно использовать команду openssl для просмотра его содержимого.

Для этой информации вы можете увидеть следующую картину:

Давайте посмотрим на код:

Этот файл содержит подпись и сертификат открытого ключа. При создании подписи должен участвовать частный ключ. Сводка информации, используемой в подписи, является содержимым CERT.SF.
Данные подписи будут использоваться в качестве сводки подписи. Функция writeSignatureBlock использует privateKey для шифрования подписи, чтобы сгенерировать подпись, а затем сохранить подпись и сертификат открытого ключа вместе в CERT.RSA.
Последняя подпись, хранящаяся в CERT.RSA, является цифровой подписью CERT.SF. Сигнатура генерируется с использованием privateKey, а алгоритм подписи определяется в publicKey. В то же время publicKey также будет храниться в CERT.RSA, что означает, что CERT.RSA содержит подпись и сертификат, используемый для подписи. И требуют, чтобы этот сертификат был самоподписанным.

4. Почему вы подписываете так?

Выше мы ввели детали трех файлов после подписания apk, поэтому давайте подведем итоги, почему необходимо шифровать и подписывать таким образом в Android, является ли этот вид шифрования на стороне наиболее безопасным? Давайте проанализируем, что произойдет, если файл apk будет изменен.

Прежде всего, если вы изменяете какой-либо файл в пакете apk, сводная информация об измененном файле отличается от информации о проверке MANIFEST.MF во время проверки установки apk, поэтому проверка не проходит и программа не может быть успешно установлена.
Во-вторых, если вы вычислите новое итоговое значение для измененного файла, а затем измените соответствующее значение атрибута в файле MANIFEST.MF, то оно должно быть рассчитано в файле CERT.SF. Суммарное значение отличается, и проверка все еще не проходит.
Наконец, если вы все еще не сдаваетесь, продолжите вычислять итоговое значение MANIFEST.MF и соответственно измените значение в CERT.SF, тогда значение цифровой подписи должно быть таким же, как записано в файле CERT.RSA. Не то же самое, все равно не получается.
Итак, можем ли мы продолжать подделывать цифровую подпись? Невозможно, потому что нет личного ключа, соответствующего цифровому сертификату.
Следовательно, если переупаковываемое приложение может быть установлено на устройстве Android, оно должно быть отклонено.

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

V. Знание точек сортировки

1. Значение данных отпечатка пальца, файла подписи и файла сертификата

1》 Отпечаток данных должен сделать алгоритм SHA / MD5 на источнике данных, это значение является уникальным

2 file Технология файлов сигнатур: отпечаток данных + алгоритм RSA

3. Файл сертификата содержит информацию об открытом ключе и другую информацию.

2. Мы понимаем, что есть два способа входа в Android: jarsigner и signapk. Разница между этими двумя способами заключается в следующем:

2 «Имена файлов SF и RSA после подписи jarsigner по умолчанию являются псевдонимом хранилища ключей, а имя файла после подписи signapk является фиксированным: CERT

3. Когда мы запускаем программу Debug в Eclipse, по умолчанию используется jarsigner для подписи, а также используется файл подписи debug.keystore по умолчанию.

4. Файлы хранилища ключей и файлы pk8, x509.pem можно конвертировать между собой.

Источник