74 entries in 0.6s
: i'm willing to 'marry' rsa, but not oaep
only willing to casually fuck
: 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.
: 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 )
: 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)
: 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) ☟︎
: 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. )
: i was hoping to avoid baking hashing into ffa/p , but loox like it isn't escapable if we're doing oaep
: 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)
: i in turn am working through diana_coman's oaep
: 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
: i wont cry if every once in 256 cases you do an extra oaep
that 50-50 might've not been needed.
- 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, ☝︎
: that's the headache: oaep
in ada, comparison in C, if not right, oaep
in ada again, if right then rsa in C
: but yes, i forgot that the comparison happens after oaep
: 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
: 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)
: 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
: 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
: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in the rsa packet ? with oaep
and everything ?
: 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_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.
: 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: 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)
: 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)
: 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
: 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
: padding, bitstream, sponge, oaep
to follow; currently still in the works
: 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
: an oaep
(or similar scheme) ciphertron rests on 2 elephants : strength of rsa, and strength of the (voodoo) hash.
: 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
: 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?
: (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)
: anyway. other than the above "can constantify mpfhf ?" question, also open is the matter of alternative padding. currently all we have is oaep
: 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 +
: 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 + ☟︎
works like this : given hash and hash' hash functions, calculate X as hash(m00) xor G(r) and Y = r xor hash'(X).
: speaking of timing attack: it also worx great on oaep
and all similar (hashtronic) rsa 'padding' systems...
: to briefly revisit earlier thread, i found an old piece by shoup that utterly demolishes the oaep
nonsense. (unfortunately pdfized, and not convertible meaningfully.)
: 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.
: that's fair. ok. i assume you don't think much of OAEP
(i see it mentioned in the logz but only just)
: '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