211 entries in 0.775s
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
bvt: now, sse could theoretically help, but there is a question of whether sse operations are
constant time (in each generation of intel cpus)
BingoBoingo: The
constant time bignum work helps to inform the crypto work
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
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)
bvt: myeah, complexity does not go too well with both
constant-
time and fits-in-head.
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 )
mircea_popescu: Turns out, Kochs 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 Barretts Reduction." << check him out.
mircea_popescu: asciilifeform
constant time is a d) in that scheme. though i guess c-d may well package.
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.
diana_coman: if we aimed indeed for
constant time, then sure, definitely worth the change but that's not the case
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.
☟︎ Mocky: they live in
constant misery, mostly leaving after a short
time 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.
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.
Mocky: it's not
constant time without asm?
mircea_popescu: zx2c4 is this
constant time ecc implementation on display somewhere btw ? i don't think i ever saw one before.
zx2c4: the ecc is
constant time. but anyway the transport layer doesnt use any ecc
zx2c4: asciilifeform: i haven't been able to observe any non-
constant time multiplications on intel in that code
zx2c4: by only using a limited subset of constructs which are known to be
constant time zx2c4: also,
constant time mircea_popescu: this is a source of
constant surprise, consider all the
time phf sunk into chasing unicode obscura on his logger.
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