tmsr - Search: serpent

ossabot: Logged on 2019-01-13 09:29:50 mircea_popescu: ad interim the draft is, that the client stores all the keys (rsa, serpent, whatever) one per line, the rsa ones in republican format, the rest unspecified as of yet, in a file called keys.tmsr encrypted by the rsa key of the client.

diana_coman: mircea_popescu: we have eucrypt that generates the rsa keys and serpent and all that client and server need; we however do not have (and it was supposedly in discussion/waiting/etc) a clear way to store them securely; let me dig log ref

ossabot: Logged on 2019-10-22 06:42:27 mp_en_viaje: anyway, i suppose the logical next step is for the remarkably productive bvt to do some benchmarking re speed of possible candidates (a list including atm the chacha and serpent -- knowledgeable folk feel free to propose more candidates) so as to have some practical basis.

ossabot: Logged on 2019-10-22 06:39:48 diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-22#1947561 - I can see that; my thinking was not towards using sha1 but more towards permitting other-than-serpent mainly because 1. serpent is still snake-oil and only adopted-for-lack-of-better option afaik b. maybe tmsr makes its own hash function next year or something (ha!)

ossabot: Logged on 2019-10-22 02:29:31 mp_en_viaje: http://bvt-trace.net/2019/10/fg-fed-linux-rng/ << the most important q here is, are we going to mandate serpent ? or are we going to permit legacy sha1/chacha ?

bvt: http://logs.ossasepia.com/log/trilema/2019-10-22#1947549 << i certainly liked serpent most, because it went through at least some of form republican investigation, but decided not to hurry too much putting it everywhere.

asciilifeform: http://logs.ossasepia.com/log/trilema/2019-10-22#1947549 << asciilifeform is partial to serpent , but strictly because actually had a chance to do some analysis of it ; and dislikes sha for the obv. reason, and chacha ditto for the reason of originating from post-brainrot bernstein. but theoretically all of these snake oils are equally snake oils, and difficult to argue against the standard 'drink t

mp_en_viaje: anyway, i suppose the logical next step is for the remarkably productive bvt to do some benchmarking re speed of possible candidates (a list including atm the chacha and serpent -- knowledgeable folk feel free to propose more candidates) so as to have some practical basis.

ossabot: Logged on 2019-10-22 06:24:44 mp_en_viaje: diana_coman, a) to avoid the sha1-powered contraction ; b) to reject, discontinue and clearly mark as untenable pantsuit heritage ; c) to disrupt any possible legacy of usgistani shenanigans in the output ; d) to give meaning to the notion of computer identity ("a computer's key is the hash of the sig it uses to serpent its rng code") and e) for simplicity (one mechanism instead of two as now)

diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-22#1947561 - I can see that; my thinking was not towards using sha1 but more towards permitting other-than-serpent mainly because 1. serpent is still snake-oil and only adopted-for-lack-of-better option afaik b. maybe tmsr makes its own hash function next year or something (ha!)

mp_en_viaje: diana_coman, a) to avoid the sha1-powered contraction ; b) to reject, discontinue and clearly mark as untenable pantsuit heritage ; c) to disrupt any possible legacy of usgistani shenanigans in the output ; d) to give meaning to the notion of computer identity ("a computer's key is the hash of the sig it uses to serpent its rng code") and e) for simplicity (one mechanism instead of two as now)

mp_en_viaje: http://bvt-trace.net/2019/10/fg-fed-linux-rng/ << the most important q here is, are we going to mandate serpent ? or are we going to permit legacy sha1/chacha ?

a111: Logged on 2019-07-29 13:49 asciilifeform: given that 'peh' eats tape from stdio (this is by design, so that can 'chain' tapes) the only practical solution to symmetricizing seekritz kept on disk, afaik, is commandline 'serpent' util or similar.

asciilifeform: given that 'peh' eats tape from stdio (this is by design, so that can 'chain' tapes) the only practical solution to symmetricizing seekritz kept on disk, afaik, is commandline 'serpent' util or similar. ☟︎

