log☇︎
274 entries in 0.493s
asciilifeform: ( no prizes for guessing why holyshit.png doesn't appear in the orig 'serpent' paper, or the mountain of 'analysis' ... ) ☟︎
asciilifeform: it's a matrix of http://www.loper-os.org/pub/serpent/serpent_with_reduction.txt , prepped for gaussian row-reduction ( xor-sat is in p! motherfuckers ) with horiz. axis -- key bitz, vertical -- expansion bits...
asciilifeform: diana_coman: serpent lulz make sense thus far ?
a111: Logged on 2018-10-30 21:36 asciilifeform: if all (a0..a31, b0..b31, ...) appear in the expansion, then serpent aint actually braindamaged in the sense originally contemplated by asciilifeform .
asciilifeform: http://www.loper-os.org/pub/serpent/serpent_with_reduction.txt << for the impatient.
deedbot: http://www.loper-os.org/?p=2645 << Loper OS - Serpent Ciphers Key Schedule in Algebraic Form: with Reduction.
asciilifeform: if all (a0..a31, b0..b31, ...) appear in the expansion, then serpent aint actually braindamaged in the sense originally contemplated by asciilifeform . ☟︎
asciilifeform: and, if we feel like it, can apply the sboxes of http://ossasepia.com/2018/02/22/eucrypt-chapter-11-serpent/#selection-87.13307-87.14692 and produce a 100%-algebraic statement of the entire key inflater.
deedbot: http://www.loper-os.org/?p=2632 << Loper OS - Terms -88 of the Serpent Ciphers Key Schedule in Algebraic Form.
asciilifeform: gotta point out, serpent aint dead yet
mircea_popescu: i suppose that could be the backup alternative then : if we end up ditching serpent, we use a rsa packet to move ~1.4kb of entropy for initializing the mt, and then use mt generated pads for a cipher.
mircea_popescu: as best i can tell -- the only options are either keep using serpent or else use some kind of recursive hash otp
asciilifeform: test is straightforward, you take yer vintage serpent and feed in k1,string, get ciphertext1, k2,string, get ciphertext2, and observe that the ciphertexts are same (cuz key expanded to same thing)
a111: Logged on 2018-10-29 19:39 asciilifeform: pretty handy proof , however, that the xor liquishit on the right hand side of those serpent eqs, doesn't conserve entropy !
asciilifeform: http://btcbase.org/log/2018-10-29#1867215 << dun feel sad, serpent had to hang on asciilifeform's wall for 2yrs before this. ☝︎
asciilifeform: pretty handy proof , however, that the xor liquishit on the right hand side of those serpent eqs, doesn't conserve entropy ! ☟︎
asciilifeform: pretty tired from curing serpent.
mircea_popescu: weaker than serpent.
asciilifeform: for lulz, would be interesting to dig up the list of 'luminaries' who voted for serpent. ( last i recall, it was public )
asciilifeform: btw i seem to recall that the original mircea_popescu & diana_coman thread where 'let's try serpent' turned up that the current 'paper' is not in fact the original, and the orig has evaporated. nao gotta wonder what was in it.
asciilifeform: hilariously, i have a tall pile of academiliquishit re serpent right here on desk, and it ALL without exception dwells on the sboxes & lineartransform, 0 discussion of key schedule.
a111: Logged on 2018-10-26 17:04 mircea_popescu: in short, because this winding discussion risks overwhelming buffers, the salient points are a) that i'm not ready to go to war over serpent, it's a meh-maybe item ; b) that building our spearheads around items we're not willing to die for may be how the converse of http://btcbase.org/log-search?q=bitcoin+corrupts altogether.
a111: Logged on 2018-10-26 16:48 mircea_popescu: i am experimenting with serpent, and yes it's borne of that ancient discussion of ours, but i'm nowhere near-ready to bake it into "this is tmsr secure disk"
asciilifeform: relatedly, for shits & giggles asciilifeform has been reading a 'digital evidence' law school textbook, for entomological/ameritardological studies, and it goes out of its way to mention 'serpent sank an fbi case'
asciilifeform: thus far, afaik, we already know that there aint 2**256 possible 528-byte serpent expandedkeys. nor 2**128. and as i currently suspect, not even 2**64 .
asciilifeform: the actual bitness of serpent , seems like, is so small as to be iterable on pc.
asciilifeform: logic : take the key inflator http://ossasepia.com/2018/02/22/eucrypt-chapter-11-serpent/#selection-87.13060-87.13306 ;
asciilifeform: mircea_popescu: not only were you right, but i just about have a handle on deriving the factual key bitness of serpent..
diana_coman: asciilifeform, no proof that I'm aware of, as per earlier http://www.dianacoman.com/2017/11/22/taming-of-the-serpent-in-ada/#selection-49.0-49.393
asciilifeform: ( in serpent inflator, the only ops are xor, rotate, and sboxation, all 3 conserve entropy )
asciilifeform: actually, funnily enuff , i nao see a proof for serpent's, but not keccak
asciilifeform: relatedly, asciilifeform tried to bake a proof that the lamehash keyinflater function of serpent is one-to-one ( i.e. actually carries 256bit of the key register's entropy into the 528 bytes of whiteolade ) and not only didnt , but realized that afaik no such proof exists for any 'troo' hash also ( incl keccak.. ) ☟︎
asciilifeform: ^ summary of serial i/o processor thing asciilifeform baked. will be applicable even if we come up with sumthing less sad than serpent, in fyootoor.
asciilifeform: http://btcbase.org/log/2018-10-29#1866964 << specifically in the context of the 'crypto contest' where serpent was trotted out, there was a loud and pompous 'here's ciphers, with jusfifications!' circus. so imho the excuse of 'not knew to wash hands yet' is not available ☝︎
asciilifeform: https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf ( pdfturd! ) << near as i can tell, is the 'full paper' referred to in the 'short'
asciilifeform: mircea_popescu: i have a serious wtf re serpent, and neither the s.mg/classic ada, nor the orig paper, has helped me to make sense of it, and i'm suspecting that i'm thick... so here it is:
deedbot: http://www.loper-os.org/?p=2627 << Loper OS - Serpent in ICE40, Part 2.
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.
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: 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: 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: 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.
deedbot: http://www.loper-os.org/?p=2593 << Loper OS - Can the Serpent Cipher fit in the ICE40 FPGA?
asciilifeform: mircea_popescu: classical serpent eats 256bit key. but ( as illustrated in http://ossasepia.com/2018/02/22/eucrypt-chapter-11-serpent/ ) eats/shits 16 byte payload blox as it goes; a 4096 byte flash sector would need 8 of these, plus i suspect a 9th for the block # ( see earlier re 'known plaintext'ism etc )
mircea_popescu: but wasnt serpent size 256byte ?
asciilifeform: and the q of 'would serpent fit in ice40' is imho also worth answering. i'ma put it in the pipe.
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: ( if anyffing, moar -- iron sepentron is only 'broken' if it actually is captured by enemy prior to serpent-pops )
asciilifeform: and will point out, errybody who transmitted rsa-over-serpent in the 20yrs prior to $breakthrough is just as hosed as the folx who were using pocket iron serpentrons
asciilifeform: and nao you have bright-kid-cipher instead of serpent, same iron
asciilifeform: incidentally , baking such box doesn't marry to serpent, can replace the ice40's feed rom whenever, with whatever one likes
mircea_popescu: in short, because this winding discussion risks overwhelming buffers, the salient points are a) that i'm not ready to go to war over serpent, it's a meh-maybe item ; b) that building our spearheads around items we're not willing to die for may be how the converse of http://btcbase.org/log-search?q=bitcoin+corrupts altogether. ☟︎
mircea_popescu: i want serpent to take me out to dinner first! what!
mircea_popescu: but as it stands, seems sending people to bring me a serpent hdd is not unlike sending people to bring be titted boars. why, can't use women ?
asciilifeform: mircea_popescu: i suspect that there will not be a 'civilized' symmetric cipher, i.e. item with less voodoo flavour to it than 'serpent'
mircea_popescu: i am experimenting with serpent, and yes it's borne of that ancient discussion of ours, but i'm nowhere near-ready to bake it into "this is tmsr secure disk" ☟︎
mircea_popescu: whole problem of "nobody serpent" etc goes away
asciilifeform: serpent was bottleneck, in that gedankenbox.
asciilifeform: ( 'electric' serpent is actually somewhat nontrivial, on acct of the gnarly 'key schedule' algo and the arrayed sboxes )
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 . ☟︎☟︎
mircea_popescu: diana_coman re http://ossasepia.com/2018/10/18/smg-comms-chapter-3-packing-serpent/#selection-85.346-85.466 wouldn't it be better to have a single style for this ?
asciilifeform: or if somehow user extinguishes all of his serpent keys without immediately transmitting a replacement
mircea_popescu: can convey serpent keys over serpent too.
asciilifeform: mircea_popescu, diana_coman : '6.3. The server will issue type 5.2 messages encrypted to the corresponding client RSA key in response to any client messages for as long as it doesn't have a preferred client Serpent key set. The client is responsible for either maintaining or explicitly burning ~all~ of these, and will pay for them in any case' means that if a serpent key is currently set, serv won't issue another unless client explic
mircea_popescu: precisely why we put serpent in there, so alf can go pig wild with his intricate rsaing :D
diana_coman: in other news from the smg comms front: the rsa pack/unpack turned a bit nastier than the nice serpent because (of course!) of the C element; basically the rsa operations are in C (mpi mess) while the oaep is in Ada and the current eucrypt wrapper is fine but doing the ugly dance of C to Ada *and back*; my solution to this is to decree that there will be only ONE direction of calls namely from Ada to C (because Ada is the main, desired par
deedbot: http://ossasepia.com/2018/10/18/smg-comms-chapter-3-packing-serpent/ << Ossasepia - SMG Comms Chapter 3: Packing Serpent
mircea_popescu: there's exactly nothing similar between rsa packet and serpent packet. for the same money could ask to have busses and flour delivered in single container.
diana_coman: the tester does not pack them in rsa or serpent proper so it's the "package" there rather than protocol message, I guess that might be confusing, I'll update
asciilifeform: ( i.e. you dun have to 'check what it is' on top of existing logic, e.g. if port 9000 it goes to serpent, if 9001 -- to rsa , and each respective process validates per the existing rulez )
mircea_popescu: well, minigame using serpent, but anyways.
mircea_popescu: in ~principle~ eve can't even know what serpent keys either server or client are using.
mircea_popescu: 2. fixed size 1472 byte serpent packets.
mircea_popescu: is serpent 128 bits or 128 bytes ?
mircea_popescu: 2. fixed size 1408 byte serpent packets.
mircea_popescu: rsa-size and serpent-size packets handled, rest discarded (and sources punished)
Mocky: http://btcbase.org/log/2018-10-02#1857302 >> still will be filtering incoming UDP by known IPs and preferred serpent keys though anyway, correct? ☝︎
asciilifeform: ( serpent can pad into 4096 )
mircea_popescu: well, rsa packets are 4096 bits multiple ; serpent packets are multiples of 128. rsa key exchange is 16kb fix.
asciilifeform: ( the serpent packets are constrained to simply multiples of 128 )
mircea_popescu: asciilifeform the problem degrades gracefully : even if you do have shared rsa key, client sometimes wants to send serpent keys (which go to rsa) and some other times wants to send plain cruft (goes to serpent). so two sizes again
mircea_popescu: 1. server must be able to acquire RSA key of client. 2. the rsa key of client will have to go in a rsa message, because they presumably don't have serpent keys agreed upon ; 3. the payload for one chunk of rsa key is 1960 bytes, fixed ; 4. the size of a key is 3.x such 1960 byte chunks, meaning 4 chunks. 5. the size of a 4 payload message is 16kb.
diana_coman: asciilifeform, serpent payloads really; rsa is meant for single use when registering with server pretty much
asciilifeform: diana_coman: given that you have rsa in there also, how do you intend to make'em shorter ? or is this strictly re the serpent payloads
asciilifeform: diana_coman: interestingly, just about my entire collection of vintage ada, with the exception of that little serpent thing, qualifies for this museum.
a111: Logged on 2018-08-04 22:05 asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd.
asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd. ☟︎☟︎
mircea_popescu: (for the oursiders : it is the agreement in minigame boardroom that rsa helo packets from existing clients will be lowest priority, after 1. serpent packets and 2. rsa helo packets from unknown clients. the idea is you keep your serpent keys, and continue your "session" whenever, it's kind of a stateless session)\
diana_coman: uhm, dunno about that certainty there; maybe client doesn't want to keep serpent keys between sessions for all I know
mircea_popescu: diana_coman, this is too fluid to fix in a comment, and i'd rather have it here than in #eulora. so : let's call eucrypt.serpent X and eucrypt.RSA-OAEP R. now, 1. client wants to log in, R(hello) -> S[erver].
diana_coman: as to the serpent_self_test procedure - it can in principle even go away entirely as there is an equivalent test in the tests dir where tests should be anyway; the self_test is left mainly because it was in the original, but not crucial in any case
ave1: Then, smg_serpent self_test procedure needs to be function and raised removed
diana_coman: fwiw the footprint of eucrypt with default runtime is 215K (separate components: mpi 109K; bit_keccak 17K; keccak 42K; rsa 19K; serpent 20K - 31K (depending on level of optimisation chosen)
diana_coman: ave1, I tried compiling eucrypt & components using your runtime: need support for Interfaces.C (used by keccak/oaep) and Ada.Unchecked_Conversion (used by Serpent)
a111: Logged on 2018-02-23 14:52 mircea_popescu: speaking of which, what do you think diana_coman should eucrypt also include an elastic hashing algo on top of keccak and serpent ?
mircea_popescu: speaking of which, what do you think diana_coman should eucrypt also include an elastic hashing algo on top of keccak and serpent ? ☟︎
deedbot: http://www.dianacoman.com/2018/02/22/eucrypt-chapter-11-serpent/ << Ossasepia - EuCrypt Chapter 11: Serpent
mircea_popescu: in other news : as work on eucrypt is winding down -- the whole item is just about complete, needs serpent and we've decided to add an oaep-rsa wrapper (mostly as a pretext to do some ada-c interop testing), so roughly speaking by end of month it should actually be done -- we're moving on to shaping up the eulora client-server comms model. this will mostly be a design discussion, will take place in #eulora, prolly take up som
asciilifeform: diana_coman: in the contemplated example, are eucrypt/mpi and eucrypt/serpent plug-in alternatives for each other ?