| |
| 2.10, Аноним (10), 15:12, 13/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Майнинговую ферму свою перепрофилируй. Всё больше толку от неё будет
| | |
| |
| 3.48, Аноним (48), 09:33, 14/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
не будет. майнинг это хороший вклад, прибыльный. умный выбор
| | |
| |
| 4.79, GentooBoy (ok), 20:57, 15/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Если вы получите подделанный сертификат гугла или фейсбука то ферму окупите сразу несколько раз.
| | |
|
|
|
| |
| 2.4, Ivan_83 (ok), 14:27, 13/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Не давно, не пора.
Отказыватся имеет смысл там, где оно используется напрямую и в целях безопасности.
В HMAC конструкции он, как и md5 скорее всего ещё безопасен и долго будет безопасен.
В git оно используется не в целях безопасности, поэтому sha1/md5/md4 или что похуже - пофик, для безопасности там pgp прикручивается сбоку.
| | |
| |
| |
| |
| 5.8, Deny (?), 15:10, 13/05/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Извините,не понял аналогии.Я предпочитаю использовать современные инструменты.Да,бывают ситуации,где необходимо думать о поддержке разнообразного легасти, но если можно обо
| | |
| |
| 6.9, Deny (?), 15:11, 13/05/2019 [^] [^^] [^^^] [ответить]
| –3 +/– |
йтись без этого,то я предпочту пользоваться современными вещами.
Странно,обрезало сообщение
| | |
| |
| 7.15, Ан (??), 16:07, 13/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Потому что дешевле с точки зрения использования ресурсов компьютера. Такие вещи вы и сами должны понимать)))
| | |
|
|
|
| 4.28, Ivan_83 (ok), 18:57, 13/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Затем, что местами оно приколочено на гвозди (md5 в RADIUS без вариантов), а секурность в том же гите от sha1 не зависит, там для этого другие инструменты.
А так, я же не настаиваю на sha1 в том же ssh/tls, наоборот, sha2-256 там весьма не плох, и нынче он аппаратно считается в райзенах. (sha1 тоже аппаратно считается, а вот sha2-512 нет).
| | |
| |
| 5.60, КО (?), 11:59, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>а секурность в том же гите от sha1 не зависит, т
там от него зависит превращение репозитария в тыкву.
| | |
| |
| 6.64, Ivan_83 (ok), 16:04, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Покажи примеры репозиториев которые превратились в тыкву из за sha1.
| | |
|
|
|
| 3.18, OpenEcho (?), 16:19, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
"HMAC is a specific type of message authentication code"
HMAC гарантирует защиту от подмен используя Merkle-Damgård конструкцию _только_ при условии, что используемя хэш функция не имеет коллизий
MSG: казнить нельзя, помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86
а теперь представте, что приказ пришел на ваше пожалование, но ваш недруг нашел коллизию в MD5 и подменил оригинал на:
MSG: казнить, нельзя помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86
результат - секир башка
Это так, к слову о "безопасен"...
| | |
| |
| 4.19, Аноним (19), 16:47, 13/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс в 20 мегабайт
| | |
| |
| 5.21, OpenEcho (?), 17:53, 13/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс
> в 20 мегабайт
А мы разве живем не во времена, где paypal.com.abracadabra.top - "нормальное", каждодневное явление?
| | |
|
| 4.24, rty (?), 18:19, 13/05/2019 [^] [^^] [^^^] [ответить] | +/– | При атаке HMAC, злоумышленник не сможет генерировать пару 171 сообщение 187... большой текст свёрнут, показать | | |
| |
| 5.25, OpenEcho (?), 18:36, 13/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– | |
HMAC - это не шифровка, а упрощенно - цифровая подпись:
hmac = хэш(секрет+сообщение+секрет+опционально случайность)
где только "секрет" - неизвестное значение, поэтому если хэш функция имеет коллизии, то такая подпись - фуфло
| | |
| |
| 6.39, Sw00p aka Jerom (?), 22:06, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>HMAC - это не шифровка, а упрощенно - цифровая подпись:
Да, не шифровка, но цифровая подпись - шифровка хеша (с помощью приватного ключа в случае RSA). Минус HMAC - нужно согласовывать секретную часть, пихаемую в месте с сообщением в хеш функцию.
пс: md5('blavlablasecretstring' + 'message text') - вот банальный MAC
| | |
| 6.47, Sw00p aka Jerom (?), 23:43, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>поэтому если хэш функция имеет коллизии, то такая подпись - фуфло
все хеш функции по определению имеют коллизии
| | |
| |
| 7.51, anonymous (??), 10:00, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Речь про известный алгоритм по изменению входных данных при сохранении результирующего hash-а.
| | |
| |
| 8.61, КО (?), 12:02, 14/05/2019 [^] [^^] [^^^] [ответить] | +/– | не речь про поиск двух фраз имеющий общую часть и одинаковый hash, это не то же ... текст свёрнут, показать | | |
|
|
| 6.56, RJ (?), 11:43, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>если хэш функция имеет коллизии,
Практически любая функция свертки с меньшим количеством информационных битов, чем в оригинале, имеет коллизии.
| | |
| 6.65, Ivan_83 (ok), 16:10, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
hmac выглядит совсем иначе.
В начале там берут хэш от секрета, далее в этом хэше половину битов каждого байта скармливают на вход хэш функции, потом вливают туда все данные и в конце оставшиеся половинки от хэша с секретом.
Но да, ты прав насчёт того что такая функция не спасёт от подделки защищаемых данных, но зато она всё ещё гарантирует не возможность восстановить секрет.
| | |
|
| |
| 6.31, Ivan_83 (ok), 19:01, 13/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
И никто не стремится переезжать на sha3, я что то вообще не видел его нигде.
| | |
| |
| 7.35, rty (?), 20:03, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Имхо в sha3 сомнительная функция f, а про саму модель sponge я ничего плохого не видел.
Вместо блочного шифра с фиксированным ключом авторы keccak придумали свою функцию, которая по вроде как обладает свойствами PRP.
Максимальный размер блока у современных шифров 512 бит, а максимальный размер состояния keccak 1600 бит, поэтому как сделать лучше при сохранении размера состояния я не знаю. EME какое-нибудь.
| | |
|
|
| |
| 6.50, anonymous (??), 09:54, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
В Вашем случае Вы, видимо, упёрлись в диск. Попробуйте с tmpfs повторить этот же эксперимент.
| | |
|
|
| 4.29, Ivan_83 (ok), 18:58, 13/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
А ты уверен что это так?
Я где то читал что md5 хоть и "сломали" но в hmac он типа всё ещё безопасен.
| | |
| |
| 5.40, Sw00p aka Jerom (?), 22:11, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> но в hmac он типа всё ещё безопасен.
ну да, там и ксоров ключа с сообщением и с константами понадобавили вот и все, сам по себе HMAC это, что-то вроде
md5('blablablasecretstring' + 'message text')
| | |
| |
| 6.66, Ivan_83 (ok), 16:14, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Я выше написал что из себя представляет hmac.
То что ты называешь ксором с константами - на самом деле извлечение отдельных битов из байтов хэша секрета.
| | |
|
|
|
| 3.32, OpenEcho (?), 19:35, 13/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>для безопасности там pgp прикручивается сбоку.
Если публичные PGP ключи не передаются из рук в руки под подпись, то грош цена такой безопасности c PGP/GPG. Я как то показывал FreeBSD проекту как я стал "security-officer" зарегистрировав на MIT-ишном сервере ключей свой ключ 5180E90F с таким же именем. Никаких проблем, каждый это может сделать.
Или должны быть 3rd party центры сертификации, которые проверяют паспорт и соответствие физиономии и подписывают своим ключом и несут ответственность за верификацию или передавать публичные ключи из рук в руки(как это делается в банках), иначе нет никакой гарантии, что ключ, которым подписали принадлежит действительно хозяину, только надежда, не больше, что это правда тот за кого себя выдает.
| | |
| |
| 4.37, xm (ok), 20:49, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Теперь у нас есть DANE для этих целей. Вопрос в его поддержке софтом.
| | |
| |
| 5.38, OpenEcho (?), 21:30, 13/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Думаете гугля позволит? Они так тщательно загоняют всех в CT стойло, а DANE, imho для них облом
| | |
|
| 4.49, Crazy Alex (ok), 09:53, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Ну вот в том же bitcoin core PGP-ключи используются. И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии, с другой - это был бы лакомый кусок для атаки (основной биткоин клиент же). И как-то подмен не видать, хотя большая часть пользователей не получала ключи "из рук в руки". Достаточно, что эти ключи перекрёстно подписаны и опубликованы во многих источниках.
P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы ключ принадлежал той самой сущности, что коммиты делает, а так будь это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности репы некритично совершенно.
| | |
| |
| 5.67, OpenEcho (?), 18:46, 14/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии,
Не факт...
> И как-то подмен не видать, хотя большая часть пользователей не получала
> ключи "из рук в руки".
А то что вы не видите подмен, - это значит что у вас не таких мощностей и доступа. Блокчэин не так уж хорошо защищен как вы думаете, - атака "51%" уже была успешно применена как миниум на 5-ти криптовалютах.
Оставим майнеров и посмотрим на простейшее. Предположим я имею возможность следить за вами, за всеми вашими девайсами и точками входа в интернет. Дальше все очень просто:
перехват вашего конекта, генерация новых ключей и отправка контента от вашего имени с моими ключами, на обратке - перепаковка с вашими ключами и доставка на ваши девайсы. Classic MITM атака. Помог PGP/GPG если ключи не были переданы из рук в руки?
> Достаточно, что эти ключи перекрёстно подписаны
> и опубликованы во многих источниках.
Ну а теперь - честно, как много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были случаи компроментирования и на довольно известных проектах.
> P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы
> ключ принадлежал той самой сущности, что коммиты делает, а так будь
> это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности
> репы некритично совершенно.
о какой безопасности речь ???
X = сущность
Y = issued-by(X)
верить Y которая принадлежит X ???
а еще X может генерить новые ключи каждый день...
и тогда вообще не понятно, а та ли это сущность X
| | |
| |
| 6.72, Sw00p aka Jerom (?), 02:18, 15/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Ну а теперь - честно, как много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и >рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и >перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет >механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были >случаи компроментирования и на довольно известных проектах
Соглашусь только с одним, что PGP и его сеть доверия, основанная на взаимных подписываниях ключей всей сетью, не спасет от так называемого "внедрения" злоумышленника в эту сеть, особенно в современных реалиях, когда порой эта сеть доверия состоит из людей которые друг друга в глаза не видели, а чисто по ынтернету.
Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему каналу связи (при личной встрече, по телефону и т.д.)
| | |
| |
| 7.74, OpenEcho (?), 15:24, 15/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему
> каналу связи (при личной встрече, по телефону и т.д.)
Так именно об этом я и говорил в начале, PGP эффективен только в случае, если ключи передаются из рук в руки (если вы знаете голос человека, его повадки, то можно и через телефон, но самое надежное - как в банках - из рук в руки и под подпись)
Но это все работает только в случаях личных знакомств, верить же PGP подписям на Github для примера, где вы не знаете кореспондента лично или в случаях с бинарными пакетами в юникс системах - это просто вера на слово. Вы видели людей, которые перед установкой redis звонят в проект и докапываются кто подписал пакет и сверяют с неизвестным X фингерпринт?
| | |
|
|
|
| 4.52, anonymous (??), 10:31, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Не обязательно из рук в руки. По любому (хоть открытому) каналу с аутентификацией отправителя и гарантей сохранности сообщения.
Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролю, другому ключу (владелец которого достоверно известен) и т.п.
Да и вообще в культуре использования PGP (из того что видел я) два одновременных валидных ключа на один ящик вызывают вопросы и повышенную осторожность.
Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для вашего закрытого ключа).
| | |
| |
| 5.68, OpenEcho (?), 19:36, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Не обязательно из рук в руки. По любому (хоть открытому) каналу с
> аутентификацией отправителя и гарантей сохранности сообщения.
> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь
> на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролю
Здесь в соседней новости про взлом Github-овских экаунтов...
Помогла аутентификация?
> , другому ключу (владелец которого достоверно известен) и т.п.
Где эта самая достоверность в PGP/GPG ?
> Да и вообще в культуре использования PGP (из того что видел я)
> два одновременных валидных ключа на один ящик вызывают вопросы и повышенную
> осторожность.
И много вы знаете реальных людей, которые вообще смотрят за ключами и добросовестно сверяют с публичными key серверами сколько там ключей? Это хорошо если они там вообще опубликованы.
Вот именно, что кроме вызывания вопросов, текущая культура примения PGP ключей не вызывает больше ничего. Ну да, механизм криптографии высок, а толку от него если origin unknown ?
Видимость надежности, но не надежность т.к. без достоверной 100% гарантии принадлежности ключа - это не надежней чем просто верить на слово
> Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё
> равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для
> вашего закрытого ключа).
Элементарная MITM атака и прийдет пушистый, белый арктический зверек
| | |
| |
| |
| 7.78, anonymous (??), 20:23, 15/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
P.S.: Переформулирую: вообще да, просто так доверять никакому ключу, конечно же не стоит. А если есть дополнительные подозрительнеы признаки (а-ля лишние ключи), то нужно быть вдвое осторожным. Но обычно люди используют сторонние аутентицирующие каналы, и это не всегда встречал IRL с паспортом в руке (тем более, если человека знаешь много лет).
| | |
| 7.84, OpenEcho (?), 00:29, 16/05/2019 [^] [^^] [^^^] [ответить] | +/– | Предыдущий себеседник, приводил пример, что если персона аутефицирована, то авто... большой текст свёрнут, показать | | |
|
|
| 5.73, Sw00p aka Jerom (?), 02:20, 15/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS
так это по определению уже не открытый канал связи. Обычно лично звонят по телефону и посимвольно сверяют фингерпринт.
| | |
| |
| 6.75, OpenEcho (?), 15:29, 15/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Обычно лично звонят
> по телефону и посимвольно сверяют фингерпринт.
Вероятно мы живем на разных планетах, т.к. я никогда не видел людей, которые "обычно звонят" в debian/CentOS/Gentoo... перед установкой операционки и при установке пакетов для сверки фингерпринта.
| | |
| |
| 7.76, Sw00p aka Jerom (?), 16:05, 15/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>перед установкой операционки и при установке пакетов для сверки фингерпринта
так не в этом случае, имелось ввиду PGP для писем.
| | |
| 7.85, Sw00p aka Jerom (?), 01:55, 16/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручками его потом на сервере проверить, а мы про pgp разговариваем. Много ли таких людей кто сверяет? А в случае с виртуальными машинами и их клонами, многие ли перегенерировали хост ключи? Новость даже такая была.
| | |
|
|
|
|
|
|
| 1.3, Аноним (3), 14:00, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> коллизия возникает при наличии определённых префиксов, независимо от остальных данных в наборе
Красота.
| | |
| |
| 2.13, КО (?), 15:52, 13/05/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Да не совсем, это вариация на тему уже показанная Google - метод создания коллизии, не метод подбора к существующему hash.
| | |
| |
| 3.14, КО (?), 15:56, 13/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– | |
поясняю, неточность в переводе статьи
для любых, наперед заданных, p1 и p2 можно подобрать такие m1 и m2, что
hash(p1||m1)=hash(p2||m2)
это не совсем тоже самое, что в переводе, что есть такие p1 и p2, что что не пиши в m1 и m2, результат хеширования не меняется. :)
| | |
|
|
| 1.6, педофил (?), 15:03, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Тогда получается, что можно взломать всё, куда удастся пропихнуть такой префикс? А это может стать отдельной уязвимостью?
| | |
| |
| 2.11, товарищ майор (?), 15:38, 13/05/2019 [^] [^^] [^^^] [ответить]
| –3 +/– | |
мне - можно. Ну, если тебя совсем не насторожит бредятина в начале файла - может.
А если ты для себя, любимого спрашивает - у тебя не хватит ресурсов.
И твоя майнинговая ферма по сравнению с моей - курам на смех (нет, ты думал, те китайские заводы по прозводству битков - крестьяне с рисовых полей вскладчину строили?)
| | |
|
| 1.12, Мексиканец (?), 15:43, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– | |
> веский аргумент для незамедлительного прекращения использования SHA-1, особенно в сертификатах и цифровых подписях.
А я давно юзаю SHA-512, правда при работе с файлами, любых размеров, вплоть до 60 Gb (копии iso blu-ray)
Не скажу, что сумма вычисляется долго на моём 6900K, но для меня важна 100% подлинность файла, особенно, когда бэкапы хранятся на HDD и M-Disc.
| | |
| |
| |
| 3.46, Аноним (46), 23:14, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
с crc32 даже в словаре аглийских слов можно найти несколько слов с одинаковым хешем. но конечно лучше чем ничего.
| | |
|
| 2.27, педофил (?), 18:46, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Некоторые люди слишком страдают беспокоясь маловероятных вещей. Да, я тоже.
Как избавиться от такого?
Хеши - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов. По идее. Нормальные люди не задумываются.
| | |
| |
| 3.41, Sw00p aka Jerom (?), 22:17, 13/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Хеши - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов.
ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятность
| | |
| |
| 4.57, КО (?), 11:52, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятность
Не возможно. Можно только увеличить. :)
Криптографический hash отличается тем, что вычислить другие варианты оригиналов сложно (в идеале не проще полного перебора комбинаций).
Но при этом вероятность того, что ваш меганакрученный пароль из ста слов имеет коллизию с одним символом пробел, тоже можно лишь попробовав. :)
| | |
| |
| |
| 6.87, КО (?), 17:55, 16/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Максимальный у hash=значение, но его легко подделать :)
| | |
| |
| 7.88, Annoynymous (ok), 12:56, 21/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
 > Максимальный у hash=значение, но его легко подделать :)
