211 entries in 0.741s

mp_en_viaje: sounds easy enough at the entrance gate ; but once inside it becomes obvious that where can't live, can't live. my constant "either help me build something, help the idiots be idiots, or be sad in a corner -- there's no other option" is, similarily, insistently perceived as so much empty bravado at the gate. but, in reality, as time goes by...

ossabot: Logged on 2019-10-13 06:42:11 mp_en_viaje: in other lulz, i suspect about half of the ru ip space is "soft" banned in germany, constant "inexplciable" service interruptions etc. can't eg load archive.is most of the time, and so on

mp_en_viaje: in other lulz, i suspect about half of the ru ip space is "soft" banned in germany, constant "inexplciable" service interruptions etc. can't eg load archive.is most of the time, and so on

asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-09#1926712 << it is entirely possible to have sane ~back end~ on which you, e.g., write in a lisp-flavoured skin when mangling trees, and a fortran-flavoured skin when want to run in constant space/time with fine control of flow; the bolix people -- had. in fact, arguably all machines have (presently piss-poor) incarnation of this concept, it is... the machine arch itself.

asciilifeform: ftr asciilifeform is sewing a constant-time keccak so that peh can rsa in battlefield. is someone gonna do this in my place, so i can write www log ??

asciilifeform: ( on pc, in addition to 'unix leaky' and other boobytraps, also gotta contend with not knowing what the fuck the cpu does internally in re constant-time )

bvt: now, sse could theoretically help, but there is a question of whether sse operations are constant time (in each generation of intel cpus)

asciilifeform: OriansJ: lotsa folx over the years landed in the logs, and thought 'these people sit and philosophize and what'. but plenty of examples of working mechanism , if yer interested to study. http://www.loper-os.org/?cat=49 for instance is a just-short-of-done constant-time 0-dependency cryptoarithmetizer.

asciilifeform: ( the latter not used for any of the published tests, but to simply gauge the effect of 'modern' x86isms . fwiw does have constant-time mul etc )

asciilifeform: ( in fact ada per se has a fascism knob that, if set, prevents early return from subroutines . i have not thus far used, cuz in ffa per se this is already the case, nuffin gets to terminate early when 'constant time' algo )

asciilifeform: the knobs still on conveyor are -- subroutines; hash ; constant-time table lookups. that's it.

asciilifeform: 'but asciilifeform , if you want lobster, you gotta build a $9000b fishing fleet' 'mno, here's 1 from your own dryer lint trap, and it can bend xrays and modexp in constant time, naowat'

asciilifeform: in re single-shot gcd, you either ~look at the bits~ , and that's lehmer's (not constant-time-able) method, or you do not, and that's stein's or the division-powered one, and i suspect it can be proven that yer stuck with quadratic runtime if you dun look at the bits.

asciilifeform: bvt: from surface look, loox like lulzy piece, e.g. 'The algorithm is not constant-time as shown but can be made constant-time with low overhead'

bvt: asciilifeform: https://gcd.cr.yp.to/papers.html -- rather new constant time gcd from djb. i did not look at it closely so can't say if it's anything good or belong to the kunstkammer

asciilifeform: bvt: the only new instrs that seem to be even theoretically of use, are 'mulx' and 'adcx' -- but i dun have any iron that supports these atm, and cannot even begin to say whether constant time etc

asciilifeform: mircea_popescu: this is why i like 'run 9000 shots, and discard outliers' (granted this only applies when the item is expected to go in constant time, goes without saying)

asciilifeform: BingoBoingo: in http://qntra.net/2019/01/constant-time-miller-rabin-test-added-to-finite-field-arithmetic/ , plox s/informating/informing

asciilifeform: in other lullies, https://duckduckgo.com/?q=miller+rabin+constant+time << seems like we're the only folx who ever showed detectable symptom of giving a shit..

feedbot: http://qntra.net/2019/01/constant-time-miller-rabin-test-added-to-finite-field-arithmetic/ << Qntra -- Constant Time Miller-Rabin Test Added To Finite Field Arithmetic

