• Как лучше разбираться в людях
    0
    Я прекрасно знаю о чем здесь говорит этот конкретный индекс masculinity (MAS).
    И ещё раз, это абсолютнейшая неправда (по крайней мере в сравнении с немцами).

    Если же отвлечься от этого и вернуться к вашему «наличию половых признаков», то тогда все еще хуже в Германии.
    Если хотите вот вам другая абстракция — нельзя быть мужиком «в быту» и бабой на работе. Ну то есть как бы можно, но это скорее исключение из правил, и уж точно не про русских.
  • Как лучше разбираться в людях
    +3

    Ну да. Вот это вот доставило особенно.


    В Германии PDI низкий, поэтому у них Меркель.

    Во первых вовсе не поэтому, а потому что на выборах нельзя сказать "Нет" (т.е. большинство-то немцев как раз её ненавидит уже наелись фрау-мадам), ну и её партия набирает больше голосов "Да" (так исторически сложилось что их грубо две в Германии, кроме всякой мелочи, которой немало, а вторая слабее в настоящий момент). Т. е. тупо другие голоса "Да", которые НЕ ЗА Меркель, размываются… Поэтому уже больше полгода в Германии де факто нет правительства (и пока не видно перспективы...). Ну возможно следующая пятница покажет who is who, и пока в Германии совсем не исключены перевыборы.


    Мы более женственны, чем немцы.

    Это даже не смешно. Это просто даже не знаю как прокомментировать.
    Видимо понятие "женственны" у всех разное.
    Ну вот я лично знаком с несколькими десятками и немцев и русских, у меня язык не повернётся про кого-нибудь из той русской половины сказать он более "женственен" чем какой-нибудь самый "мужественный" из тех немцев. От слова совсем.
    (А судя по графику даже "не более", а как-то в два раза.)
    И я совсем не про "морду" там набить, напиться в дрова и подобные стереотипы (хотя и тут у нас какой-никакой запас прочности имеется).
    Я про картину в целом, что нормальный человек под "женственен" понимает, а именно "то не рана — то царапина", "не упал, а просто споткнулся", отношение к слабому полу (например вступится за даму и не пройти мимо), и т.д. и т.п.
    Даже просто тупо то же "могу/не могу поменять колесо на машине".
    Как кстати такие оценки делаются, если эти понятия у нас с ними разные в принципе, т.е. немцы себя по одной шкале, а мы совсем по другой оцениваем?

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Да.
    Я вам про то, что когда вы генерируете пару `h,r` (от `k`) вы можете остановить генератор на первом же подходящем `r`, при нужной его размерности (0,N).

    При подборе же злоумышленником, ему требуется перебрать уже гораздо больше значений (для единственного ему известного `r`, не для множества).
  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Для проверки подписи на стороне верификатора надо четко знать g

    Знаю, и что? Его (h) во первых необязательно делать вычисляемым (его можно передать в подписи — он масенький), а во вторых нельзя разве сделать "вычисляемым" (ака псевдо-зависимым) от тех же r, w, u1, u2 и т.д., т.е. до того как он будет нужен в вычислении v… Как я вам это выше предложил, типа с рекурсивным акронимом, и подобными штуками.


    Вы знаете для чего например DH-параметры при обмене ключами в TLS используются? При чем, они не обязательно вживляются в сертификат, который может быть любым (т.е. НЕ embedded in certificate), ими можно его сверху обернуть.
    Ну вот и здесь как-то так сделать.


    Ну и вы забыли про публичный ключ g^x.

    Я вовсе не забывал про публичный ключ — просто их может же быть несколько для пачки различных h из подписи.


    И если они не вычисляемы, как оно вероятно и будет в DSA, ибо думать лень/некогда пока трудно себе представляю, без открытия x, даже если их (секретов) тоже несколько, то...


    • либо "опубликовывать/хранить в устройстве" пачку y под это дело (знаю много, но вполне реально для например 10K h/g, что есть 384*10K = 3.8MB).
    • либо искать более подходящий для этого алгоритм (их слава богу кроме DSA целая куча есть, хоть те же микейи и иже с ними).
  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Естественно. И проверять не нужно было… Я ж написал, то «не хороший» пример, чисто в качестве иллюстрации к обсуждению про функцию сжатия… Т.е. если хотите, только чтобы направление мысли обрисовать.
  • Каждую пятницу я в… Пик Балмера — есть ли за ним правда?
    0
    Я просто оставлю это здесь…
    Алексей Водовозов. «Вино запрещено, но есть четыре но...» — YouTube
    Там кстати тоже этот «эффект» упоминался.

    И да, два раз «пережил» это состояние (причем с разными «дозами», но оба раза кратковременно). Видимо редко пробую (работать в таком виде;)
  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Но для них и k надо другое, с-но и затраты на его подбор.

    Да, но это был аргумент против радужной таблицы...


    Еще раз очените затраты на перебор k(0,q) на подгруппе для любых h(0,z)->g(0,p), r(0,N).


    И сравните это с подбором k(0,q) для конкретных значений h, r.

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    И этих k всего N штук.

    Это в результате их всего N.
    Перебрать же в этом случае под конеретное r нужно много-много больше.

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Тогда почему бы этой процедурой не воспользоваться злоумышленнику?

    Rainbow-tables?
    Потому что, количество таких g,k, ну или в нашем случае h,k на поле больших p (q) очень огромно.
    Т.е. он просто не знает какие мы "заготовили".
    Да и числа не маленькие, размер такой радужки будет невообразимым.


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


    но с другой вам по-хорошему нужны разные k

    Ну да, но мы же можем еще оперировать и hg соответственно).

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Все же k < q, т.к. modinv(k, q) = modinv(k+q,q)

    Уел, так уел. Всё так.


    Ну тогда здесь один вариант, сильно не уменьшать q.
    Т.е. подготавливаем множество g,k, дающих короткие r, и оборачиваем динамикой (передаем ее длину) в подписи.

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    > Подбор g потребует времени меньше, чем проверка подписи

    Вам понятие recursive acronym знакомо? Тут можно подобное сделать.

    > Если не совпало, берем G, умножаем на g…

    А понял теперь что вы имели ввиду под кэшированием…
    Нет, это то как раз понятно (я вам про этот алгоритм и написал — «fast modular exponentiation»)…
    Только не два, а три взятия остатка.

    Просто числа там огромные, и умножение и три взятия остатка на тех числах очень не быстро происходит.
  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Совсем не эквивалентная (для r), — для взлома вам нужно подбирать под конкретное единственное r.
    А для подписи подойдет любое в интервале, что согласитесь не одно и тоже.
    Кроме того, вы заранее их можете заготовить, под конкретное g (ну и постоянные p,q естественно).
  • Che Burashka и взлом систем продажи билетов на московские электрички
    0

    Да нет, тут немного другое, естественно оно дискретно распределится на оригинальной подписи.
    Вы там слово ЕСЛИ вырезали:
    В оригинале:


    если результат-подпись 280 разворачивается обратно без потерь (неполный перебор на стадии подписания).

    Как ускорить подпись для ускорения перебора (при этом замедлив праверку естественно) надеюсь понятно (подбором секретной экспоненты).


    И я там написал, что пример не очень хороший — просто как илюстрация.

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Вы правы, гляда на формулы (где в одном оно базис, в другом экспонента), забыл про modular multiplicative inverse, который там у s.
    Но всё же `k < p-1` а не `k < q` как предлогалось…
  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Знания x и доменных параметров хватает для создания подписи.

    Ну дак а я вам уже который день талдычу, что вы не туда смотрите.
    Конкретно здесь это потому, что DSA на это заточен, т.е. чтобы раздать всем (p,q,g) и дальше работать только с переменными x,y (ака сессионная или пользовательская пара).


    А если оно нам так не нужно, т.е. именно в таком виде?


    Ну вы подумайте уже хоть немного…
    Вы формулу создания g у DSA помните?
       g = h(p-1)/q % p
    Т.е. даже при небольшом h вы имеете g в размерности p (очень большое).
    Т.е. если g не опубликовывать, а короткое h зависимо "примешать" в подпись, то подбирать нужно будет не только k, но и g (от неизвестной вычисляемой h).


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


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


    Поэтому k лежит в области [0;q) — любое значение сверх q даёт тот же результат, что в остатке от деления на q.

    Правда, что ли?!!!
    А это ничего, что k еще и в формуле подсчета s участвует? Т.е.:
       r = (gk mod p) mod q
       s = modinv(k, q)*(H + x*r) mod q


    Вы же правда не думаете, что при разных значениях k (длинном k1 и коротком k2), дающих одинаковый результат r, вы и одинаковый результат s тоже получите?
    У вас правда с математикой всё нормально?


    Т.е. надо перебрать всего 2^40 значений, чтобы его восстановить

    Всего?!
    Перебрать каким действием?


    Dual fast modular exponentiation (при этом с N(p)=3072 и N(g)=3072 бит)?
    Вы серьезно?!
    Я как-то подобное на FPGA делал, так оно десятки миллисекунд требует, скажем 45ms на итерацию, т.е. тогда грубо как результат что-то — posix 50996747245 (Thu Jan 09 04:07:19 CET 3586) на одной железке, на FPGA.
    При том что распараллеливание у вас только от k дискретно.
    Т.е. полный перебор.


    Мы ведь не рассматриваем вариант, что вы прямым возведением в степень (а потом по модулю) собирались пробовать? Правда ведь, нет? :).
    Иначе я не вижу, что вы там собирались кэшировать?
    Чисто ради интереса, возведите вот это вот прямым способом в степень:


    Скрытый текст

    Значения на prime/и взаимную-простоту для q и p-1 не проверял, т.е. пример чисто для "размерности" чисел...


    set k 380078191597288277774210015182069419003282106052601533840669828472257391788
    set g 964216767853194139370498842359060632002603481743785309112813027583646753097005635661674579467787416550104153740593745724913462510171495942810356243629488841783614687838311479147575745482499475671081315621269676818289754600995862764796727441180845119870953940671578820610972884997013438733180284799239729683259069643367048263193381769004342273953109504373831198317547020876117398585778944607490021006682886073867739467893208470548795222670628790574678985690541213717189181716152699532361644335565134233585782589041208355612999472164747224066676833761323417911976869713912959127468316203539660406853926421641470316191011265853329124652810854645601150683750383234750441081349453261383126870007083151314012960317139623231095990920582289329487708968562519203493881657550378827778628650958406053126004930317327320394640525312881460076788527870624078219465430375229681519804305375083061287224842577128675083062849146896751309826217
    set p 4238909486862084964706018965345216945439486998442848604569404906867032171518819503624196222284829675053759767428084934489649871118143279102077040778463869962393112417385535476078079868293589149851032387358046696715903263546574174712640181481359718446594265502348384400386658554258649008499822085202651081013662947371740547648487017138104910917674732357725479085230655222355156753640512651428511923299366903007839164988692951958295119706447342157657375609942981582663458351898679836685453777144472005427780718637254973754641878702918249233604729248046641218036844395727113086337576272833864908420200073361307216204374472712336098177573361858057854863868433378343301615043672821886786496888478665997552886737978554819030666749224795289381560565474343296145163923097948091161091932449453099048912700545918652739501293855389400526678689526370024754188717040413001609060658567567741416138571550955968975951500318225535957770773441
    set q 68480971917075583872490110011849415490255850003090710488118600277904607329202
    
    set r [expr {($g**$k % $p) % $q}]

    Оно умрёт у вас там прямым способом (да и памяти сомневаюсь что хватит) ...


    Ответ кстати (используя modpow, ака fast modular exponentiation):


    set r [expr {[modpow $g $k $p] % $q}]
    \->
    54396351577338248274319882117724183171887577577494247423721537029425364252343

    И надеюсь, что от обратного, по полю конечных дискретных логарифмов то же не думали идти?...


    DSAшный не подберётся, там q минимум в 160 бит.

    Там ровно столько бит, сколько вы при генерации q(p) и подборе H (хеш функции) определите.
    Я вам про метод (процедуру) говорил, а не про "разрешение"…
    Если завтра DSS скажет что (3072/256) мало, то и минимальная и рекомендованная длины вырастут.


    И потом, кто вам сказал, что уменьшая r вы обязаны уменьшать k?
    По другому правда никак?
    Т.е. сгенерировать большее k, чтобы r (которое есть результат по модулю q) было короче, вы правда не можете?
    По модулю, Карл.
    Это остаток от деления, если что. Например, вот тут два больших числа становятся коротким в остатке:


       20060457451 mod 16256445 = 4321

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Я не знаю, откуда вы взяли это, но это неверно.

    Я это взял дословно из вашей википедии (раз уж вы все время на нее ссылались, типа "надо не RFC читать, а arXiv.org или хотя бы википедию.").


    Подписью является пара (r, s) ...

    А то есть вы теперь на DSA перепрыгнули… Ну ладно, давайте про DSA (хотя DSA — есть не самая лучшая производная эльджамаля...).


    Вы надеюсь понимаете что короткий "оттиск" подписи по модулю q, не приближает вас никак к отгадыванию x из секрета.
    Потому что x — то есть только часть ибо это экспонента в полном "закрытом" ключе (напрямую для y и опосредствованно для s).
    Еще раз, не нужно путать x с закрытым ключом.
    Которым оно де факто не является как можно было подумать, читая стандарт. А вся комбинация (x, p, q, h) ну или (x, p, q, g) в некоторых вариантах (просто g вычисляемо от h,p,q).
    То что при этом (p, q, g) и даже y известны/опубликованы, вам никак не поможет.
    Т.е. в реальности подбор этого "короткого" x, на "длинном" поле открытых значений p, q, g, есть настолько ресурсозатратная задача, что....


    А ладно, вам другой вопрос — вы когда нибудь ключи эльгамаля вообще генерировали?


    Раз у вас есть теперь cryptopp, попробуйте на досуге:


    AutoSeededRandomPool rng;
    ElGamalKeys::PrivateKey privKey;
    privKey.GenerateRandomWithKeySize(rng, 4096);

    Это минуты… для единственно ключа.


    И время практически не изменится, если у тех же DSA-ключей указать размерность q несколько короче, чем требует SHA1/SHA2.


    Чего вы там за 2-3 часа подобрать собирались?...


    Подбирать же k на поле r, p, q, g — это еще менее благодарное занятие.


    r должна быть известна верификатору.

    Я где-то обратное говорил?


    по ней нельзя восстановить k, необходимый для подписи

    Дак я не хотел… Это вы везде писали. Например, цитата:


    Под r остается 40 бит. k, соответственно, лежит в интервале [0;2^40]. Часа за два-три подберётся на 64 битном процессоре...

    Эльгамаль-ключ?!.. Даже DSA-шный…
    Подберётся?!.. Для p какой длинны?...

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    А если вы не знаете k, то вы не сможете сделать подпись на другой стороне. Вы же не возьметесь утверждать, что сможете его восстановить?

    Так о том и речь (почитайте ваш коммент выше), это вы же рассказывали про размерность k и собирались за 2-3 часа подобрать секретный ключ.


    Я думал вы просто опечатались, а вы не осилили даже википедию прочитать…

    Ничего я нигде не опечатался:


    Еще одним из преимуществ является возможность уменьшения длины подписи с помощью замены пары чисел (s,m) на пару чисел (s mod q, m mod q), где q является каким-то простым делителем числа (p−1). При этом сравнение для проверки подписи по модулю p нужно заменить на новое сравнение по модулю q: ( yA ⋅ rB) mod p = gC (mod q). Так сделано в американском стандарте DSS


    Это называется "ожидаем от оппонента хотя бы элементарных знаний дискретной математики".

    Вы правда не троль?

  • Многозадачность или марихуана?
    0
    Дык спокоен, аки бык…

    Это вы за меня не волнуйтесь так, — я его (выгорание) отпуском/выходными вполне себе успешно тушу (уже более двадцати лет как).
  • Che Burashka и взлом систем продажи билетов на московские электрички
    –1
    Под r остается 40 бит. k, соответственно, лежит в интервале [0;2^40].

    Ааа, ну говорю же "абсолютное непонимание базовых принципов".
    Вы формулу зависимости r от k посмотрите:
    r = gk mod p.
    Значение k вообще никак не зависит от длинны подписи, и лежит в диапазоне (1, p-1), ну и взаимно простое с p−1. Т.е. как бы зависит от части ключа, но не как не от подписи (даже прямой, молчу уже про вариант (s mod q, m mod q))...


    Мда… ваш "анализ" просто поражает.
    Это называется — Строим вокруг высказываний опонента воздушные замки, а потом "успешно" их разрушаем.

  • Che Burashka и взлом систем продажи билетов на московские электрички
    –1
    Тогда я вначале подберу этот секретный ключ

    Ну да, встретимся через сотню другую лет...


    Я не ослаблял, это вы ограничили её (подпись) 80 битами.

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


    Чем оно принципиально отличается от вашего y = x % 7?

    Тем, что во первых оно имеет обратное действие, если вам известен делитель.
    А во вторых, оно интереснее в случае, когда делитель вообще не важен (в том же эльгамале).


    Еще раз — этим оно же принципиально отличается от процесса шифрования/расшифровки.


    Я не ослаблял, это вы ограничили её (подпись) 80 битами.
    Часа за два-три подберётся на 64 битном процессоре, если не заниматься оптимизацией кода.

    Нет тут никакого ограничения, подпись просто передается в другом "разрешении", не влияющем на подбор секретного ключа (тот был бы еще нонсенс), но влияющим естественным образом на количество подписей на перебор (что здесь не важно, ибо это действие — для каждого билета и тупо нерентабельно).
    Кроме того, правильно построенный эльгамаль на проверке "переберет" вам за 2-3 часа несколько тысяч подписей (ну может десятков тысяч).


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

    Вам ключи от квартиры уже предлагал?...


    Для них я уже показал некорректность или непроработанность.

    Пока что вы показали абсолютное непонимание базовых принципов (как например подпись != шифрование), как и полное нежелание думать нестандартно, и неприятие любого отступления от написанного где-нибудь в учебнике/википедии.


    Счасливо оставатся.

  • Многозадачность или марихуана?
    –7
    • Ухудшает качество внимания

    Сижу в опенспейс-офисе, ищу багу в коде после большого мёржа, разговаривая одновременно с клиентом о новом релизе (при этом пытаясь отфильтровать коллег позади себя, базлающих по английски и по немецки почем зря), кроме того параллельно пытаясь закрыть issue в другом опенсорсном проекте (указав комментом человеку на место в конфиге, где он балбес у него неправильно), черкнув на бумажке напоминалку дать по рукам сотруднику, услышав краем уха, как он объяснял другому, что 2+2=5, перезапустив кнопкой "рестарт" один из CI-процессов (заметив что он вылетел на одном тесте со спорадической ошибкой), записав в туду пометку о том, что нужно будет обвязать этот тест мокапом…


    … И дописывая между всем прочим этот комментарий.


    • Быстрее утомляет

    Рабочий день начался в 8:00, а закончится как обычно ночью (хотя нет, сегодня низя — Валентинов день все-таки)...


    • Повышает уровень стресса и ухудшает настроение

    Стресс — это "нормальное" состояние инженера сегодня. И мультитаскинг к нему имеет очень посредственное отношение (как будто других факторов мало)…
    А, настроение — как настроение, нормально вроде...


    • Снижает эффективность обучения

    Возможно, но сомневаюсь (ибо учусь всю жизнь, инженеру без этого никак).


    • Приводит к принятию плохих решений в настоящем и будущем

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


    ЧЯДНТ.
    P.S. Мне вообще нравятся такие научные статьи типа "Британские ученые открыли"…
    Хотя вроде нет… Монреальский уни в Канаде, хмм...

  • Фундаментальная уязвимость HTML при встраивании скриптов
    0
    Символ / встречается не только внутри строк, но и в самом скрипте (операция деления)

    Ну да, ииии? Это-то вам зачем экранировать? Или вы операцию деления тоже от пользователя (чужого кода) прямым способом у себя "вставляете"?!


    Т.е. я вас правильно понимаю, что вы экранируете так (я утрирую дальше):


    <%
      MagicEncode(
        JS_doing_WebServiceCall(
          URL_Get(something),
          XML_Get(Params), etc
        )
      );
    %>

    Т.е. одно магическое маскирование для JS (наружу), XML (веб-сервис), URL (something, опять для WS), и т.д. Всё одним MagicEncode?


    Тогда у меня для вас плохая новость — это не камильфо, не правильно, закладывает множество скрытых мин (в долгосрочной перспективе). И вообще, так нельзя.

  • Функция random() у гуглобота работает абсолютно детерминированно
    0

    Да запросто, но думаю в этом случае оно сделает это c другим юзер-агентом, с другого-IP,… и наверное другим движком (в котором ранд работает случайным образом).


    Эта фича у гугла, чтобы в том числе хотя бы из js-движка не переиндексировать страницы, зависящие от случайных составляющих (ака "Случайная страница").
    Хотя правильный сервер может или но-робот проставить или оборачивать "случайную" динамику конструктами типа if (!bot) {...};.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    0
    Правда смотрится это довольно грязно

    Кстати, если уж хакиш-вэй так хочется embedded, то чем вот это вот не устраивает?


    <var data="surprise!</script><script>alert(&quot;whoops!&quot;)</script>">
    </var><script>
      var s = (function(){
        var s = document.currentScript;
        if (!s) {s = document.getElementsByTagName('script'); s = s[s.length-1];}
        return s.previousSibling.getAttribute('data');
      })();
      console.log(s);
    </script>

    Естественно обернув полифилом, нормальной функцией в АПИ и т.д.
    Оно не крадет ID, и работает вроде везде...

  • Фундаментальная уязвимость HTML при встраивании скриптов
    0
    Его для тега script просто не предусмотрено.

    см. ниже (просто попробуйте) ...


    Заглянул в древние исходники своего js_encode (для utf-8 на сях), прекрасно работает много лет...


    Скрытый текст
    while (l--) {
    switch ((c = (unsigned char)*p)) {
      case '\\': 
        buf = "\\\\";
        buflen = 2;
        goto lab_enc;
      case '\'': 
        buf = "\\'";
        buflen = 2;
        goto lab_enc;
      case '"': 
        buf = "\\\"";
        buflen = 2;
        goto lab_enc;
      case '\n': 
        buf = "\\n";
        buflen = 2;
        goto lab_enc;
      case '\r': 
        buf = "\\r";
        buflen = 2;
        goto lab_enc;
      case '<':
        // wrap <!-- to <\!--, wrap </ to <\/ :
        if (l && (*(p+1) == '!' || *(p+1) == '/')) {
          buf = "<\\";
          buflen = 2;
          goto lab_enc;
        }
      break;
      case '>': 
        // wrap --> to --\> :
        if (p-1 > st && *(p-1) == '-' && *(p-2) == '-') {
          buf = "\\>";
          buflen = 2;
          goto lab_enc;
        }
      break;
    }
    ...
  • Фундаментальная уязвимость HTML при встраивании скриптов
    0

    Да, для скрипт-тега, JS обертка должна, кроме всего прочего (кавычки и т.д.), еще и эскейпить /, т.е. всего лишь:


    <script> alert('<\/script>'); </script>
  • Фундаментальная уязвимость HTML при встраивании скриптов
    0
    И в результате у вас внутри строки Javascript будут именно &lt;, &gt; ...

    Прошу прощения, и правда попутал тут, — забыл про XHTML vs. CDATA (никогда не вставляю подобное прямо в скрипт).


    скрипт-тег все еще останется проблемой, даже если не забыть про правильный эскейп

    Попробую и я вам донести свою мысль — про правильный эскейп просто НЕЛЬЗЯ забывать, ни в коем случае.
    Просто, если внутри тега ожидается CDATA, то и эскейпить нужно для CDATA.
    Для HTML — HtmlEncode, для JS внутри HTML — HtmlJSEncode (например <a onclick="alert(<%=html-js= something(); %>)">)…
    И так далее.


    А лучше просто класть foreign-inlput в предназначеные для этого теги (типа input, textarea и т.д.), и/или вовсе отдельным майм-стримом (т.е. application/json).

  • Фундаментальная уязвимость HTML при встраивании скриптов
    +2
    Подзравляю, вы открыли, что пользоваться eval с внешними данными не очень хорошая идея.

    Жирный плюс!


    По теме статьи, было… стало ...

    Всё еще много проще — например было/стало:


    -<script>var x = <%= JSON.stringify(...) %>; </script>
    +<script>var x = <%=html= JSON.stringify(...) %>; </script>

    Т.е. html= это обёртка (функция, генератор, стрим), вызывающая htmlEncode, htmlEscape, и прочие подобные функции, делающие &lt;, &gt;, &quot;, &amp; и прочее, ещё никто не отменял.
    Если foreign-input, embedded и прочее вставляется в html-разметку, т.е. результат сперва разбирается html-парсером, до того как будет собственно "исполнен" тег скрипт, полифилы и прочее ничего с собственно html-стандартом не имееющее.


    И если забыть про правильный эскейп, то скрипт-тег будет далеко не единственной проблемой…
    XSS, XFS, и прочие радости можно словить даже тупо на "сломаной" encoding...


    К homm: это не имеет вообще ничего общего с "фундаментальной уязвимостью". Совсем.

  • Функция random() у гуглобота работает абсолютно детерминированно
    +3
    Я написал маленький скрипт, который использует этот баг для точной идентификации гуглобота

    На кой он это спрашивается делал, если гуглобот никогда и не скрывался, и по navigator.userAgent и кучей других разных способов однозначно определяется как бот.
    Точней уже некуда.


    И да, это не баг, это — фича...

  • Предсказание случайных чисел в умных контрактах Ethereum
    0
    может искать такое решение которое даст такой хеш блока

    Только если он может влиять на результат (что есть нонсенс, и исключено при правильно построенной схеме того же «коммит-раскрытия»).


    Например, если все "ходы + сиды" каждого "игрока" (включая майнера если он тоже играет) во первых подписаны заранее (до опубликования/раскрытия сидов), во вторых ему неизвестны (он знает только их подписи), то он при всём желании не сможет повлиять на результат, от слова никак. Даже взлом SHA1 над сообщением 50% мое / 50% чужое (майнер против конторы) НО с последующим подбором его нового сида под уже готовую (им же заранее сделанную подпись) связан просто с чудовищными затратами (и временными, и ресурсными).
    И если вообще реализуемо (в случае какого-нибудь доступного вектора атаки при ошибке проектирования), то как минимум затягивается (очень и очень надолго), т.е. вызывает подозрение у всех участников контракта. Т.е. кроме сомнительного результата, он еще и рискует доверием к нему как к честному майнеру.

  • Предсказание случайных чисел в умных контрактах Ethereum
    0
    Однако ECDSA нельзя использовать в Signidice, поскольку контора может манипулировать входными параметрами (в частности, параметром k) и так влиять на получающуюся в результате подпись.

    Можно её использовать… Всё дело в том, как именно...


    … эта подпись затем используется для генерации случайного числа.

    Если у вас есть еще один (второй) seed и энтропия его достаточно высока (пусть даже от urandom), даже простейшего миксина с этим вторым рандом НО уже после получения смарт-контракта от первой даже и "неблагонадежной" конторы будет достаточно, чтобы манипуляции этой конторы (не знающей заранее второй seed) не смогли оказать никакого предсказуемого влияния на конечный результат.


    Т. е. грубо алгоритм выглядит так:


    1. Игроком генерируется случайный Pseed, но не публикуется, а подписывается его приватным ключом, после чего эта подпись Ps(Pseed) вместе со ставкой вызывает смарт-контракт.
    2. ...
    3. … все как в схеме выше ...
    4. ...
    5. Игрок публикует свой Pseed, который:
      5.а. во первых, проверяется с помощью известного открытого ключа игрока и его ранее опубликованной подписью Ps(Pseed).
      5.б. во вторых "замешивается", например AES-упаковкой, с подписью полученной от смарт-контракта, в результате создавая реальное случайное число.
      5.в. подшивается к следующей транзакции (в качестве прува всей игры).

    Т.е. это вовсе НЕ от алгоритма подписи (ECDSA, RSA, etc) собственно зависит, а от способа передачи информации от всех участвующих сторон, в идеальном случае — неизвестной ни одной из сторон до конца (до конечного опубликования).


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

  • Теневой бан и с чем его едят
    0
    Невозможность поставить минус (выразить несогласие) — это недостаток любой системы голосования (см. например Парадокс Кондорсе).
    Это, к слову, одна из причин, почему некоторые люди не ходят на выборы (я не про Россию, ибо не живу там). В качестве примера про другую соседнюю страну, с мутти Меркель во главе — эта мадама никогда не «проправила» бы так долго (c 2005-го если что), если бы у людей была бы возможность кроме «Да», сказать и «Нет», ибо её ненавидят «обожают» поголовно ВСЕ избиратели других партий Германии.
    Так, что дизлайк — это очень нужное и правильное средство, и очень плохо если его нет.
  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Эльгамаль длиной 80 бит, кстати, требует всего 2^40 операций подбора, не 2^80.

    Вот откуда это берется. Нет, вы просто не поняли, эта зависимость от длины хэша сообщения M, т. е. в нашем случае т.к. плясать от хэша вы не можете (нужен секретный ключ), перебирать всё равно придется 280.


    Причем валидация подписи существенно сложнее, чем перебор, так как для перебора (для начала) нам необходимо восстановить k по известному r, не трогая никак s.

    Вы чего вообще?! Если вы не ослабили алгоритм вы "никогда" не сможете восстановить k по известному r.
    Это не допустимо ибо зная его, вы восстановите секрет.


    Т.е. трюк «проверяем секунду, зато подбираем вечность» — может быть неприменим.

    Хмм, не вижу пока логики почему нет.


    q тоже берется не с потолка, оно должно быть делителем p—1

    И что, если это например одноразовое действие.
    Случайное k вот вообще взаимно простое с p − 1, только оно на каждой итерации берётся.


    Вам всё же может стоить подтянуть мат-часть?...


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

    То был пример, и это вовсе не то же самое. Ваше "отрезание" действие невосстановимое. Математически для него не существует обратной формулы привязки к алгоритму, чтобы проверить используя только паблик (т. е. работает только в случае симметрики, или в частном случае когда режем только нулевые биты).
    Во вторых, я же вам даже расписал как и куда оно.


    Еще раз, простейший вариант (со "сжатием"). Я не говорю хороший, но простой к пониманию.
    Берёте RSA 2048, подписываете используя длиннющую подпись, после этого жмём ее в 80 бит (любой функцией имеющую обратную), и заканчивая подписывание если результат-подпись 280 разворачивается обратно без потерь (неполный перебор на стадии подписания).
    Т.е. грубо, чтобы ускорить такой "перебор" в случае подписывания RSA (сделать проверку подписи много медленнее чем её создание), можно например изменить алгоритм вычисления секретной экспоненты (на стадии генерации ключей) и/или генерацию padding (более псевдослучайный вместо случайный).
    Еще раз, то снова был пример, и для того же эльгамаля он не нужен в таком виде, там все проще (это же самое достигается например правильным подбором q).

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0

    Я вам другой — не математический пример приведу:
    Если у вас подпись — это отпечаток пальца (FP),
    а ваша функция проверки подписи — это сканер FP в 75 dpi,
    то вам в принципе всё равно, в каком разрешении эта подпись до вас добралась в 75, в 300 или 1200 dpi.
    Тут главное, чтобы этот отпечаток только вы создать могли...

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Шифровать до или после бессмысленно

    Опять "шифрование" у вас влезло…
    Подпись и отличается тем, что для неё можно делать действия в принципе не разрешенные в шифровании (т. е. с потерей "точности", если хотите).


    Вы не забыли, что мы пытаемся уменьшить? Т.е. в случае эльджамаля это замена пары (s,m) на пару (s mod q, m mod q)… Ну так и оберните ее функцией/поверхностью.


    Сжимать её необратимо можно, но тогда проверяющей стороне потребуется выполнить проверку множества потенциальных подписей.

    Если пользоваться вашей терминологией "сжиматься" оно будет как раз на стадии подписи.
    Для проверки подписи (в отличии от шифрования) её совсем не обязательно "разжимать" (ну или в некоторых вариациях полностью однозначно "разжимать").


    (результат обращения многозначен)

    Т.е. вы правда не видите как его можно сделать однозначным?
    Если на стадии подписи, вы примените функцию туда и обратно, то ваша "не сжатая" подпись станет "однозначной".


    Простейший пример. Наша функция "сжатия" — осаток от деления на 7 (ака y = x mod 7) или для краткости:
    y = x % 7,
    обратная соответственно была бы
    х = y" * 7 + y,
    если бы для y" было бы верно
    y" = x / 7.


    Т.е. сжимая и 25, 46 или 46546546, вы получите y=4, но y" в разных случаях будет разный.


    Применительно к эльджамалю, вы правда не видите где y" нам либо просто не нужен, либо его можно сделать вычисляемым?


    • т.е. в случае ненужности y" имеем одну операцию (быстрый эльджамаль);
    • в случае вычисляемого y" имеем или дополнительную функцию или много операций (медленный или очень медленный эльджамаль соответственно).

    Кстати тут вам ответ на вопрос куда в том же ECIES симметрику девать. Просто у него в нормальном виде — это (медленное действие) было бы "одноразовым" (на сессию, например при коннекте), чтобы все остальное потом летало.
    Нам же оно на руку (мы как раз хотим медленно).

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0

    На питоне оно будет, как-то:


    from math import log
    def dist_back(x):
      x = x+100
      return (1e+6/x**1.2)**log(x) - 37897683942850464
    
    >>> dist_back(0)
    0.0
    >>> dist_back(199)
    1.4734998082487939e+17

    Ну а "x % 200" это было вместо ассёрта (или если вдруг зависит от третьей координаты "z") ...

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0
    Покажите, пожалуйста, куда конкретно смотреть.

    У меня вроде даже подобное валялось где-то. Если найду на досуге, скину...


    Это же не функция на множестве действительных чисел, у нас дискретный случай.

    Чего это, вдруг? Вот это вот конкретно была (1e6/x^1.2)^ln(x), но может быть любая другая, хоть тангенсами обернутая… ну и плюс смещения/модуляция.


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

    Вы чего право слово:


    proc tcl::mathfunc::dist_back {x} {
      set x [expr {$x % 200 + 100}]
      expr {(1e+6/$x**1.2)**log($x) - 37897683942850464}
    };
    
    puts [format "%.0f..%.0f" \
      [expr {dist_back(0)}] [expr {dist_back(199)}]]
    
    0..147349980824879390
    
    puts [format "%.0f..%.0f" \
      [expr dist_back(1)] [expr dist_back(198)]]
    
    1051778453779040..147264069284830140

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


    Это вот распределяет обратно [0..199] в [0..147349980824879390], т. е. применительно к эльджамалу (r',s') -> (r,s").


    Добавив туда параметр z, вы сделаете её трехмерной (поверхностью), позволяя цеплятся за другие параметры/данные из подписи (r).


    Как это переделать на 280 -> 2много надеюсь не нужно объяснять?

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0

    Вы неисправимы...


    Мне нравится ваш переход к математике. Давайте

    Иии… вам же выше написано как оно у эльгамала будет, ну а где симметрика очень хорошо описано у тех же ECIES (только смотрите подпись, НЕ шифрование). Или просто гляньте в реализацию любого миксапа микейев. А если вернуться к графику, то шифрование "втыкается" на поверхности образующую эту кривую (т.е. кривая не одна) либо как у некоторых других алгоритмов определяет дискретный угол наклона кривой.
    Т.е. у тех же ECIES:
    kE ‖ kM = KDF(S ‖ S1)
    Однако, чтобы усилить действие многократного "повтора" симметрики, нужно видоизменять не столько производные k, сколько часть от "предыдущей" итерации по полю для гамаловского gC (mod q).


    Про график. Если его нарисовать не в логарифмическом масштабе, ...

    С чего вы это взяли-то, он — как раз линейный. Ну если плохо видно, то вот вам другой пример:

    Вы не забывайте, что вы контролируете процесс подписи, т.е. пределы (min/max) могут быть строго определены в реализации алгоритме (параметрах).
    Т.е. распределение тут — более менее равномерное.
    А то, что вы назвали коллизиями — есть просто функция дискретного пере-распределения по X.
    Я думал то, что с уменьшением размера подписи, такая "дискретность" растёт — это очевидное следствие. Но по другому никак, да и не критично оно здесь.


    ведь тогда он перестанет быть симметричным.

    Симметричный он не потому что одно и тоже действие (они как раз и обратные бывают), а потому, что один и тот-же ключ.
    Дальше думаю понятно.


    Хотя, что вы привязались к симметрике, — то был просто ОДИН из возможных примеров из обсуждения выше.
    Т.е. как привязать аппроксимацию подобной функции к уравнениям того же эльгамала (совсем без симметрики) вам не стало понятней?
    Вы же знаете, правда, что симметричные алгоритмы (как правило) быстрее асимметричных...


    Давайте еще раз резюмируем:


    • т.е. то, что подпись можно сделать короче без уменьшения пары ключей, это думаю вам теперь понятно?
    • то, что подобрать приватный ключ, нужный для подписания, действие близкое к невозможному, думаю тоже понятно;
    • то, что единственная возможность подписания (без ECpriv) это брут с проверкой результата используя ECpub?

    Что же нужно/можно сделать чтобы замедлить такую брут-"атаку"?
    Посмотрите на формулу проверки подписи… и представьте, что подписывать билет используя ECpriv и проверять используя ECpub, будут только один раз.


    Однако брутить его будут многократно… Нужно ли вообще что-то делать, если в принципе можно увеличить priv/pub и H, при этом уменьшив подпись.
    А если все же делать (оставив размеры priv/pub и H на максимально допустимом железом/софтом уровне), то куда можно воткнуть "сложную", ресурсоёмкую математику, чтобы заменив (s,m) на (s mod q, m mod q) многократная проверка подписи замедлилась в разы (ударение на проверка). При этом подпись (r,s) уменьшилась бы в размерах.
    И конечно не забывайте, что у эльгамала зная k секретный ключ может быть "легко" вычислен, как то x = ( m − k s ) r−1 mod (p−1), т.е. и в дальнейшем затрудняя (или по крайней мере не ослабляя) "вычисление" k, при этом "зная" s mod q и m mod q.

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0

    Чтобы уже и правда закрыть эту "конструктивную" дискуссию, вот что например написано в вашей любимой википедии про тот же ElGamal:


    Еще одним из преимуществ является возможность уменьшения длины подписи с помощью замены пары чисел (s,m) на пару чисел (s mod q, m mod q), где q является каким-то простым делителем числа (p−1). При этом сравнение для проверки подписи по модулю p нужно заменить на новое сравнение по модулю q: (yA ⋅ r B) mod p = gC (mod q). Так сделано в американском стандарте DSS (Digital Signature Standard).

    Т.е. насчет вашего "Криптографы всей планеты пытаются ...", это мимо. Ибо уже давным давно есть (как минимум для конкретных прикладных задач).
    Мешать же в одну кучу HTTPS, подписи договоров и т.д. право не стоит, ибо разное оно.


    И чтобы два раза не ходить:


    Шифрование по схеме Эль-Гамаля не следует путать с алгоритмом цифровой подписи по схеме Эль-Гамаля.

    А вы это, к слову, делаете постоянно.


    Во вторых, чтобы как-то "математически" показать мою позицию про "их (способов) на самом деле несколько", я вам попытаюсь объяснить это на простом графике какой-нибудь функции, например:

    Не знаю ваш уровень вышки, поэтому попробую простыми словами.
    Вы наверно наблюдаете тут огромную разницу между осями x и y (например 74.2222, 1,48*109).
    Теперь просто представьте, что если хеширование билета "привязано" к оси y, а подпись "привязать" к оси x, то в случае вычисления проекций, ключи (priv/pub) могут быть любого размера, как собственно и хеш билета, при этом подпись останется короткой.
    Т.е. в случае 280 по оси x, при правильном подборе функции и интервала/смещения (например для верхнего графика x где-то между [40,120]), все остальное может быть выбрано гораздо длиннее вплоть до 24096.
    Единственное, что нужно обеспечить в этом случае — достаточно медленный перебор короткой подписи, через проверку от pub-ключа.
    Естественно при обеспечении прочих условий надежности собственно алгоритма (не зависящих от длинны подписи).


    Ну и третий момент, на самом деле еще тривиальней — отбросьте все функции, графики и т.д.


    Просто сравните 2-а числа:


    37778931862957161709568
    1427247692705959881058285969449495136382746624

    Одно длиннее — это очевидно (одно 275, другое 2150). Но если они результат вычисления от некоторых случайных величин, то уже не понятно, каково действительное "разрешение" т.е. длинна оных.
    Т.е. если даже просто долго, многократно подписывать билет "обыкновенным" алгоритмом (с рандомномной составляющей), создающим подпись длинной в 1024-бит, то когда-нибудь вы получите что-нибудь умещающееся в 80-бит.
    А если этому как-то помочь алгоритмически (ведь он же известен)...


    Т.е. в результате всё опять в итоге просто упирается в усиление предотвращения брута на подпись на поле известной пары (билет/pub) и какого-либо "random" padding.


    Прошу прощения, если местами был немного резок.
    Просто вы много выше написали что вы "в теме", а мне пришлось многократно разжевывать элементарные по сути вещи.

  • Che Burashka и взлом систем продажи билетов на московские электрички
    0

    ну да, а я ещё не слышал про взломаный эльгамаль, и что это по вашему "мой" способ к бесконечности приближает?..
    И не мешайте пожалуйста мухи с котлетами — когда я вам писал про спу-лет, речь шла про скорость Брута по публичному ключу на поток на подбор подписи. Я закончил с вами.