Максимальный у Hash>>значение, но он нахрен не нужен :-)
| | |
|
|
|
|
|
| 2.36, KonstantinB (ok), 20:35, 13/05/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Случайно вы не получите одинаковый хэш даже с MD5.
Ну, то есть, вероятность есть, но примерно такая же, как вероятность падения метеорита вам на голову.
А если к вашим HDD с бэкапами имеют неограниченный доступ посторонние люди, то скорее этот вопрос надо решать.
| | |
| |
| 3.58, КО (?), 11:53, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Случайно вы не получите одинаковый хэш даже с MD5.
Случайно CRC32 получить тяжело. Специально - гораздо легче.
| | |
|
|
| 1.16, Аноним (16), 16:10, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Дополнительно можно отметить публикацию результатов криптоанализа блочных шифров SIMON-32/64, разработанных АНБ США и в 2018 году утверждённых в качестве стандарта ISO/IEC 29167-21:2018
АНБ оно такое АНБ.
| | |
| 1.17, Аноним (17), 16:18, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ] | –2 +/– | Эта публикация - чья-то дурацкая шутка SIMON-32 64 - шифр с 32-битным блоком и ... большой текст свёрнут, показать | | |
| 1.33, Аноним (33), 19:39, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>При таком уровне вычислений ориентировочная стоимость атаки составляет менее ста тысяч долларов, что вполне по карману спецслужбам и крупным корпорациям.
Атаковать неуловимых Джо бабла не напасутся.
| | |
| 1.43, Виталий (??), 22:32, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
При тех же мощностях Гуглу нужно меньше двух дней, да уж безопасненько)))
| | |
| |
| 2.59, КО (?), 11:57, 14/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
На что? На то, чтобы создать сертификаты для www.google.com и www.microsoft.com с одинаковой подписью? Да. Но они оба будут игнорироваться браузером, потому что ему нужна другая.
Вот запороть git репо можно. Но цена вопроса в 100 тыс баксов. :)
| | |
|
|
