log☇︎
65400+ entries in 0.041s
asciilifeform: http://p.bvulpes.com/pastes/oFd2X/?raw=true << full text of the pdfturd, for the l0gz.
asciilifeform: evidently sumbody passed it off to |\n as an 0day
asciilifeform: nah, it's part of a 'if you could patch microcode, here's how you might trigger the bomb' stage magic demo.
mircea_popescu: so basically this is a bug in asm.js ?
asciilifeform: 'As explained in Section 7.2, we use ASM.JS code in Firefox 50 to trigger the implemented x86 div Trojan. It is shown in Listing 9.'
asciilifeform: rather than a wild thing.
asciilifeform: mircea_popescu: yes i recall very well. this one is genuine, tho, but one half of a rigged academi-demo, requires ~their~ microcode patch
asciilifeform: ( flip to last pg )
mircea_popescu: asciilifeform no, don't you remember this thing ? some dood went off deep end, that there's a cvasi-magical virus in his usb stick. cca 2015 vintage logs ☟︎
asciilifeform: eh |\n it's a duck : apparent source is https://ecc2017.coreboot.org/uploads/talk/presentation/38/Microcode.pdf talk , and demands a pre-diddled, per the recipe, old amd k8/k10
mircea_popescu: Firefox 50.0 32-bit on Linux << should be easy enough to test
mircea_popescu: is this more of that romanian fellow's "magical usb stick aliens" ?
asciilifeform: |\n: where'dja come across this, and for what chip is it alleged to work ?
|\n: not to mention that amount of such holes, of course if that works, is immense
asciilifeform: mircea_popescu: linked item alleges that if one divides 0xa1a2a3a4 by 0xb1b2b3b4 on x86, triggers magic nsa hole.
asciilifeform: hang straight off the yardarm of dirigible, wainot
mircea_popescu: |\n suppose you start by introducing yourself and showing the minimum awareness of republican process of using sane fucking pastebins.
mircea_popescu: i'd rather hang the moron flattering himself with "enemy" that tried to lose me a disk than either of these.
|\n: hello, was wondering if you've heard anything about this in particular https://webcache.googleusercontent.com/search?q=cache:https://github.com/RUB-SysSec/Microcode/blob/master/ff_div/fx_payload_exec_linux32_fx_50.0_set_eip.html
asciilifeform: mircea_popescu: i view block ciphertrons as a 'slightly better than nuffin' kind of tech -- would slightly rather lose a serpented disk to enemy than naked one; but that's about it
mircea_popescu: i don't even think there's anything wrong whatsoever with studying the damned thing. my reservations were strictly around investing any kind of "this is te republic's encryptodisk" flag on it\
mircea_popescu: i certainly see the point re "explore the space" ; and yes a serpent implemented as both eulora workhorse and verilog is better studied than just former.
asciilifeform: mod6: that, + tall pile of saecular rubbish
asciilifeform: mod6: goin' back to my very full ada plate
a111: Logged on 2018-10-26 16:08 asciilifeform: mircea_popescu: in re these lulz, at one point asciilifeform dug for 'anybody ever verilog-ified serpent?' and found a stack of 'papers'. any src ? mno. but plenty of 'discussion' of supposed 'implementation', in the traditional nadia henninger style .
asciilifeform: but funnily enuff, just from this 2hr lulz we already know moar than from my combined stash of http://btcbase.org/log/2018-10-26#1866343 pointlessly-murdered trees... ☝︎
asciilifeform: mircea_popescu: grr, typo, ~65~ not 25
mod6: hanbot: That's awesome, thanks!
asciilifeform: ( the orig author, to be fair, did write it algebraically, but in imho somewhat cryptic form )
asciilifeform: i admit, the seekrit reason asciilifeform could even be arsed to pick the thing up, is that to write serpent in maximally algebraic form might tell us sumthing useful re the weakness.
asciilifeform: so from that point it becomes a q of the actual gate delays. in principle a serpentron that does coupla 100MB/s is physically possible. ( just not on my desk, lol )
asciilifeform: is the actual parallelism of the algo. the rotator would likewise win from having 32 physical instances, as obvious from http://ossasepia.com/2018/02/22/eucrypt-chapter-11-serpent/#selection-87.15048-87.17527
asciilifeform: if i were baking asic ( not sure why anybody would blow 'orbit' moneys on serpent asic, but for the sake of arg ) would unroll the sbox invocation the way it is unrolled in the pc serpent diana_coman is using, there'd be no reason not to have 128 or what, independent copies. but in the tight space of ice40 this is out of the question.
asciilifeform: i've gathered afaik all of the commercial demo boards with ice40, they all have 1 ea.
asciilifeform: ( and conceivably, worth sumthing even if it takes having ~two~ on the board; problem is that i dun presently have a board with 2 , to actually try )
asciilifeform: those are blocking, i.e. take multiple clocks ea.
asciilifeform: rather, it'll be the rotational transforms.
asciilifeform: i expect the sbox won't actually be the bottleneck in a full serpentron tho
asciilifeform: mircea_popescu: as in, whether it actually sboxates at the stated 25MHz ? notyet, gotta write a serial i/o thing for it, to do this. possibly later today.
mircea_popescu: asciilifeform so did you measure throughput of this thing ?
asciilifeform: hanbot: neato, ty
asciilifeform: 'yosys' ( 'icestorm'-'s synthesizer, suggests a max clock rate of ~25Mhz for the posted form. )
asciilifeform: in other minutiae, the terms i left in xor-containing form, can of course be expressed in not/and/or , but this resulted in seven-term ORs , which i assumed is a greater delay than to let it use a xor LUT; but this is not experimentally confirmed, and one might conceivably get better throughput if all of the terms were rewritten in the and/or/not form.
asciilifeform: btw, spoiler : i put the thing in an ice40-8k , simply did not have time to write up yet, and the fwd sbox in fact eats roughly 1/4 of the gates . which leaves the orig question wide open...
asciilifeform: it is also possible that the equations can be simplified further, i did a fairly surface job of it, mostly by hand
asciilifeform: mircea_popescu: observe also that the sbox mechanism is 'bitsliced' (i.e. the bits move only 'vertically' there ) so potentially it can be shrunk at expense of speed . so the real puzzler isn't 'does serpent fit', it can almost certainly be shoehorned, but 'with how little/much unrollage' i.e. what resulting eating bitrate.
a111: Logged on 2018-10-13 07:14 hanbot: anyway the idea is to have an exhaustive list of news outlets with their contact email made, after which i'll have her mail that blurb; i expect something like a week's turnaround, and will report when it's done.
hanbot: mod6, ben_vulpes, et al: nicoleci sent 31 emails (as per http://btcbase.org/log/2018-10-13#1861765 ) to various news outlets last night, and will report any replies here. i expect more mail to go out this week, will update. ☝︎☟︎
asciilifeform: approx, yes ( tho keep in mind that said chip, in order to do useful work, gotta have at least a bit of room for other things, unless one were to equip board with >1 ( not end of the world, they're, what, 8bux ) )
mircea_popescu: asciilifeform basically, if it fits in 1/3 of the chip ?
deedbot: http://www.loper-os.org/?p=2593 << Loper OS - Can the Serpent Cipher fit in the ICE40 FPGA?
deedbot: http://thetarpit.org/posts/y05/07e-hermannstadt-ii.html << The Tar Pit - Hermannstadt, part two: the huge-ass photo shoot
a111: Logged on 2018-10-27 01:49 mircea_popescu: http://btcbase.org/log/2018-10-26#1866669 <<< this statement is too general. "which one has the largest first octet". that's it.
diana_coman: http://btcbase.org/log/2018-10-27#1866701 - ok, I'll implement it this way then and we see ☝︎
deedbot: http://trilema.com/2018/cabinas-genesis-y-otras-ostras/ << Trilema - Cabinas Genesis y otras ostras.
BingoBoingo: <mircea_popescu> BingoBoingo it was just a throway oneliner ic ame up with while walking off a steak, sadly no more there. << AH, I though maybe Tess Hollandaise died of excess mass and had been replaced as leader of the hamplanets by a younger, dumpier model
Mocky: mircea_popescu, do you have any interest in kuwait? if so I can keep this lead warm on the back burner while I work qatar
mircea_popescu: BingoBoingo it was just a throway oneliner ic ame up with while walking off a steak, sadly no more there.
BingoBoingo still waiting to hear the new fope's identity
deedbot: http://qntra.net/2018/10/systemd-vulnerability-allows-crashing-systems-remotely-and-probably-executing-code-too-with-dhcpv6-packets/ << Qntra - SystemD Vulnerability Allows Crashing Systems Remotely (And Probably Executing Code Too) With DHCPv6 Packets
BingoBoingo: Who's the hammiest of the hams now?
mircea_popescu: didja hear the fatican elected a new fope ?
mircea_popescu: i wont cry if every once in 256 cases you do an extra oaep that 50-50 might've not been needed.
a111: Logged on 2018-10-26 21:09 diana_coman: basically "which one has a higher octet first if I walk them from left to right?"
mircea_popescu: http://btcbase.org/log/2018-10-26#1866669 <<< this statement is too general. "which one has the largest first octet". that's it. ☝︎☟︎
a111: Logged on 2018-10-26 21:02 diana_coman: asciilifeform, I guess mircea_popescu has a point: one can choose just *what* has to go through the MPI swamp and what not
mircea_popescu: http://btcbase.org/log/2018-10-26#1866650 << normally not an issue worth thinking about ; but if it coems with saving a lot of gnarly back and forth,,, ☝︎
mod6: thanks trinque
deedbot: BingoBoingo paid trinque invoice 3
diana_coman: asciilifeform, myeah, I don't claim I fully know everything that goes on in there and I quite doubt anybody does; and ftr yes, I'm not at all comfortable with the fact that I had to and have to sign it but... I have to, pretty much
asciilifeform: it was a terrifing thing, i ran away from it. and buggy, also, per diana_coman's dig, and i'm not even convinced that we know the full extent of the buggism.
diana_coman: asciilifeform, in some sense MPI lib is a very good illustration for all sorts of things - "make a call and be surprised" sort of things, especially re memory allocation
diana_coman: more of a hack to accommodate the stink of MPI - not sure it's something we want in there; if anything, I guess I can see more the point to just walking the octets in the array and basically doing the comparison in Ada
diana_coman: http://btcbase.org/log/2018-10-26#1866643 - to detail this: technically speaking one CAN test top bit until it's 0 for the oaep block (hence for *sure* < modulus) but I don't think it's great mainly because: 1. this fixes one more bit 2. it's really a way bigger hammer than needed - it can start with 1 and be smaller than modulus so potentially increases the number of repeat-oaep without any good reason 3. it's not even particularly clean, ☝︎
diana_coman: asciilifeform, theoretically yes; practically since one calls stuff from mpi lib to create the MPIs, there are all sorts of things going on in there
asciilifeform: the conversions are O(bitness) tho, i dun expect they will be major dent in performance. simply ugly aesthetically.
diana_coman is still pondering the best way to treat that so it doesn't make a mess
diana_coman: and yes, the mpi-variable-buffer-returned gives me some headaches
diana_coman: that's the headache: oaep in ada, comparison in C, if not right, oaep in ada again, if right then rsa in C
asciilifeform: but yes, i forgot that the comparison happens after oaep
diana_coman: yes, c_wrappers that I wrote have a wrapper for precisely that mpi_compare thing among other stuff
diana_coman: asciilifeform, I gave up on using gnat's ; mainly because at previous experience things went weird quite quickly
asciilifeform: can use that
diana_coman: basically "which one has a higher octet first if I walk them from left to right?" ☟︎
diana_coman: but the comparison is iffy since either a. call c-wrapper and so do conversion from ada's oaep array of octets to C's MPI shit
asciilifeform: relatedly, asciilifeform is writing a sane paths-handling lib, and it's an uphill climb, tricky to get to/from c representations without pointerism
diana_coman: yes, this is for the OAEP part - current algo repeats the oaep padding until the result is < modulus of given key (since otherwise it can't rsa afterwards)
asciilifeform: idea being, c-isms stop at the spackling layer and propagate no further
asciilifeform: yea but you wouldn't want the idjicy to leak upstream ( per e.g. last night's 'spackling' thread )
diana_coman: but it's true that doing the whole conversion to c and conversion back *just for the sake of an MPI comparison* might be uglier than just walking the arrays and seeing which one has a bit set first
asciilifeform: ( e.g. in the udp thing )
diana_coman: precisely why I preferred to make a wrapper for it so I don't import the whole stinking pile further up
diana_coman: and for the other it's the C style thing where it allocates memory the way it sees fit and the caller is supposed afterwards to clean up the mess when it likes
asciilifeform: yea kochian 'normalization' (variable-width representation of bignums) does that.
diana_coman: BUT: for one thing as previously noticed + tested they trim leading 0 so if you feed it an array with 0 you will NOT get it back the same
asciilifeform: recently was going over ancient notes from my torture room, and it was actually on my to-do, right before i shelved the thing
diana_coman: asciilifeform, it shits a shit: there is get_mpi_buffer and set_mpi_buffer that theoretically do that
asciilifeform: diana_coman: until you wrote the recent piece, i actually forgot that mpi ~didnt~ shit out ordinary octet arrays as-supplied
diana_coman: asciilifeform, I guess mircea_popescu has a point: one can choose just *what* has to go through the MPI swamp and what not ☟︎
asciilifeform: key gen would be a bitch tho