a111: Logged on 2019-01-09 00:19 asciilifeform: in other noose, constant-time stein-gcd aint so bad, 1msec (2048bit operands) , 6msec (4096bit) , 21msec (8192bit), 81msec (16384bit)

asciilifeform: ( this is not a contradiction in terms, it is possible to implement whole thing, with same constant-time algos, by hand asm )

asciilifeform: i prolly oughta add to the http://btcbase.org/log/2019-01-20#1888508 thing : 1 of the items which seemed like a speedup, but in actual practice sucked, was the use of (constant-time) 2 (ditto 4) -bit windows for modexp ( iirc apeloyee suggested ) ☝︎

asciilifeform: ( the 64x64 iron multer in amd/intel, possibly surprisingly, is in fact constant time, in all boxes i've tested to date )

asciilifeform: mircea_popescu: it is conceivable that the ones currently sold are constant time , i simply haven't tried'em.

asciilifeform: this allows 'P' to be a constant-spacetime operation, and hands the decision of 'just how important to constant-time the whole prime generation' to the author of the tape.

asciilifeform: which means ugh, for e.g. 2048bit candidate being tested for primality in constant time, ~each~ witness needs 1 modexp and 2047 modsquares !

asciilifeform: http://p.bvulpes.com/pastes/TkmoM/?raw=true << sneak peek of constant-time stein. ( afaik there isn't one anywhere else on the net, funnily enuff. )

asciilifeform: if primality test ( which consists of GCD ~and~ m-r, in order to constant-time ) does not exceed 0.0356sec, then on machine with 1 FG it can be considered that the FG is the limiting reactant.

asciilifeform: in other noose, constant-time stein-gcd aint so bad, 1msec (2048bit operands) , 6msec (4096bit) , 21msec (8192bit), 81msec (16384bit) ☟︎

asciilifeform: it is interesting to note, i did an exhaustive dig re gcd algos; and found that there are half a dozen sub-quadratic ones, but none of those can be made constant-time.

asciilifeform: otherwise can wait for asciilifeform's constant-time m-r ( or not, depending on what's in eulora war room chalkboard, i cannot presume to know what the priority is )

mircea_popescu: http://ossasepia.com/2018/03/01/eucrypt-chapter-12-wrapper-c-ada-for-rsa-oaep/#selection-133.1-133.132 << right, and you want to use ~constant time~ keccak

asciilifeform: ( in orig timeline also did not include problem of constant-time keccak, which i presently do not have, and neither anyone else, but is necessary to fill mircea_popescu's spec for the final product )

asciilifeform: i've actually found decent (not constant time, but didn't need, it only checked sigs) rsatrons in malware samples -- kB or so of asm. it aint exactly mystery, how to bake

asciilifeform: mircea_popescu: i didnt try patching out the test ( given as it's got montgomery, the answer will be soup ) but did try for odd exp, got ~same~ as for the nonconstanttime gmp knob ( which is pretty hilarious, means that they dun do anything differently for 'constant time' variant, evidently )

a111: Logged on 2018-10-12 13:52 asciilifeform: ( bonus is that the closed form is not only constant time, but substantially faster on pc, nomoar branch prediction misses )

feedbot: http://qntra.net/2018/12/stanislav-datskovskiy-publishes-fully-constant-time-code-for-barretts-modular-reduction-as-part-of-ffa-library/ << Qntra -- Stanislav Datskovskiy Publishes Fully Constant Time Code For Barrett's Modular Reduction As Part Of FFA Library

mircea_popescu: Turns out, Koch’s pile of shit, despite eschewing constant time arithmetic, and being implemented in Overflowandcrashlang… loses the footrace, when given a full-width modular exponentiation (i.e. one where it cannot cheat by skipping over leading zeroes.)

mircea_popescu: "As far as I know, the proof in this article is the only public one which completely treats a constant-time implementation of Barrett’s Reduction." << check him out.

asciilifeform: http://btcbase.org/log/2018-12-18#1881465 << will add to this : on any hypothetical iron where add and sub aint constant-time ( i know of none , but could hypothetically exist in fyooyoor ) the overall 'is modexp constant-time' litmus will ring alarm. ☝︎

asciilifeform: at 1 time, was used in the constant entry ( nibble inserter ) routine, then the latter was replaced with rewritten http://www.loper-os.org/pub/ffa/hypertext/ch13/fz_io__adb.htm#29_14 , nao sole remaining use is in the knuth divider.

asciilifeform: ( the only guarantee i can offer in good conscience is that nuffin can be broken by operating the ~external~ controls -- but even there user is required to see whether his cpu has barrel shifter (see ch13 discussion) , constant-time mul ( see ch9 discussion ) )

mircea_popescu: asciilifeform constant time is a d) in that scheme. though i guess c-d may well package.

