TMSR-RSA spec, extremely early draft

Wednesday, 16 August, Year 9 d.Tr. | Author: Mircea Popescu

I. As far as extant literature is concerned, Werner Koch is a malevolent imbecile whose shameless parents should nevertheless fucking apologize. Everyone elsei "involved" in "crypto" to date is not far behind, from Zimmermanii onwards.

II. The RSA key shall be a 4096 bitiii entity produced out of two 2048 bit primesiv. The key will be stored as a N, e, C structure, where N is the public modulus, e the chosen exponent, and C a comment field of unspecified length. Key fingerprints will be calculated over this structure through a yet-to-be-specified hash function.v

III. The RSA exponent will be a 4096 bit integer at the option of the user. In principle the user can input any 4096 bit prime, but one of two types are recommended : either the FULL stylevi or else the RNG stylevii.

IV. RSA padding will be provided through Keccak-OAEPviii. Messages longer than 2048 bits will be packeted into 2048 bit chunks. There will be no symmetrical cyphers involved at any point. Signatures will be based on the same padding.

IV. RSA implementation will work in constant time and constant space ; the canonical implementation will be written in Ada. Work is ongoing towards a FFA-based approach.

V. Alternative ciphers. Cramer-Shoup.

———
  1. See the logs re useless antecessors, I won't rehash here. Not so much as a fucking constant - time exp they produced, these useless fucktards that aren't anything else. []
  2. Years prior to the reveal, "Zimmerman" responded to an email encrypted to his key by stating (in plain text) that he "decades ago" lost the corresponding key. 'Nuff said. []
  3. For about a year I strongly supported eccentric length key. I gave up on the idea recently, because the arguments against as presented satisfied me -- and when reason speaks emotion'd better shut the fuck up.

    The user will not get any say in the matter. 2048 keys are too short. 8192 keys are too long. Keys of a length that's not a power of two are no good. RSA keys are 4096 bits and that's the end of the story. []

  4. Primality testing, as well as everything else, will be implemented correctly, as opposed to imperialy. This point fractally and endlessly repeats itself throughout, because everything the pantsuits to is retarded on all levels, recursively. Nevertheless, it won't be repeated here. []
  5. The requirements for this role are a) no blocks and b) unlimited size input. The current candidates for this role are either keccak or mpfhf. []
  6. Something like say 1111111111111111111111111111111111111111111111111111111111000101, or more generally speaking 264 - 59, 83, 95, 179, 189, 257, 279, 323, 353, 363 etc []
  7. 1100111110111010111111000100100010011101001010001000100100011001 , or generally speaking anything with ~half the bits set (that's also a prime number, obviously).

    As Stan aptly puts it,

    No moar 'we heathens have faster RSA because mother dropped us as babies and our RSAtron does different work on different hamming weights'

    Word. []

  8. To pad : 1. Produce M00 by adding 0s on the right of message M until M00 reaches 2048 bits in lenght ; 2. Generate R, 2048 bits of entropy ; 3. Calculate X = M00 xor hash(R) ; 4. Calculate Y = R xor hash(X). The padded message M is X + Y.

    To de-pad : 1. Calculate R as Y xor hash(X) ; 2. Calculate M00 as X xor hash(R) ; 3. Remove 0padding.

    The hash function is yet to be specified. It should be a non-block 2048 to 2048 bit hash function (conceivably, can also use two). []

Category: Bitcoin
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.

8 Responses

  1. MPFHF dun go with constant-time-constant-space...

  2. Mircea Popescu`s avatar
    2
    Mircea Popescu 
    Wednesday, 16 August 2017

    I thought we were happy with "at every juncture calculate both the 1 and the 0, throw away one of the two" approach to fix that problem ?

  3. Mircea Popescu`s avatar
    3
    Mircea Popescu 
    Wednesday, 16 August 2017

    Meanwhille, tis gone.

  4. So UDP has a "unfragmented packet" limit of 512 bytes. To use UDP for gossipd, would you use keys of only 2048 bits (256 bytes) or only have a message of 256 bytes with 256 bytes padding, or use the whole 512 bytes for a message and 512 bytes for padding and have a possibly fragmented packet, or send the message in one udp packet and the padding in another?

  5. Mircea Popescu`s avatar
    5
    Mircea Popescu 
    Friday, 18 August 2017

    > or send the message in one udp packet and the padding in another?

    This is fucking precious lol.

    But you have a point, last footnote should have quited 2048 not 4096 bits for padding m00 so that 256 bytes of message are OAEP'd and the resulting 512 byte padded message is encrypted in each packet.

  6. IIUC, for RSA encryption the message must be smaller than the modulus.

    So if we pad our message to get a 4096 bit message for encryption, and we have a 4096 bit modulus, how do we ensure that the message is smaller than the modulus?

  7. Mircea Popescu`s avatar
    7
    Mircea Popescu 
    Friday, 15 September 2017

    There's two approaches, one's to chunk it the other's to add a symmetric encryption layer in between (then you just rsa the key, and so it always fits). The republic favours the former over the latter.

  8. I don't think you undrstood the question I am asking. I get the idea of breaking a long message into chunks, I am talking about a single chunk here. After doing OAEP, you have some 4096 bit number. Some of those numbers are less than the modulus, and so are fine, but what do you do with the ones that are greater than the modulus?

Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.