wizzard | Entries tagged with crypto

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

блин, это настолько круто, у меня просто слов нет чтобы обьяснить.

правда у таких технологий есть и минусы... короче, welcome to the brave new world где существуют ICE, SHODAN и вот это всё.

(1) http://www.theregister.co.uk/2016/02/09/researchers_break_homomorphic_encryption/
(2) http://research.microsoft.com/apps/pubs/?id=260989

Current Mood: amazed
Current Music: Frozen Synapse - Triumph
Crossposts: http://wizzard0.livejournal.com/552464.html

Я уже года три думал написать такой пост, и вот Мэтью Грин написал его за меня:

http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html

Там всё-всё правильно.

Crossposts: http://wizzard0.livejournal.com/453434.html

Encrypting a 128-bit block using a 128-bit secret shared AES key takes about 2 seconds using three machines. Decryption is not implemented yet.

Crossposts: http://wizzard0.livejournal.com/438686.html

Похоже, нашли способ с помощью active attacker ломать (перенаправлять) транзакции ДО того как они будут проверены майнерами и попадут в block chain.

https://www.mtgox.com/press_release_20140210.html

Напоминает историю с Android'ом, где code signing проверял одно, а лоадер загружал другое (обычно они проверяли одно и то же, но можно было сконструировать кейс, где алгоритмы в итоге шли к разным данным)

Далее транзакция уводится на левый кошелек, атакующий (или жертва) идет в саппорт Гокса и начинает возмущаться "гдебабло?", саппорт идет на blockchain, и видит, что бабла-то и нет! после чего начинает чесать репу.

В принципе, неудивительно, что можно наебать участника P2P сети, сконструировав для него filter bubble и проэмулировав остальную сеть, но за то, что это довели до практической реализации in the wild - очень большой респект.

UPDATE: другое мнение

Просто у мтгокса кривой софт, позволяющий обманывать биржу и тупые саппорты, не понимающие как работает биткоин. Эта «уязвимость» была опубликована на биткоин вики ещё год назад и про неё все знают.

Скорее всего они хотят стырить всё бабло под соусом «плохой биткоин дырявый мы не виноваты». Вот и всё.

Вкратце суть уязвимости. Я запросил вывод с мтгокса. Они сделали транзакцию. Я каким то образом успех перехватить транзакцию и послать главным майнерам подделку. Она подписана сигнатурой мтгокса, но хеш у неё другой (потому что в сигнатуру не входят некоторые поля). Майнеры её включают в цепочку, мтгокс по хешу проверяет и не находит. Я мтгоксу пишу мол денег не получал. Тупой саппорт делает ещё одну транзакцию.

Во-первых что им мешает взять адрес отправителя, адрес получателя и посмотреть, сколько денег было отправлено? Ничего не мешает, адреса генерятся без проблем сколько надо, тупой саппорт на блокчейне хоть сейчас может проверять транзакции.

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

UPDATE2: чтиво по теме

~~https://bitcointalk.org/index.php?topic=458129.msg5052671#msg5052671~~ блин, это не то, это по вопросу "как это на btce случилась сделка по $102"

http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/

Crossposts: http://wizzard0.livejournal.com/398700.html

Тут уважаемый 109 давеча высказал мысль, что compute-bound proof of work алгоритмы порождают бессмысленное специализированное железо, а вот memory-bound - порождают быстрое универсальное железо.

Я с ним, в целом, согласен (писал ранее о том, что IMHO производительность нынешних компов упирается в latency случайного доступа к памяти, которая растет гораздо медленнее гигагерц и гигабайт)

Ну и вот, сделали наконец довольно простой и годный алгоритм, который, к тому же, не ускоряется через time-memory tradeoff.

https://wiki.ethereum.org/index.php/Dagger

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

Теория графов и прочая дискретка FTW :)

Listen or download Fleur Разбег for free on Pleer

Current Music: Fleur - Разбег
Crossposts: http://wizzard0.livejournal.com/397994.html

Хехехе.

Пока идут всякие революции и прочие метания говном, настоящие прорывы происходят, как обычно, в тишине институтов.

Ну, всем известно что идеальный DRM построить нельзя, по определению? ("увидеть фильм" отличается от "скопировать фильм" все меньше и меньше, поскольку копировальная техника растет)

Так вот, DRM нельзя, а идеальный обфускатор - можно. Now with proofs.

