Предположим, я продаю Алисе и Бобу сервис типа VPN, позволяющий им через мой сервер обмениваться пакетами данных (пакеты небольшие, ~1.5K, но трафик может быть большой).
Внутри себя эти пакеты либо зашифрованные, либо не нуждаются в шифровании. В общем, это личное дело Алисы и Боба. Мое же дело, чтобы халявщица Ева не могла использовать мой сервер, не договорившись со мной.
Очевидное решение — я договариваюсь с Алисой и Бобом (с каждым по отдельности) о секретный ключах, и дальше пакеты от них ко мне приходят зашифрованными и подписанными каким-нибудь AES-GCM'ом.
Но шифрование-то на самом деле не нужно, и мне как-то обидно тратить мегагерцы своего сервера на расшифровывание, если мне, на самом деле, надо только проверить аутентичность отправителя.
В связи с этим ищется Message Authentication Code (MAC), обладающий следующими свойствами:
1. Проверка пакета должна быть существенно дешевле, чем AES-GCM. При этом предполагается, что сервер работает на современном интеловском железе с аппаратным ускорением AES'а
2. Нет ничего страшного, если Ева сможет на халяву пробросить несколько пакетов, или даже несколько десятков пакетов. Лишь бы она не смогла организовать поток. Т.е., в отличии от обычного MAC'а, требования к секурности довольно слабые
3. Как следствие из 2-го пункта, изучение подписанных пакетов не должно помогать восстановить секретный ключ
Никто не подкинет идею, куда смотреть?
В частности, можно ли, например, использовать GCM без AES'а, или это небезопасно?
Здравствуйте, Pzz, Вы писали:
Pzz>....
Pzz>В связи с этим ищется Message Authentication Code (MAC), обладающий следующими свойствами: Pzz>1. Проверка пакета должна быть существенно дешевле, чем AES-GCM. При этом предполагается, что сервер работает на современном интеловском железе с аппаратным ускорением AES'а Pzz>2. Нет ничего страшного, если Ева сможет на халяву пробросить несколько пакетов, или даже несколько десятков пакетов. Лишь бы она не смогла организовать поток. Т.е., в отличии от обычного MAC'а, требования к секурности довольно слабые Pzz>3. Как следствие из 2-го пункта, изучение подписанных пакетов не должно помогать восстановить секретный ключ
Pzz>Никто не подкинет идею, куда смотреть?
Pzz>В частности, можно ли, например, использовать GCM без AES'а, или это небезопасно? RSA?
а вы здесь каким боком ?
в любом сценарии алиса и боб могут обменяться идентами через вас, и дальше общаться напрямую без вас
получается вы нужны только один раз, а значит подойдет любой аутентификатор
Здравствуйте, reversecode, Вы писали:
R>а вы здесь каким боком ? R>в любом сценарии алиса и боб могут обменяться идентами через вас, и дальше общаться напрямую без вас R>получается вы нужны только один раз, а значит подойдет любой аутентификатор
Я здесь сервер, который пересылает пакеты. И я не хочу пересылать пакеты от Евы.
Как договориться отдельно с Алисой и Бобом о секретных ключах, я понимаю. Вопрос был, как потом эти секретные ключи экономичным образом к каждому отдельному пакету применить. Поэтому, что как сделать это не экономичным образом, я сам знаю.
Вопрос же о том, как Алиса и Боб установят доверие между собой, в данном топике не рассматривается.
как сертификаты работают разберетесь ?
вы корневой сертификат
ева и боб ваши под сертификаты которые вы им выдали
ева и боб смогут проверить на своей стороне о том что полученные данные подписаны не васей пупкиным
после того ева и боб обмениваются публичными ключами
и дальше через сервер(вас) идет уже зашифрованный контент который вы не видите
Здравствуйте, Pzz, Вы писали:
Pzz>Никто не подкинет идею, куда смотреть?
Посмотрите реализацию kerberos. Там MAC получается путём шифрования случайной величины симметричным ключом и результат её шифрования добавляется к пакету вместе с зашифрованной величиной.
У вас и отправителя есть секретный ключ для проверки результата шифрования. У Евы его не будет.
Здравствуйте, vmpire, Вы писали:
Pzz>>Никто не подкинет идею, куда смотреть? V>Посмотрите реализацию kerberos. Там MAC получается путём шифрования случайной величины симметричным ключом и результат её шифрования добавляется к пакету вместе с зашифрованной величиной.
Эээ. А содержимое пакета в генерации МАКа участвует?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, vmpire, Вы писали:
Pzz>>>Никто не подкинет идею, куда смотреть? V>>Посмотрите реализацию kerberos. Там MAC получается путём шифрования случайной величины симметричным ключом и результат её шифрования добавляется к пакету вместе с зашифрованной величиной.
Pzz>Эээ. А содержимое пакета в генерации МАКа участвует?
Не помню как в kerberos. Вроде бы там не участвует, но участвует текущее время, чтобы защититься от replay.
Но вы можете сделать, как вам удобно.
Здравствуйте, vmpire, Вы писали:
Pzz>>Эээ. А содержимое пакета в генерации МАКа участвует? V>Не помню как в kerberos. Вроде бы там не участвует, но участвует текущее время, чтобы защититься от replay. V>Но вы можете сделать, как вам удобно.
Я понимаю, что можно взять блочный шифр в любом разумном режиме, и в качестве бесплатного приложения получить еще и МАК.
Но поскольку именно шифрование мне не нужно, я хочу обойтись без него, потому что оно чего-то стоит, даже если это AES с аппаратным ускорением. Мне нужен только МАК, причем не обязательно очень "сильный".
Мне казалось, что я в первоначальном письме достаточно ясно изложил, что мне нужно, и почему...
Здравствуйте, Pzz, Вы писали:
Pzz>>>Эээ. А содержимое пакета в генерации МАКа участвует? V>>Не помню как в kerberos. Вроде бы там не участвует, но участвует текущее время, чтобы защититься от replay. V>>Но вы можете сделать, как вам удобно. Pzz>Я понимаю, что можно взять блочный шифр в любом разумном режиме, и в качестве бесплатного приложения получить еще и МАК. Pzz>Но поскольку именно шифрование мне не нужно, я хочу обойтись без него, потому что оно чего-то стоит, даже если это AES с аппаратным ускорением. Мне нужен только МАК, причем не обязательно очень "сильный".
Дело в том, что шифрование только фиксированной маленькой части сообщения — очень дёшево.
Pzz>Мне казалось, что я в первоначальном письме достаточно ясно изложил, что мне нужно, и почему...
То, что Вы изложили я прекрасно понял. Но поняли ли Вы, преимущества того, что я предлагаю?
Здравствуйте, Pzz, Вы писали:
Pzz>В связи с этим ищется Message Authentication Code (MAC), обладающий следующими свойствами: Pzz>1. Проверка пакета должна быть существенно дешевле, чем AES-GCM. При этом предполагается, что сервер работает на современном интеловском железе с аппаратным ускорением AES'а Pzz>2. Нет ничего страшного, если Ева сможет на халяву пробросить несколько пакетов, или даже несколько десятков пакетов. Лишь бы она не смогла организовать поток. Т.е., в отличии от обычного MAC'а, требования к секурности довольно слабые Pzz>3. Как следствие из 2-го пункта, изучение подписанных пакетов не должно помогать восстановить секретный ключ
Pzz>Никто не подкинет идею, куда смотреть?
Попробуйте глянуть на UMAC (и его аналог VMAC для x64), Poly1305 и Badger.
Здравствуйте, vmpire, Вы писали:
Pzz>>Мне казалось, что я в первоначальном письме достаточно ясно изложил, что мне нужно, и почему... V>То, что Вы изложили я прекрасно понял. Но поняли ли Вы, преимущества того, что я предлагаю?
именно просто хеш
потому что в вашей формулировке это выглядело как некий алгоритм с применением MAC
если просто просили — какой хеш для мак применить, даже гугл сразу ответил бы
вообщем правильная постановка вопроса(да еще и понятная) как всегда уже является ответом
Здравствуйте, reversecode, Вы писали:
R>именно просто хеш R>потому что в вашей формулировке это выглядело как некий алгоритм с применением MAC R>если просто просили — какой хеш для мак применить, даже гугл сразу ответил бы
Мне нужен MAC. Хэш тоже подходит, если он 1) достаточно секурный 2) достаточно быстрый. Как сделать из хэша MAC, я знаю. Но я согласен и на другие методы.
R>вообщем правильная постановка вопроса(да еще и понятная) как всегда уже является ответом
Что было не понятно в изначальной постановке вопроса?
