log
74 entries in 0.6s
a111: Logged on 2019-03-14 01:55 mircea_popescu: diana_coman explain http://btcbase.org/log/2019-03-11#1901356 to me. so there's http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/#selection-37.1-37.47 ; now why isn't it usable for v ? i'm missing something here.
mircea_popescu: diana_coman explain http://btcbase.org/log/2019-03-11#1901356 to me. so there's http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/#selection-37.1-37.47 ; now why isn't it usable for v ? i'm missing something here. ☝︎☟︎
mircea_popescu: http://ossasepia.com/2018/03/01/eucrypt-chapter-12-wrapper-c-ada-for-rsa-oaep/#selection-133.1-133.132 << right, and you want to use ~constant time~ keccak
asciilifeform: rsa-oaep requires hashtronics for padding.
mircea_popescu: wait, when did we move off oaep for rsa padding ?!
a111: Logged on 2017-09-16 02:53 mircea_popescu: incidentally, should prolly take a look at http://www.shoup.net/papers/oaep.pdf also
asciilifeform: i'm willing to 'marry' rsa, but not oaep, oaep only willing to casually fuck
asciilifeform: at any rate, i dun have an obviously-superior replacement for oaep. so presently ( see my rollout calendar ) i'ma implement one. but i dispute that 'cannot be made' claim.
asciilifeform: mircea_popescu: the 'proof' is iffy ( iirc we dug into this in early thrd ) but that aint the thing that makes me hairs stand up: it's that oaep introduces structurism ( for comparison, even the oldest 'all or nuffin' algo, rivest's , does not )
mircea_popescu: http://btcbase.org/log/2018-11-14#1872257 << i am not aware something better than oaep for rsa padding ~could in principle be had~, let alone actually is known to exist. ☝︎
a111: Logged on 2018-11-14 20:20 diana_coman: my understanding was that nobody actually LIKES oaep all that much but it's (again! another one of those!) the thing we have (as opposed to the thing we might wish for)
asciilifeform: ( that is, oaep )
diana_coman: my understanding was that nobody actually LIKES oaep all that much but it's (again! another one of those!) the thing we have (as opposed to the thing we might wish for) ☟︎
asciilifeform: the fixed structure elements in oaep bother asciilifeform . ( initially was gonna do destructurization differently : each bit of payload turned into 4 via rng xor, then fisher-yates shuffle, then the 'deshuffling' binarysort code is appended to message. you can prove that the output is 'all or nuffin' transform. )
asciilifeform: i was hoping to avoid baking hashing into ffa/p , but loox like it isn't escapable if we're doing oaep
diana_coman: meanwhile the oaep got sorted better as part of smg comms really (i.e. only ada calling c, no back and forth dance and that gets rid of a LOT of confusion)
asciilifeform: i in turn am working through diana_coman's oaep articles
mircea_popescu: anyway, back to it : "blockcipher takes 10 bits of P and no more ; spits out 16 bits of E exactly" a) needs entropy and b) probably reduces to rsa-with-oaep.
asciilifeform: http://ossasepia.com/2018/10/31/smg-comms-chapter-5-rsa-with-oaep-from-ada/#selection-155.1206-155.2305 << example of where i'dve used an ada record
deedbot: http://ossasepia.com/2018/10/31/smg-comms-chapter-5-rsa-with-oaep-from-ada/ << Ossasepia - SMG Comms Chapter 5: RSA with OAEP from Ada
mircea_popescu: i wont cry if every once in 256 cases you do an extra oaep that 50-50 might've not been needed.
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: 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: 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
diana_coman: the oaep padding is in ada
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)
diana_coman: will probably cut it in 2 parts two, namely the wrappers first and then the whole big .vpatch bringing in everything needed (mpi, keccak, oaep-but-this-time-from-ada-only)
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
mircea_popescu: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in the rsa packet ? with oaep and everything ?
diana_coman: PeterL - was waiting on your patch for the 255 instead of 256 error on keccak but since it didn't come, I patched it http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/comment-page-1/#comment-4254 ; ref http://btcbase.org/log/2018-10-01#1856345 ☝︎
mircea_popescu: http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/comment-page-1/#comment-4219 << check out peterl!
asciilifeform: ( or see diana_coman's rsa walkthrough, http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/ )
PeterL: diana_coman: http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/comment-page-1/#comment-4218
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].
ave1: diana_comon, Yes, I read the test and the code and your text (also played with the test a little). So I was a little suprised that rsa_oaep_encrypt used mpi code. I will write an alternative.
diana_coman: to answer your question directly though: 1. it certainly could - rsa_oaep_encrypt is just a wrapper so it's meant more as an example of using all the stuff together rather than a standard: I'd expect that there would be other/different wrappers, made to suit specific uses
diana_coman: ave1, do you mean basically http://www.dianacoman.com/2018/03/01/eucrypt-chapter-12-wrapper-c-ada-for-rsa-oaep/#selection-307.1-307.690 ?
ave1: diana_coman: could the input parameter of rsa_oaep_encrypt be a character array? it is now an MPI this will discard any leading zero's of a message an exclude binary stream/file encryption. (same goes for decrypt)
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)
mod6: <+diana_coman> this one: http://www.dianacoman.com/2018/02/20/eucrypt-corecting-error-in-oaep-check/ << this seems to have fixed it
diana_coman: this one: http://www.dianacoman.com/2018/02/20/eucrypt-corecting-error-in-oaep-check/
diana_coman: phf, the oaep_fix_checks seems to be missing and that's possibly also creating trouble otherwise since you're running the code without the fix
phf: diana_coman: btcbase is claiming that i'm missing proper antecedents for smg_oaep.adb/ads, but i think i have all your vpatches. can you please check http://btcbase.org/patches?patchset=eucrypt&search= and let me know if i'm missing something
deedbot: http://www.dianacoman.com/2018/03/01/eucrypt-chapter-12-wrapper-c-ada-for-rsa-oaep/ << Ossasepia - EuCrypt Chapter 12: Wrapper C-Ada for RSA + OAEP
phf: http://btcbase.org/patches/eucrypt_ch10_oaep_tmsr/tree/eucrypt/smg_keccak/smg_oaep.adb#L29 http://btcbase.org/patches/vdiff_keccak/tree/vtools/src/keccak_c.adb#L63
deedbot: http://www.dianacoman.com/2018/02/20/eucrypt-corecting-error-in-oaep-check/ << Ossasepia - EuCrypt: Correcting an Error in OAEP Check
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
deedbot: http://www.dianacoman.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/ << Ossasepia - EuCrypt Chapter 10: OAEP with Keccak a la TMSR
a111: Logged on 2018-02-13 22:06 diana_coman: in other issues: rfc on oaep for tmsr, see http://trilema.com/2017/tmsr-rsa-spec-extremely-early-draft/#comment-124596
diana_coman: in other issues: rfc on oaep for tmsr, see http://trilema.com/2017/tmsr-rsa-spec-extremely-early-draft/#comment-124596 ☟︎
diana_coman: padding, bitstream, sponge, oaep to follow; currently still in the works
mircea_popescu: entirely true that if one builds a hash which can be provenly as strong as rsa, then thathash powered oaep would be the natural padding for rsa
asciilifeform: an oaep (or similar scheme) ciphertron rests on 2 elephants : strength of rsa, and strength of the (voodoo) hash.
mircea_popescu: http://btcbase.org/log-search?q=oaep !
asciilifeform: oaep
a111: Logged on 2017-09-16 02:57 PeterL: by the way, I stuffed the keccak ada stuff (and, speaking of OAEP, here is one of those too) into https://github.com/PeterMLambert/keccak since I don't have my own server up yet
PeterL: With RSA-OAEP, one can encrypt messages whose bit-length is up to just a few hundred bits less than the number of bits in the RSA modulus, yielding a ciphertext whose size is the same as that of the RSA modulus. << It sounds like he is using a smaller amount of random bits than we are?
PeterL: by the way, I stuffed the keccak ada stuff (and, speaking of OAEP, here is one of those too) into https://github.com/PeterMLambert/keccak since I don't have my own server up yet ☟︎
mircea_popescu: (tl;dr : here's proof oaep is insecure ; original "proofs" wrong ; rsa-oaep is not insecure by accident, due to rsa properteis ; here's oaep+ fixed by me to actually work)
mircea_popescu: incidentally, should prolly take a look at http://www.shoup.net/papers/oaep.pdf also ☟︎
mircea_popescu: anyway. other than the above "can constantify mpfhf ?" question, also open is the matter of alternative padding. currently all we have is oaep.
mircea_popescu: oaep won;t constant spacetime either.
a111: Logged on 2017-08-09 15:58 mircea_popescu: anyway, let it be said that there's nothing wrong with oaep as far as we know, but for the sake of argument a mpfhf based padding scheme would conceivably work like this : 1. given message m, of length l, generate r = random bits, of length l' up to l but not less than 256 bits. 2. compose m' = r + m + c (in that order), where c is l - l` (and its bitness is always same as the bitness of len(m')-256). 3. compose Pm = R + S +
mircea_popescu: anyway, let it be said that there's nothing wrong with oaep as far as we know, but for the sake of argument a mpfhf based padding scheme would conceivably work like this : 1. given message m, of length l, generate r = random bits, of length l' up to l but not less than 256 bits. 2. compose m' = r + m + c (in that order), where c is l - l` (and its bitness is always same as the bitness of len(m')-256). 3. compose Pm = R + S + ☟︎
mircea_popescu: oaep works like this : given hash and hash' hash functions, calculate X as hash(m00) xor G(r) and Y = r xor hash'(X).
mircea_popescu: what gpg normally uses is called OAEP
asciilifeform: speaking of timing attack: it also worx great on oaep and all similar (hashtronic) rsa 'padding' systems...
asciilifeform: to briefly revisit earlier thread, i found an old piece by shoup that utterly demolishes the oaep nonsense. (unfortunately pdfized, and not convertible meaningfully.)
asciilifeform: OAEP is slightly better from this pov but also gives you https://lists.gnupg.org/pipermail/gcrypt-devel/2011-June/001797.html .
asciilifeform: but yes, it is 'freeform' in the sense where no algebraicism (as in rivest's, or the popular OAEP) is imposed, and the output can be as long and entropic as one likes.
Framedragger: that's fair. ok. i assume you don't think much of OAEP (i see it mentioned in the logz but only just)
asciilifeform: 'PSS is harder to implement because it uses randomness -- randomness is hard on many embedded systems like smart cards. The most proclaimed advantage of PSS is that it has a "security proof" with, apparently, a rather tight reduction (see this page for some references). Security proofs are not an easy subject; the proof for OAEP (the encryption padding which is like the "sister protocol" to PSS) was found out to be wrong by Sh
asciilifeform: now have to decide 'OAEP' or 'PKCS#1' ?