Что дает нам идеально безопасный в значении "ключи невосстановимы" DRM, способ конструировать асимметричную криптографию из симметричной и, бинго, способ выполнять шифрованный код!

Welcome to the brave new world. Сейчас это доведут до ума, и будет новая волна изменений.

То есть безопасный SaaS, P2P SaaS, вирусы, которые невозможно проанализировать, и неломаемые триалы, и много-много еще чего ;-)

https://www.simonsfoundation.org/quanta/20140130-perfecting-the-art-of-sensible-nonsense/ (slashdotted)

http://eprint.iacr.org/2013/451.pdf
http://eprint.iacr.org/2013/631.pdf

Сижу читаю.

Crossposts: http://wizzard0.livejournal.com/396044.html

Есть, есть положительная динамика от излияний Сноудена.

Как-то так внезапно обнаружил, что в контактлисте уже 9 человек стали пользоваться OTR "по дефолту" (раньше был 1)

Так победим!

Crossposts: http://wizzard0.livejournal.com/370824.html

Астрологи обьявили день цифровых подписей.

Как с помощью openssl (ну или чего угодно, CNG, CryptoAPI, BouncyCastle, NSS, whatever) повесить на X.509 сертификат две подписи? (чтобы выразить факт доверия к intermediate CA1 со стороны root CA2 и root CA3, также известно как cross-signing)

Crossposts: http://wizzard0.livejournal.com/360174.html

а вы когда-нибудь задумывались, что обфускация кода в пределе эквивалентна гомоморфному шифрованию?

то-то мне исторически все время казалось, что в пейперах какие-то очень похожие концепции проскакивают...

Crossposts: http://wizzard0.livejournal.com/352992.html

Google confirms critical Android crypto flaw used in $5,700 Bitcoin heist

Java Crypto weakness could affect security in hundreds of thousands of apps.

http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/

1. Еще одно подтверждение тому, что генератор случайных чисел - критически важная штука
2. Используешь самописное? С высокой вероятностью всё плохо. Используешь стандартное? Доверяй, но проверяй.

К счастью, в случае с энтропией "доверять, но проверять" просто - берем энтропию из системного генератора, подмешиваем туда какой-нибудь своей, хуже не станет. Гм... Подмешивать, конечно, тоже надо правильно. Ну да ладно ;)

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

Crossposts: http://wizzard0.livejournal.com/339806.html

JFYI: Дмитрий Котеров (http://dklab.ru) делает систему расчета и анализа статистики (я так понял, заточенную на website analytics), работающую с шифрованными данными (вычисления максимально вынесены на железо клиента, а сервис лишь роутит/фильтрует обезличенные пакеты)

Очень приятная новость на фоне всех последний событий.

Тем, кто решит последовать его примеру и захочет зашифровать данные в своей БД: есть прекрасная книга, Translucent Databases 2Nd Edition: Confusion, Misdirection, Randomness, Sharing, Authentication And Steganography To Defend Privacy, которая ответит на целую кучу вопросов и убережет от типичных ошибок.

Ну а если вопросы все равно останутся - обращайтесь %)

Crossposts: http://wizzard0.livejournal.com/337955.html

tl;dr: задача ICFPC этого года эквивалентна построению универсальной ломалки для асимметричной криптографии (восстановить trapdoor-функцию с помощью chosen-plaintext атаки и оракула организаторов) вряд ли это intended, но забавно.

В связи с этим вопрос: есть ли вообще какие-либо статьи по применению SMT солверов для оптимизации решения discrete logarithm или factoring problem?

Current Location: L2
Crossposts: http://wizzard0.livejournal.com/336173.html

Кто-то знает, сабж секьюрен или нет? На первый взгляд гугл ничего не находит.

Если вдруг кто в курсе - буду благодарен за инфу.

As you probably know, a digital signature is a virtual "seal" that proves that some message has originated from a particular person in possession of a private key.

Let's try to look at this "seal" from the information-theoretic perspective.

We want to reach 128-bit security, i.e. a random guess should have a 1 in 2^128 chance getting a signature right.

Then, the public key is an encoding of a trapdoor function which can map X 256-bit messages into some thumbprint, where there are 2^256 ways (or more) to construct this trapdoor.

( so? )

Meanwhile, everybody knows SSL certificates arent 22 MB but only about 5-20 KB in length. Something just doesnt seem right.