diana_coman: the Requester is the one who knows where data comes from, what does one need to do to obtain it, what sort of constraints there are (e.g. don't spam server with 1001 requests per second) and even what has to be obtained in order to be able to make a request at all (e.g. a set of Serpent keys!)

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.

mircea_popescu: precisely through same process as yielded here, timings for serpent etc, there's readily recognizable meta-structures

diana_coman: aaand this is it, docs apparently right: fully cleaned up (i.e. none of the serpent vars + init anymore either), max value 16777216, x 22368144; with NO handlers it's 0.9s no sjlj and 0.03 with sjlj; same but WITH 1 handler per proc turns into 1.06s without sjlj and 158.87s with sjlj

diana_coman: <diana_coman> oh, no serpent in there ? it'll run VERY fast though i.e. 0.039s sort of thing -> darn, that's 0.0039

diana_coman: confirmed: with max=65535, no serpent (i.e. empty calls only), I got 0.004, 0.009, 0.007, 0.005 (without sjlj)

mircea_popescu: http://btcbase.org/log/2019-02-13#1895836 << so on the basis of this better table neatly presenting data i'm concluding that a) serpent run indeed takes 2.8 us or so ; b) timing data converges within 1/3 s test runs or so ; c) these statements equal to foregoing earlier items which are thus retrospectively deemed correct and finally, and most importantly d) tentatively it seems sjlj adds no measurable time delay on running co ☝︎

diana_coman: mircea_popescu, I found the key misunderstanding there (in addition to comparing different machines and all that): the 1.25value is when serpent is fully optimised for time i.e. it goes from ~8s to 1.25 for full 22 loops 1..10, mod 4; sorry for the confusion there, I was still in exploration mode.

mircea_popescu: alright. and if there's 22 for loops, this means the correct count of "how many times serpent is run" is 50 ^ 22 then ?

mircea_popescu: asciilifeform basically, we found i can't math ; that aside, we found that in one context serpent takes ~3us, and in another ~0.3us.

mircea_popescu: we are currently entering the loop twice, and we enter a total of 22 loops. therefore the number of times serpent is run is 2 ^ 22.

mircea_popescu: diana_coman the problem is this : on the basis of this last run, we're estimating serpent to take 0.3 microseconds.

diana_coman: it's of course not exactly surprising, given that one goes from 50 serpent executions to 50mn rather quickly

diana_coman: basic test including serpent + test project with full set of loops : ossasepia.com/available_resources/ljmp_test.tar

a111: Logged on 2019-02-12 14:05 diana_coman: mircea_popescu, eucrypt's test on Serpent seem good candidates as one can even adjust how many iterations to do if you want some specific time intervals; current full test of the serpent module (including i/o because of using test vectors in file) is reported by time at ~2.3s without sjlj; this has no tasks/exceptions as such;thing is: time is not extremely precise but I could run I suppose some 1k times and see

asciilifeform: http://btcbase.org/log/2019-02-12#1895272 << serpent dun have many jumps in it, recall, it's unrolled, even fewer jumps (conditional or otherwise) than ffa ☝︎

diana_coman: mircea_popescu, eucrypt's test on Serpent seem good candidates as one can even adjust how many iterations to do if you want some specific time intervals; current full test of the serpent module (including i/o because of using test vectors in file) is reported by time at ~2.3s without sjlj; this has no tasks/exceptions as such;thing is: time is not extremely precise but I could run I suppose some 1k times and see ☟︎

mircea_popescu: wrap it in a few for and if clauses, something like like for( a = 1; a < 100; a = a + 1 ){ if a is even then for( b = 1; b < 100; b = b + 1 ){ ... collector = serpent(collector) }}}

mircea_popescu: ad interim the draft is, that the client stores all the keys (rsa, serpent, whatever) one per line, the rsa ones in republican format, the rest unspecified as of yet, in a file called keys.tmsr encrypted by the rsa key of the client.

mircea_popescu: just note that eucrypt having rsa does in no manner hurt your serpent-only-phonecrypto putative app ; just like it having serpent dun hurt a "this is my pgp implementation" usecase, and so on.