asciilifeform realized that he's gonna need a constant-time keccak for the final chapters, dun have 1 yet

asciilifeform: the other is that on iron such as certain ARM ( i have not yet investigated ~which~ ) , and ppc, and certain others, there does not even exist a constant-time MUL, and one is stuck with some variant of http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#33_13 -- which really begs to be asmed, is riotously inefficient

a111: Logged on 2018-11-01 20:48 mircea_popescu: asciilifeform speaking of "taking suggestions" : suppose you bake me a proper drop-in gpg replacement. in ada, constant time, does FG-aware keygen, signing, verification, and encryption/decription. 100% rsa, none of the "cipher" bs as per current.

asciilifeform: diana_coman: unlike, e.g., haskellists, we only do things if they make sense : as you pointed out, 'bit-vectorized' keccak aint constant time, no matter what, so no particular reason to bother with the massage

diana_coman: if we aimed indeed for constant time, then sure, definitely worth the change but that's not the case

asciilifeform: ( if, btw, somebody else has the time/inclination to do the latter, i'll only say 'thx'. thing is already in xor-sat form, roll the constant term into the eqn's, set $known-schedule as the output values, and gaussian-reduce... )

mircea_popescu: asciilifeform speaking of "taking suggestions" : suppose you bake me a proper drop-in gpg replacement. in ada, constant time, does FG-aware keygen, signing, verification, and encryption/decription. 100% rsa, none of the "cipher" bs as per current. ☟︎

diana_coman: http://btcbase.org/log/2018-10-26#1866278 -> ~every time I used String for anything more than constant value I regretted it somewhere down the line so I tend to converge on the same idea - it's just broken ☝︎

ave1: diana_coman, I now have a good version of the crc32 bitwise constant time algo, but I ran out of time for today, so eta probably tomorrow.

a111: Logged on 2018-10-12 13:52 asciilifeform: ( bonus is that the closed form is not only constant time, but substantially faster on pc, nomoar branch prediction misses )

a111: Logged on 2018-10-12 12:49 asciilifeform: http://btcbase.org/log/2018-10-12#1860789 << imho a ~constant time~ crc32 would be useful, and can be made from ave1's with very small effort, but i'ma leave it as exercise for him ( simply dispose of the if's )

mircea_popescu: have your own program designed correctly, so your own shitropy management thread ensures your own shitropy calls always return in constant time. YOUR JOB, as a shitropy eater.

a111: Logged on 2018-10-12 12:39 asciilifeform: http://btcbase.org/log/2018-10-12#1860778 << there are not so many legitimate uses for /dev/urandom. however the idea that it can be fully reproduced in userland without kernel knob is afaik a mistake -- the thing gives you real entropy if available, and elsewise prngolade; importantly, as a ~nonblocking~ operation. idea is that it ~always~ returns in constant time.

asciilifeform: ( bonus is that the closed form is not only constant time, but substantially faster on pc, nomoar branch prediction misses ) ☟︎☟︎

ave1: and for the table lookup, it's the the table access part that's not constant time? (lookup(0) might take different time than loop(255))?

ave1: the div variant could be made to be constant time using the ffa primitives but currently is not.