So... anybody else still surprised why DSA, ECDSA, Winternitz, *MSS and other signature schemes allow Rob to compute the private key so easily if Sam does not rigorously follow restrictions of nonce, padding and so on?

This is also the reason I consider most signature schemes being insecure (as in, fundamentally susceptible to cryptanalysis, especially under the chosen-message attack)

( references )

Current Location: L2
Crossposts: http://wizzard0.livejournal.com/321593.html

It has come to my mind that you can combine SMP (socialist millionaires protocol) and Kish-Sethuraman protocol to get a protocol which is both IT-secure and can be bootstrapped without all the key management burden.

So, I tried to outline the way how exactly they should be combined and what properties will the resulting construction have.

You can read the draft of the article here:

http://tvori.info/people/wizzard/writings/2013/nikitin-mits-draft.pdf

EDIT: Article updated with the shared secret reuse limitations.

Since this is both my first TeX article and first contribution to the cryptography field, any feedback is greatly appreciated.

Thanks!

Current Location: L2
Crossposts: http://wizzard0.livejournal.com/320610.html

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

Решения, работающего во всех случаях, так до сих пор и не придумал. Зато придумали сабж. Похоже, он возможен. Надо писать статью.

Интересно, будет ли кто-то в реальности пользоваться протоколом, где key exchange занимает два часа и десятки мегабайт трафика? :D

Crossposts: http://wizzard0.livejournal.com/320010.html

In many contexts it is quite hard to provide a hard guarantee about not repeating counters, eg can be hard to retain state eg javascript in different browsers on different machines for a roaming user, or in VMs that get rolled back, or disks that get recovered from backup. Also time is unreliable on user machines often. And sources of randomness can also be questionable in some browsers, VMs after rollback, and freshly imaged servers or VMs, or servers with no keyboard/mouse etc.

To have a crypto protocol which does not catastrophically break in event of a one in 100 chance per year of hardware boundary condition happening to your the compute environment is therefore a good idea. Or occasional failure to avoid reuse. There are more protocol fragility levels than "safe" and "broken". A third option is graceful degradation.

ie if you end up falling back to ECB of two different plaintexts for first cipher block of CBC barely hurts. Sending plaintext xors hurts alot.

Bear in mind disks as a rule of thumb fail at a rate of 1%/year and the hardware also similar (motherboard, memory, powersupply etc added together).
And when that happens a VM rollback or a disk replacement and backup recovery are likely to be the method of recovering. If your crypto is not tolerant to that environment you maybe have a problem. And its not outside of the realm of feasible that the attacker can externally influence the hw failure rate.

Similarly reusing k values in DSA/ECDSA is even more catastrophic, leaking the private key. (For DSA a counter-measure can be to generate k from MAC(secret, message) so that if the same message is signed, the same k value is used (which is obviously harmless as its the same serialization).

Adam Back <adam@cypherspace.org>

Crossposts: http://wizzard0.livejournal.com/316613.html

miTLS is a verified reference implementation of the TLS protocol. Our code fully supports its wire formats, ciphersuites, sessions and connections, re-handshakes and resumptions, alerts and errors, and data fragmentation, as prescribed in the RFCs; it interoperates with mainstream web browsers and servers. At the same time, our code is carefully structured to enable its modular, automated verification, from its main API down to computational assumptions on its cryptographic algorithms.

да, я в код не то чтобы очень внимательно смотрел, но изучить в любом случае стоит.

Crossposts: http://wizzard0.livejournal.com/295745.html

а вот, предположим, у нас есть классное долгоживущее приложение.

схему базы данных (sql, nosql, неважно) время от времени приходится менять, данные конвертить, и прочее. предположим, мы эту проблему даже решили

предположим также, что у нас все круто пошифровано, и сервер не может ничего расшифровать, только клиенты.

и, эээ, ммм, ыыы, а как *в этом случае* апгрейдить базу? )

Current Location: L2
Crossposts: http://wizzard0.livejournal.com/276361.html

Казалось бы, сколько времени уже интересуюсь разнообразной криптографией и около того - но мысль, что "криптосистема, собранная из доказанно надежных элементов, вставленных в доказанно надежную схему, не является доказанно надежной до построения отдельного доказательства", до сих пор не укладывается в моей голове %)

Хотя, казалось бы, математика, все четко и предсказуемо, то-се, не какие-нибудь там философские выкладки или плохо специфицированные интерфейсы - ан нет..