asciilifeform: there is also a serpent-on-ice40 thing, with similar level of unfinishitude; and a ice40-powered 'FG2', ditto.

mircea_popescu: asciilifeform it doesn't ; nor will it, because what truly brings serpent in is the ~space~ not the time problem. ie, because of padding, straight rsa doubles message bulk, which is a major problem for online game.

mircea_popescu: the more i think about this whole serpent business, the more it becomes evident that the ~only~ way to have a cipher (not encryption, ie, asym keys, but enciphering, ie, simmetric keys) stronger than serpent is to ~mix rng bits~. ie, the weakest cipher is the one where len(E) = len(P), and they're all equally week, and 1 serpent worth. to go stronger, you must have something that has len(E) = a len(P) + b sorta thing. the key

mircea_popescu: eg, client can (and well behaved client is expected to) send multiple serpent keys upon first connection.

mircea_popescu: but re your q : these 6 workers pick rsa from queuer ; and these 3 pick serpent from queue.

asciilifeform: mircea_popescu: how wouldja, e.g., 'these 6 cpus for serpent, these 3 -- for rsa' if yer packets are in 1 queue ?

mircea_popescu: "this is needed for the same reason as the generic at UDP lib previously - to allow one to store Serpent messages or RSA messages while maintaining them clearly differentiated" << why are you putting ducks and geese in the same line though ?

diana_coman: mircea_popescu, that was my current idea: 2 sockets, one for rsa and one for serpent, with different ports too

mircea_popescu: diana_coman does it then make sense to have a process that has a socket open and handles the serpent queue, and one proces with a different socket open handling the rsa queue (with a view that these :6666 and :6667 ports then get moved to separate machines if need be) ?

diana_coman: asciilifeform, I don't follow - 1mn clients can send 1mn datagrams to server, what has serpent to do ?

asciilifeform: diana_coman: you're cpu bound ( serpent ) so you likely will never hit the bandwidth bound. so the udpgrams will go in ~realtime.

mircea_popescu: so, i hear from cto the comms spec's mostly implemented. now, we're at the point where we wanna make a rsa and a serpent sender.

asciilifeform: there is also the 'install base pressure'. recall mircea_popescu's serpent thread, when looked like it may have to be scrapped, 'motherfucker, i built battleship on this thing and NOW you say to scrap'

mircea_popescu: we made our own keccak, we made our own serpent, you made / are making our own rsa -- time for our own ecc.

asciilifeform: in the end ragnarok anyway, yggdrasil topples, serpent nidhogg will eat world. why worry.

asciilifeform after the serpent thing has turned to a moar 'measure 7 times, cut 1' direction

asciilifeform: ( and even the serpent disk thing, even, if we ever get around to baking it )

mircea_popescu: asciilifeform my problem with "trying" is that you're stuck trying your serpent keys on stuff.

a111: Logged on 2018-11-10 16:52 asciilifeform: diana_coman: and while we're nitpicking, Serpent message types can be an enumeration (see barnes)

asciilifeform: diana_coman: and while we're nitpicking, Serpent message types can be an enumeration (see barnes) ☟︎

deedbot: http://ossasepia.com/2018/11/10/smg-comms-chapter-7-readwrite-serpent-keysets-tofrom-serpent-messages/ << Ossasepia - SMG Comms Chapter 7: Read/Write Serpent Keysets to/from Serpent Messages

asciilifeform: mircea_popescu: re 'sad serpent hole', a d00d like shinohai could easily take my proggy and determine whether e.g. aes's, key expander is injective (afaik nobody ever bothered)

a111: Logged on 2018-10-29 05:07 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.. )

a111: Logged on 2018-11-02 14:27 deedbot: http://www.loper-os.org/?p=2675 << Loper OS - The Serpent Ciphers Key Schedule Transform is Injective.

deedbot: http://www.loper-os.org/?p=2675 << Loper OS - The Serpent Ciphers Key Schedule Transform is Injective. ☟︎