asciilifeform: http://btcbase.org/log/2018-10-12#1860789 << imho a ~constant time~ crc32 would be useful, and can be made from ave1's with very small effort, but i'ma leave it as exercise for him ( simply dispose of the if's ) ☝︎☟︎

asciilifeform: http://btcbase.org/log/2018-10-12#1860778 << there are not so many legitimate uses for /dev/urandom. however the idea that it can be fully reproduced in userland without kernel knob is afaik a mistake -- the thing gives you real entropy if available, and elsewise prngolade; importantly, as a ~nonblocking~ operation. idea is that it ~always~ returns in constant time. ☝︎☟︎

asciilifeform: i find it hilarious how they carry on pretending that a crypto lib where ~some~ of the functions are (supposedly..) constant-time, is worth half a shit

asciilifeform: 'BN_gcd gets called to check that _e_ and _p-1_ are relatively prime. This function is not constant time, and leaks critical GCD state leading to information on _p_.' and a few moar.

asciilifeform: in other lullies, https://eprint.iacr.org/2018/367 >> 'Most of OpenSSL's constant-time code paths are driven by cryptosystem implementations enabling a dedicated flag at runtime. This process is perilous, with several examples emerging in the past few years of the flag either not being set or software defects directly mishandling the flag...' 'granularity issues due to word-size operands to the GCD function' etc

zx2c4: mircea_popescu: asciilifeform: http://btcbase.org/log/2018-04-12#1797528 http://btcbase.org/log/2018-04-12#1797506 -- in case you're interested in the ecc stuff more, the formally verified fiat and hacl implementations are not the only ones we have. we also have constant time accelerated x86 adx and bmi2 implementations https://git.zx2c4.com/WireGuard/tree/src/crypto/curve25519-x86_64.h and also constant time accelerated arm neon implementations ☝︎☝︎

mircea_popescu: zx2c4 is this constant time ecc implementation on display somewhere btw ? i don't think i ever saw one before.

asciilifeform: i'm curious, for instance, whether any of the cryptographers observed that the arithmetical routines behind your ecc are not in fact constant time on e.g. arm.

asciilifeform: zx2c4: i've spent the past ~2yrs writing a properly constant-time arithmetic lib. it is being slowly published. ( see earlier link to my www )

zx2c4: asciilifeform: i haven't been able to observe any non-constant time multiplications on intel in that code

asciilifeform: btw zx2c4 , i must regret to inform you that the code you linked, is in fact NOT constant-time on several common architectures, because it makes use of machine MUL instruction ( gcc will compile a nonconstant-operanded '*' to e.g. IMUL on x86 )

mircea_popescu: this is a source of constant surprise, consider all the time phf sunk into chasing unicode obscura on his logger.

asciilifeform: in other quasi-noose, if n is p*q, and 4p-1 = d*b^2, where b is integer and d is in {3,11,19,43,67,163}, n is factorable in polynomial time (with modest constant!)

asciilifeform: phf: phunphakt : ppc is one of the two currently-produced archs ( the other being arm ) that doesn't have constant-time MUL .

asciilifeform: (i.e. you don't need a universal shift register, can make 'constant' value using a just-in-time-cooked bitstream loaded in for that particular occasion)

asciilifeform: somehow the 'i dug up an algo, by apparently sane author, and determined that it runs in constant time' -- not work ?

asciilifeform: mircea_popescu: all blockciphers are pseudoscientific. the only differences you can take to the bank, is that camellia was approved by nato bureaucrats, serpent was not; and the fact that serpent runs in constant time ( branch-free ).

asciilifeform: this is why ultimately entire primality test algo must be constant time, just like the other pieces.

mircea_popescu: you're not having any of this new fangled "constant time ~= fixedtime ie, variable time running at worst case" ?

phf: mircea_popescu: well he either has a constant time algorithm in ffa, in which case if the goal is to compare speed specifically we should be comparing fixtime ffa and fixtime something else. otherwise he has a variable time algorithm running at worst case constant time, in which case the comparison is between base operation speed, which is still going to come out on top