mircea_popescu: if the convention can be "you'll need a serial capable machine", as it HAS to can be, then convention can also be "you'll need a cpu with ror/rol implemnented". whether it is decided to make it so has no bearing on whether it could be decided to make it so. that's a 1 : it could be.

mircea_popescu: to put the point on its proper footing : convention is convention, no different than any other convention. convention doth not become physical law through wide adoption, irrespective how extensive that wideness, in headcount, time, whatever.

mircea_popescu: "doesn't go away just because intel stops including it" to ~same degree.

mircea_popescu: "my personal fg is plugged into serial port and my personal ada keccak is plugged into iron on which asm works". da fuck special pleading is this.

mircea_popescu: asciilifeform how do you think anyh of that is relevant ?

mircea_popescu: http://btcbase.org/log/2017-11-16#1739542 << this is particularily hysterical given the http://btcbase.org/log-search?q=pl2303x lulz. ☝︎

mircea_popescu: afaik lisp never actually avoided this either.

mircea_popescu: tbh, this item aside (it was just given as an ~example~ anyway), i do not expect that on the medium term we will be able to avoid "and here's the special asm library, links at link time with the rest of compiled shit" situations. ☟︎

mircea_popescu: "rotation can be directly an opcode item linked as such", how about that.

mircea_popescu: maybe i didn't make the inline incantation sufficiently magical, but anyway. "straight asm", what'd you prefer.

mircea_popescu: i suppose ye age olde "i didn't know there was interest" at play.

mircea_popescu: "oh but mp, other people do it via shortwave radio" "good for them."

mircea_popescu: but reference also has no business baking in whatever quirks of "human rights & the fyotoor", known & unknown.

mircea_popescu: hey, minigame produced reference implementation of ada keccak can well contain inline asm rotation, and who dun like it can do whatever they will. ☟︎

mircea_popescu: http://btcbase.org/log/2017-11-16#1739520 << we can afford to inline asm, seeing how minigame knows what iron it runs it on. ☝︎

mircea_popescu: got 3-4k together so far. but they do seem vaguely promising, maybe.

mircea_popescu: it's like penis cage for the brain, somehow.

mircea_popescu: how the fuck.

mircea_popescu: exactly in the vein above. "understands how to add, thinks 4>5."

mircea_popescu: not discussing that part.

mircea_popescu: but the attempt is evident.

mircea_popescu: not entirely clear yet if he just AIMED to avoid all secret bit branching or actulaly managed.

mircea_popescu: asciilifeform incidentally, bernstein's curve implementation is ALSO free of branching on secret bits, have you seen that thing ?

mircea_popescu: the importance of a phuctor style primorial+commonkeyset gcding away is somehow easily overlooked by academic minds. but in practical terms it is the first line, degree (or even two!) ahead of haskelism a la gnfs

mircea_popescu: or consider something as simple as phuctor, that already has a lot of "special" primes, however you define special (small, common, whatevewr)

mircea_popescu: other lulz, same source : https://blog.josefsson.org/2017/08/03/vikings-d16-server-first-impressions/ (apparently there's an entire kanzure 's wanker club dedicated to republican hosting ; vikings.net and whatnot. doesn't seem to be actually working though, but i did join their irc, see what happens.

mircea_popescu: cultivated enough to mention bernstein&gf curve, uncomprehending enough to "post quantum algorithms". how do these happen, i wish to know. ☟︎

mircea_popescu: so logically if indeed the larger upper bound was deemed useful we'd move the standard to 8192 bits N with 4096 bit p/q rather than do this.

mircea_popescu: it may appear beneficial to instead produce larger sets, such as of 4096 bits. the UPPER BOUND of the gain from this process is known ; the lower bound of losses from it is not known, because yes if you allow 4096 bit p, q and test, an acceptable N can be composed of the product between 17 and 2^4092 - 177 or whatever it was.

mircea_popescu: this whole thing aside, the only objection to http://btcbase.org/log/2017-11-16#1739433 ie, "produce sets of 2048 bits, check them for primality, if they're prime multiply them and if the product is a suitable N keep them else start over" was http://btcbase.org/log/2017-11-14#1737682 ☝︎☝︎

mircea_popescu: as far as anyone knows, something closer to 450 bits is what's actually needed.

mircea_popescu: yes, in about 6% of cases the N will come out as 111..., in which case you know that both p and q are actually 1111 1111 led, ie you'll have 2 bits of each. and in 0.001% of cases N will led by FF and have the next bit set, so you'll know both p and q have the first octet set. if you have an extension attack allowing you to parlay 8 leading bits into the prime exposure, you can thereby crack rsa in 0.001% of cases.

mircea_popescu: ie, "you have the following information about any and all factors : they're 11 led, 1 terminated, 2045 true random bits. knock yourself out."

mircea_popescu: there's no argument that informations about range of factors CAN be used. the point is minorily that a) a range of 2045 bits is sufficient and majorily that b) should this range NOT be sufficient, the correct response is to extend IT, rather than to introduce key-substitute mechanisms in the actual encryption scheme.

mircea_popescu: factors that are very small are trivially a vulnerability, as the 17 example shows. what is "small enough" is somewhat of an open question, but 512 BITS does conceiovably qualify.

mircea_popescu: http://btcbase.org/log/2017-11-16#1739432 << factors differing by only a few bits in length aren't particularily unsafe, which is why the original alt-rsa spec involved them (see eg http://btcbase.org/log/2017-08-14#1697613 and the eventual end of that discussion.) ☝︎☝︎