asciilifeform: mircea_popescu: soo asciilifeform had a bit of sleep and wakes up and turns out the serpent thing has a twist ending

mircea_popescu: the point you make re serpent is solid -- discussions, by the dumptruck. of anything and everything BUT. went there, yielded within the week.

mircea_popescu: yes, well, the entirety of the morning's discussion reduces to "what the fuck've you been spading, i only hear about serpent-this nao".

mircea_popescu: yes, well, i'm not calibrated by you wth. srsly, what you did to serpent wasn't stroke of genius, but simply spade work. you dispute this ?!

asciilifeform: it's essentially what serpent's ( and afaik errybody's ) key inflater already does. except that it doesn't bother to tell you, simply shits out a colliding output.

mircea_popescu: anyway, no, i'm not married to serpent. i don't even fucking like it that much. i even said so!

mircea_popescu: yes, but wrong approach to it all! "here's why serpent's no good, here's why i don't like dea-aes etc, here's rabin method, imo best" IS something.

mircea_popescu: asciilifeform it's obvious, we don't even know serpent is in fact no good, hence "you persuasively suggest may not be good (but not actually done the work to turn that suggestive theory in practice)"

mircea_popescu: why is s.mg better off with republican stack than with java stack ? it's still using serpent!

mircea_popescu: the only different element is that today, unlike in 2015 (and not even RIGHT NOW, today as in this year) diana_coman published serpent code.

asciilifeform: ( and , recall, mircea_popescu almost talked me out of it, 'nobody needs iron disk crypter with questionable serpent' )

asciilifeform: mircea_popescu: fwiw i tried all kinds of approaches to breaking serpent in '16

asciilifeform: unlike the massive pile of pgpgrams-cum-aes we've collectively shat out all over the net, nobody's even ciphered anyffing with serpent of yet, aside from diana_coman's tests

asciilifeform: mircea_popescu: you haven't launched $billion mars probe with serpent in silicon. so you have option ( not proposing 'let's rabin! right nao!' , it's naturally a measure-7-times-cut-1ce subj )

mircea_popescu: i foresaw this need, in 2015. i put 10 btc behind encouraging people to fix the problem. it died an ignominous death, what i have is serpent, that's what it is.

mircea_popescu: so the way this is going now -- serpent is going to be perfectly good (tm) for the republic, because the republic is the republic of slow moving, mentally confused morons that miss their opportunities to speak usefully.

mircea_popescu: not for his crime of "being smart" and "figuring out the true truth". but for his crime of saying things out of time. because there was a fucking time for this discussion, and it was strictly BEFORE s.mg paid money for people to work their ass off in preference of playing with their kids to get it a serpent.

mircea_popescu: im not attached to serpent in any way other than in the following sense you're well fucking advised to pay attention to : 1. s.mg is a corporation, meaning ith's here to make money. 2. s.mg is also trying, but as a fucking distant second, to be a "good" corporation, however that is politically defined. it doesn't give a fuck about this, not in any deep sense, if the money's good it'll go against policy, and CHANGE policy as i

asciilifeform: ( pretty lulzy, btw, i had nfi mircea_popescu were so attached to serpent, nao i feel sad, it's almost like i killed his dog or wat )

deedbot: http://www.loper-os.org/?p=2661 << Loper OS - The Serpent Ciphers Key Schedule Equation System, in Graphical Form.

asciilifeform: i'm almost curious nao, just which nadia will be getting professorship from 'discovering' the serpent lul.

a111: Logged on 2018-10-31 20:41 asciilifeform: ( no prizes for guessing why holyshit.png doesn't appear in the orig 'serpent' paper, or the mountain of 'analysis' ... )

mircea_popescu: in other news, this rapidly deteriorating day (it fucking rained on me at the beach, on TOP of serpent being as tight as hilary's ass) was saved by my ... 404 mn ecu pop in Eulora. very high % valuyable shit, too!

asciilifeform: mircea_popescu: the bigger saddity, is that i dun have anything to offer to plug-in replace 'serpent', nao just as in '16 when mircea_popescu was offering prizes