Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Цифровая подпись. Проверка подписи, защита от подделки, подмены и т.п.
53 views
Skip to first unread message
Victor Blood
Mar 5, 2012, 2:55:44 AM3/5/12
to
Приветствую тебя, All!
Сабж, собственно.
Абсолютной защиты не существует, нужен алгоритм близкий к идеалу, в основном
защита от подделки подписи/сертификата.
Со всеми регардами,
Victor Blood (AKA MASM)
Сабж, собственно.
Абсолютной защиты не существует, нужен алгоритм близкий к идеалу, в основном
защита от подделки подписи/сертификата.
Со всеми регардами,
Victor Blood (AKA MASM)
Serguei E. Leontiev
Mar 6, 2012, 7:49:28 PM3/6/12
to
Привет Victor,
От пн, 05 мар 2012 11:55:44 в fido7.ru.crypt ты писал:
VB> Абсолютной защиты не существует, нужен алгоритм близкий к идеалу,
Алгоритм - термин обозначающий нечто идеальное. Поэтому, скажем,
сходи на gost.ru, возьми ГОСТ Р 34.10-2001 и наслаждайся алгоритмом.
VB> защита от подделки подписи/сертификата.
Сертификат - понятие не алгоритмизируемое, быть может, лучше без него?
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru <http://www.cryptopro.ru>
От пн, 05 мар 2012 11:55:44 в fido7.ru.crypt ты писал:
VB> Абсолютной защиты не существует, нужен алгоритм близкий к идеалу,
Алгоритм - термин обозначающий нечто идеальное. Поэтому, скажем,
сходи на gost.ru, возьми ГОСТ Р 34.10-2001 и наслаждайся алгоритмом.
VB> защита от подделки подписи/сертификата.
Сертификат - понятие не алгоритмизируемое, быть может, лучше без него?
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru <http://www.cryptopro.ru>
Victor Blood
Mar 7, 2012, 1:32:16 PM3/7/12
to
Приветствую тебя, Serguei!
Ответ на сообщение Serguei E. Leontiev (2:5020/400) к Victor Blood,
написанное 07 Mar 12 в 04:49:
VB>> Абсолютной защиты не существует, нужен алгоритм близкий к идеалу,
SEL> Алгоритм - термин обозначающий нечто идеальное. Поэтому, скажем,
SEL> сходи на gost.ru, возьми ГОСТ Р 34.10-2001 и наслаждайся алгоритмом.
Ну, прям интернет форум, сходи... В магазин сходить проще и забить.
Вот есть, например, CERT - распределяет сертификаты, проверяет подписи, мне не
нужен ГОСТ Р.... мне нужен алгоритм шифрования и флгоритм проверки подлиности
при авторизации в системе.
VB>> защита от подделки подписи/сертификата.
SEL> Сертификат - понятие не алгоритмизируемое, быть может, лучше без него?
Сертификат понятие единое и речь тут, читай выше, не о сертификате, а о его
проверке и защите, что очень хорошо описывается теми-же TLS/SLT и иже с ними, а
это уже принятые алгоритмы.
Предполагается поверх шифра сертификатом, т.е. после авторизации передавать
данные по синхронному каналу, алгоритм для него уже определен XTEA3. Посему
интересует: алгоритм, именно, алгоритм проверки сертификата, алгоритм защиты
сертификата от атак типа "подделка копией", "пересылка через хост" и, если
нечего сказать кроме "пошел на gost.ru", тогда лучше молчать совсем.
Со всеми регардами,
Victor Blood (AKA MASM)
PS. вот эха и дохнет.
Ответ на сообщение Serguei E. Leontiev (2:5020/400) к Victor Blood,
написанное 07 Mar 12 в 04:49:
VB>> Абсолютной защиты не существует, нужен алгоритм близкий к идеалу,
SEL> сходи на gost.ru, возьми ГОСТ Р 34.10-2001 и наслаждайся алгоритмом.
Ну, прям интернет форум, сходи... В магазин сходить проще и забить.
Вот есть, например, CERT - распределяет сертификаты, проверяет подписи, мне не
нужен ГОСТ Р.... мне нужен алгоритм шифрования и флгоритм проверки подлиности
при авторизации в системе.
VB>> защита от подделки подписи/сертификата.
Сертификат понятие единое и речь тут, читай выше, не о сертификате, а о его
проверке и защите, что очень хорошо описывается теми-же TLS/SLT и иже с ними, а
это уже принятые алгоритмы.
Предполагается поверх шифра сертификатом, т.е. после авторизации передавать
данные по синхронному каналу, алгоритм для него уже определен XTEA3. Посему
интересует: алгоритм, именно, алгоритм проверки сертификата, алгоритм защиты
сертификата от атак типа "подделка копией", "пересылка через хост" и, если
нечего сказать кроме "пошел на gost.ru", тогда лучше молчать совсем.
Со всеми регардами,
Victor Blood (AKA MASM)
Serguei E. Leontiev
Mar 7, 2012, 6:08:19 PM3/7/12
to
Привет Victor,
От ср, 07 мар 2012 22:32:16 в fido7.ru.crypt ты писал:
Разумно, будешь смеяться, но "забить" это самое близкое к идеалу решение.
VB> Вот есть, например, CERT - распределяет сертификаты, проверяет
VB> подписи, мне не
...
VB> проверке и защите, что очень хорошо описывается теми-же
VB> TLS/SLT и иже с ними, а это уже принятые алгоритмы.
Если ты сам и твои пользователи доверяют этому самому "CERT",
то стройте цепочку доверия с ними и получайте сертификаты там,
просто надо учитывать риск повторения судьбы DigiNotar.
Можешь организовать собственное подразделение, которое будет
поддерживать собственный корпоративный удостоверяющий центр.
Быть может, к нему будет доверия больше, хотя не факт.
TLS/SSL не описывают не только построение цепочки доверия, но и
вообще любые аспекты проверки сертификатов (замечу что есть
CipherSuite вообще без закрытых ключей и сертификатов,
использующие PSK).
А поддержание доверия между пользователями и удостоверяющим
центром, это не алгоритм, а организационный процесс. Здесь
нужен не "технарь", а нормальный "безопасник".
В любом случае, при использовании сертификата, ты меняешь один
геморрой на другой геморрой, и именно поэтому я тебе советовал
подумать на тему "может, лучше без него?"
VB> Предполагается поверх шифра сертификатом, т.е. после авторизации передавать
VB> данные по синхронному каналу, алгоритм для него уже определен XTEA3. Посему
Хм. XTEA, интересно из каких соображений?
А какой алгоритм имитозащиты (MAC/HMAC) определён?
VB> интересует: алгоритм, именно, алгоритм проверки сертификата, алгоритм защиты
VB> сертификата от атак типа "подделка копией", "пересылка через хост" и, если
Что-то я не понимаю твоей терминологии. Если вести речь о защите
сертификата и закрытого ключа (ключа подписи), то зависит от
технологии избранного удостоверяющего центра. В любом случае,
для небольшой сети, прямо на удостоверяющем центре создаётся
и то, и другое, записывается на ключевой носитель и вручается
пользователю.
Hо причём здесь "пересылка через хост"? Если же речь вести про
протокол аутентификации, то обычными мерами, обе стороны должны
предъявить: элемент идентификации (с привязкой к сетевому
идентификатору), "элемент свежести", в результате должен быть
выработан код аутентификации, который должен будет в последствии
использовался для привязки протоколов более высокого уровня к
сессии.
Потом доказываешь теорему (ну, или строишь "правдоподобное"
рассуждение) о корректности построенного протокола. Затем
приносишь полученное криптографу или математику, которому
доверяешь, и вы выносите вердикт: возвратится к самому началу,
или уже и так сойдёт.
Возьми учебник, например, Венбо Мао, "Современная криптография.
Теория и практика", подбери похожий протокол, например, IKE.
VB> нечего сказать кроме "пошел на gost.ru", тогда лучше молчать совсем.
А какой был вопрос? Про алгоритм близкий к идеалу? Так он там есть!
От ср, 07 мар 2012 22:32:16 в fido7.ru.crypt ты писал:
VB>>> Абсолютной защиты не существует, нужен алгоритм близкий к идеалу,
SEL>> Алгоритм - термин обозначающий нечто идеальное. Поэтому, скажем,
SEL>> сходи на gost.ru, возьми ГОСТ Р 34.10-2001 и наслаждайся алгоритмом.
VB> Hу, прям интернет форум, сходи... В магазин сходить проще и забить.
SEL>> Алгоритм - термин обозначающий нечто идеальное. Поэтому, скажем,
SEL>> сходи на gost.ru, возьми ГОСТ Р 34.10-2001 и наслаждайся алгоритмом.
Разумно, будешь смеяться, но "забить" это самое близкое к идеалу решение.
VB> Вот есть, например, CERT - распределяет сертификаты, проверяет
VB> подписи, мне не
...
VB>>> защита от подделки подписи/сертификата.
SEL>> Сертификат - понятие не алгоритмизируемое, быть может, лучше без него?
VB> Сертификат понятие единое и речь тут, читай выше, не о сертификате, а о его
SEL>> Сертификат - понятие не алгоритмизируемое, быть может, лучше без него?
VB> проверке и защите, что очень хорошо описывается теми-же
VB> TLS/SLT и иже с ними, а это уже принятые алгоритмы.
Если ты сам и твои пользователи доверяют этому самому "CERT",
то стройте цепочку доверия с ними и получайте сертификаты там,
просто надо учитывать риск повторения судьбы DigiNotar.
Можешь организовать собственное подразделение, которое будет
поддерживать собственный корпоративный удостоверяющий центр.
Быть может, к нему будет доверия больше, хотя не факт.
TLS/SSL не описывают не только построение цепочки доверия, но и
вообще любые аспекты проверки сертификатов (замечу что есть
CipherSuite вообще без закрытых ключей и сертификатов,
использующие PSK).
А поддержание доверия между пользователями и удостоверяющим
центром, это не алгоритм, а организационный процесс. Здесь
нужен не "технарь", а нормальный "безопасник".
В любом случае, при использовании сертификата, ты меняешь один
геморрой на другой геморрой, и именно поэтому я тебе советовал
подумать на тему "может, лучше без него?"
VB> Предполагается поверх шифра сертификатом, т.е. после авторизации передавать
VB> данные по синхронному каналу, алгоритм для него уже определен XTEA3. Посему
Хм. XTEA, интересно из каких соображений?
А какой алгоритм имитозащиты (MAC/HMAC) определён?
VB> интересует: алгоритм, именно, алгоритм проверки сертификата, алгоритм защиты
VB> сертификата от атак типа "подделка копией", "пересылка через хост" и, если
Что-то я не понимаю твоей терминологии. Если вести речь о защите
сертификата и закрытого ключа (ключа подписи), то зависит от
технологии избранного удостоверяющего центра. В любом случае,
для небольшой сети, прямо на удостоверяющем центре создаётся
и то, и другое, записывается на ключевой носитель и вручается
пользователю.
Hо причём здесь "пересылка через хост"? Если же речь вести про
протокол аутентификации, то обычными мерами, обе стороны должны
предъявить: элемент идентификации (с привязкой к сетевому
идентификатору), "элемент свежести", в результате должен быть
выработан код аутентификации, который должен будет в последствии
использовался для привязки протоколов более высокого уровня к
сессии.
Потом доказываешь теорему (ну, или строишь "правдоподобное"
рассуждение) о корректности построенного протокола. Затем
приносишь полученное криптографу или математику, которому
доверяешь, и вы выносите вердикт: возвратится к самому началу,
или уже и так сойдёт.
Возьми учебник, например, Венбо Мао, "Современная криптография.
Теория и практика", подбери похожий протокол, например, IKE.
VB> нечего сказать кроме "пошел на gost.ru", тогда лучше молчать совсем.
А какой был вопрос? Про алгоритм близкий к идеалу? Так он там есть!
Victor Blood
Mar 8, 2012, 1:45:50 AM3/8/12
to
Приветствую тебя, Serguei!
Ответ на сообщение Serguei E. Leontiev (2:5020/400) к Victor Blood,
написанное 08 Mar 12 в 03:08:
Ответ на сообщение Serguei E. Leontiev (2:5020/400) к Victor Blood,
[xskip]
VB>> Предполагается поверх шифра сертификатом, т.е. после авторизации
VB>> определен XTEA3. Посему
SEL> Хм. XTEA, интересно из каких соображений?
SEL> А какой алгоритм имитозащиты (MAC/HMAC) определён?
Ну, уж если поточному шифру нужна имитовставка, то лучше использовать
естественно MAC, что такое HMAC - я незнаю, а вот MDC не удовлетворяет условиям
использования. Но, вот сложно мне кажется заниматся спуфингом в шифрованый
канал, где ключ изменяется каждые n-бит. Ну а ГОСТ 28147-89 определяет хэш
функцию с результатом от 4 до 8 байт (MAC). Проверка ЭЦП на потоке не
рентабельна.
VB>> интересует: алгоритм, именно, алгоритм проверки сертификата,
VB>> "пересылка через хост" и, если
SEL> Что-то я не понимаю твоей терминологии. Если вести речь о защите
SEL> сертификата и закрытого ключа (ключа подписи), то зависит от
SEL> технологии избранного удостоверяющего центра. В любом случае,
SEL> для небольшой сети, прямо на удостоверяющем центре создаётся
SEL> и то, и другое, записывается на ключевой носитель и вручается
SEL> пользователю.
SEL> Hо причём здесь "пересылка через хост"? Если же речь вести про
SEL> протокол аутентификации, то обычными мерами, обе стороны должны
SEL> предъявить: элемент идентификации (с привязкой к сетевому
SEL> идентификатору), "элемент свежести", в результате должен быть
SEL> выработан код аутентификации, который должен будет в последствии
SEL> использовался для привязки протоколов более высокого уровня к
SEL> сессии.
SEL> Потом доказываешь теорему (ну, или строишь "правдоподобное"
SEL> рассуждение) о корректности построенного протокола. Затем
SEL> приносишь полученное криптографу или математику, которому
SEL> доверяешь, и вы выносите вердикт: возвратится к самому началу,
SEL> или уже и так сойдёт.
SEL> Возьми учебник, например, Венбо Мао, "Современная криптография.
SEL> Теория и практика", подбери похожий протокол, например, IKE.
VB>> совсем.
SEL> А какой был вопрос? Про алгоритм близкий к идеалу? Так он там есть!
Хм. Книжки почитаем.
0 new messages