274 entries in 0.453s
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!)
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)
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.
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)
diana_coman goes to run it a few times without the
serpent diana_coman: oh, no
serpent in there ? it'll run VERY fast though i.e. 0.039s sort of thing
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
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.
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: but "here's the 256
serpent keys i want you to pick amongst" is not.
mircea_popescu: eg, client can (and well behaved client is expected to) send multiple
serpent keys upon first connection.
mircea_popescu: well,
serpent processor wants a
serpent item to process.
mircea_popescu: but re your q : these 6 workers pick rsa from queuer ; and these 3 pick
serpent from queue.
mircea_popescu: this machine for
serpent, this machine for rsa, is the model here.
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 ?
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.
mircea_popescu: we made our own keccak, we made our own
serpent, you made / are making our own rsa -- time for our own ecc.
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)
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.. )
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 ?!
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: good thing we have strong entreopy, to run
serpent off it.
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.
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
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!
diana_coman: well, we'll have at least
serpent-tiles for interior design