log
500+ entries in 0.028s
mircea_popescu: asciilifeform not redundant because the rsa processor is "best effort", ie, only goes if there's spacetime in machine
mircea_popescu: there's exactly nothing similar between rsa packet and serpent packet. for the same money could ask to have busses and flour delivered in single container.
diana_coman: the tester does not pack them in rsa or serpent proper so it's the "package" there rather than protocol message, I guess that might be confusing, I'll update
asciilifeform: ( i.e. you dun have to 'check what it is' on top of existing logic, e.g. if port 9000 it goes to serpent, if 9001 -- to rsa , and each respective process validates per the existing rulez )
diana_coman: the port/separate is not an issue at all; at any rate rsa will be processed separately by design (and with lower priority) - but all this part is of no direct concern here
a111: Logged on 2018-10-02 16:25 mircea_popescu: ok, so this back of a digital envelope seems to suggest we want : 1. fixed size 1470 byte rsa packets, made to work with 3920-bit rsa (of which i presume the useful message size to be 1872 bit, diana_coman plox to confirm maffs ?). such a packet has then 1696 bits spare for e and bullshit.
asciilifeform: cuz if it's simply to distinguish the rsa from the symmetricolade without wasting a bit in the payload, could simply listen on 2 ports...
asciilifeform: btw there's a megatonne of 512b rsa keys in my db
asciilifeform: yea not much point in counting banks etc. sad-512bit-rsa of mid-90s
mircea_popescu: in either case, rsa after.
mircea_popescu: either you go "early", in which case 1971 is before 1977 ; or else you go "mass adoption", in which case killer micro is 1990s, but rsa is EXACTLY gribble-assbot schism, cca 2013.
mircea_popescu: asciilifeform rsa first published 1977 ; Intel produces the world's first single-chip CPU, the 4004 microprocessor. in 1971.
asciilifeform: ( at one time i tried to rsa on 6502, it's a royal bitch on 8bit-wide chip with no multiplier )
asciilifeform: rsa very much existed in '80s, good % of the classic papers re real-life algos for it are from exactly then
mircea_popescu: rsa not born yet ; all our practice not yet practiced. i can scarcely blame aurel vlaicu for using textile fixed wing.
asciilifeform: the chillunz may end up a bit confused when notice that there is no rsa in classical btc, but otherwise yes
mircea_popescu: diana_coman is that not a good example ? bitcoin can be mentally reconstructed from fundamentals of rsa and db permanence.
mircea_popescu: i guarantee you 9 in 10 MATH PROFESSORS can't explain rsa.
mircea_popescu: no. entirely without rsa all you get is cipherloade. with rsa but with ~not great wot~, what you get is on display currently in eulora log.
asciilifeform: mircea_popescu: for long time i repeatedly 'hi omfg-rsa-xyz-of-the-day people, here's phuctor, i speak for...' etc. 0 result. but possibly was doingitwrong
mircea_popescu: this is especially true the larger the prime numbers become. rsa uses this disparity to produce an undefeatable encryptio scheme. the two prime factors (13, 17) are the private (ie, secret) key. their product (221) is the public key.
mircea_popescu: right. this is then the rsa problem : it is relatively easy to multiply prime numbers ; it is exceedingly difficult to get them back out of the multiplicated soup
mircea_popescu: nicoleci rsa keys are useless when the key is short. do you understand how rsa works ?
a111: Logged on 2018-09-28 16:21 asciilifeform: and i'ma never recommend to anyone the use of heathen 'rsa chips'. not even because they all, without exception, work with only 'toy' key lengths, but because srsly wtf.
asciilifeform: 'Asciilifeform would never recommend the use of 'rsa chips' as they work with only 'toy' key lengths, work in one direction, and have to be manually transported' << agh what
diana_coman: mircea_popescu, 1872 useful bits in 3920-bit rsa, confirmed
mircea_popescu: ok, so this back of a digital envelope seems to suggest we want : 1. fixed size 1470 byte rsa packets, made to work with 3920-bit rsa (of which i presume the useful message size to be 1872 bit, diana_coman plox to confirm maffs ?). such a packet has then 1696 bits spare for e and bullshit.
mircea_popescu: rsa-size and serpent-size packets handled, rest discarded (and sources punished)
mircea_popescu: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in the rsa packet ? with oaep and everything ?
mircea_popescu: alright then, ima put 1472 bytes helo packet ; meaning 2944 bit rsa keys.
diana_coman: from a practical point of view it does mean that Eulora doesn't use directly TMSR RSA keys though
mircea_popescu: suppose i make the rsa packet 1498 bytes. this then means 2996 bit rsa. problem ?
diana_coman: eulora-sized rsa, hm
mircea_popescu: of course... if we used smaller rsa keys we could fit in the mtu...
mircea_popescu: 4x rsa chunk. 2048 bytes.
diana_coman: he is talking of the new rsa packets that are biggest
mircea_popescu: well, rsa packets are 4096 bits multiple ; serpent packets are multiples of 128. rsa key exchange is 16kb fix.
mircea_popescu: asciilifeform the problem degrades gracefully : even if you do have shared rsa key, client sometimes wants to send serpent keys (which go to rsa) and some other times wants to send plain cruft (goes to serpent). so two sizes again
asciilifeform: rereading http://btcbase.org/log/2018-10-02#1857215 -- if you actually gotta take 'new rsa key' from allcomers, and there is no way to have'em know a seekrit bitstring prior , then yes afaik it is impossible to do better than mircea_popescu's algo. ( it is unclear to me what's to prevent enemy from swamping your system with new acct requests and giving you 9000 TB of rsa keys to store, but possibly i missed a detail )☝︎
mircea_popescu: 1. server must be able to acquire RSA key of client. 2. the rsa key of client will have to go in a rsa message, because they presumably don't have serpent keys agreed upon ; 3. the payload for one chunk of rsa key is 1960 bytes, fixed ; 4. the size of a key is 3.x such 1960 byte chunks, meaning 4 chunks. 5. the size of a 4 payload message is 16kb.
diana_coman: asciilifeform, serpent payloads really; rsa is meant for single use when registering with server pretty much
asciilifeform: diana_coman: given that you have rsa in there also, how do you intend to make'em shorter ? or is this strictly re the serpent payloads
asciilifeform: ( or see diana_coman's rsa walkthrough, http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/ )
asciilifeform: mircea_popescu: even in naked (padless) rsa , sig is always of ~equal bitness to modulus
mircea_popescu: but yes, the bojum is that with rsa you're always throwing away half the bandwidth.
a111: Logged on 2018-09-28 21:21 mircea_popescu: http://btcbase.org/log/2018-09-28#1855353 << actually the winning conjunction here is that a) rsa message size is capped and b) udp packets are capped at ~same size. this is rapidly becoming a case of 4096 bit keys and 2048 bit packets and sayonara.
a111: Logged on 2018-09-28 16:15 Mocky: asciilifeform, O(1) crapolade packet rejection is already available in software with your FFA lib, if RSA over non-frag UDP was built on top, no?
mircea_popescu: http://btcbase.org/log/2018-09-28#1855353 << actually the winning conjunction here is that a) rsa message size is capped and b) udp packets are capped at ~same size. this is rapidly becoming a case of 4096 bit keys and 2048 bit packets and sayonara.☝︎
asciilifeform: and i'ma never recommend to anyone the use of heathen 'rsa chips'. not even because they all, without exception, work with only 'toy' key lengths, but because srsly wtf.
asciilifeform: Mocky: in the past i attempted a fpga rsa also. sadly the 'ice40' would need to be about 250x bigger, for it to be bakeable
asciilifeform: Mocky: in theory you already have rsa with Ch. 4 . but nowhere near line speed.
Mocky: asciilifeform, O(1) crapolade packet rejection is already available in software with your FFA lib, if RSA over non-frag UDP was built on top, no?
PeterL: so the thing you want, would it replicate all of gpg functionality (making them compatible), or would a separate, simpler thing be good (just does encryp/decrypt and sign/verify using rsa)?
mircea_popescu: BingoBoingo : "Pizarro servers do not employ BMC, nor always-on KVM setups. We do not disassemble servers for any reason, so feel free to seal your boxes. Account management is done through RSA process, do not expect that you can sidestep loss of your key through social engineering. Burn Microshit, burn." ?
a111: Logged on 2018-09-04 15:29 asciilifeform: now what i ~have~ wanted to bake, for years nao, is a box with ~2~ jacks, that tests rsa sigs on specially-defined packets at line speed, and drops all the ones that dun pass. this is imho the Right Thing, for entirely curing the disease in question.
asciilifeform: now what i ~have~ wanted to bake, for years nao, is a box with ~2~ jacks, that tests rsa sigs on specially-defined packets at line speed, and drops all the ones that dun pass. this is imho the Right Thing, for entirely curing the disease in question.
mircea_popescu: kristof http://trilema.com/2015/on-how-the-factored-4096-rsa-keys-story-was-handled-and-what-it-means-to-you/
mircea_popescu: http://btcbase.org/log/2018-08-18#1842694 << i'd like to expand on this. 1) to dump a file, the better format is curl -Ls -o /dev/null -w %{url_effective} -X POST -F "pastebox=@file.asc" http://p.bvulpes.com -w %{url_effective} ; 2. to dump a pipe/process, the better format is eg item=`cat ~/.ssh/id_rsa.pub | gpg --yes --no-tty --trust-model always -aer mod6`; echo $(curl -Ls -o /dev/null -w %{url_effective} -X POST -F "paste☝︎
mircea_popescu: nicoleci when it's done curl http://wot.deedbot.org/027A8D7C0FB8A16643720F40721705A8B71EADAF.asc | gpg --import ; and then item=`cat ~/.ssh/id_rsa`; echo $(curl -Ls -o /dev/null -w %{url_effective} -X POST -F "pastebox=$item" http://wotpaste.cascadianhacker.com -w %{url_effective}) ; it'll spit out a pastebin url, say mod6 <url> when it does.
mircea_popescu: nicoleci : ssh-keygen -t rsa -b 4096 -C "nicole@MP's whorehouse"
BingoBoingo: A lol in the spew: "deedbot> http://phuctor.nosuchlabs.com/gpgkey/23B2173C2FF1A9C43007D526720EA2B9EC1CB4AC21503429ACFBA1DA022517B3 << Recent Phuctorings. - Phuctored: 3 divides RSA Moduli belonging to 'James Bottomley <jejb@kernel.org>; James Bottomley <JBottomley@Odin.com>; James Bottomley <JBottomley@Parallels.com>; James Bottomley <James.Bottomley@HansenPartnership.com>; '"
asciilifeform: http://btcbase.org/log/2018-08-10#1840631 << btw i dun have'em all unpacked yet, but estimate the net weight to be somewhere b/w 300 and 500 mil. rsa mods☝︎
asciilifeform: ( recall, this was the orig thrust behind constant-time rsa )
diana_coman: BingoBoingo, thanks! confirmed back on + 1 fg available; unfortunately the simple test from smg_rsa (./tests 11 11 ) still hangs
a111: Logged on 2018-07-31 15:49 diana_coman: asciilifeform, yes, get eucrypt and run the tests for smg_rsa, something like ./tests 11 11 (i.e. 11 times test no 11)
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L65 << incidentally this is erroneous. a correctly-inited FG will never produce interrupt ( the tty ~must not~ interpret 0x03 as control char, it must return all octets verbatim )
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L84 << seems like you re-init the usb dongle every time you read. this is not recommended, i've encountered a chinese ttl plug that wedges if you init it one too many times
diana_coman: asciilifeform, smg_rsa/truerandom.c does the whole stuff really
diana_coman: asciilifeform, yes, get eucrypt and run the tests for smg_rsa, something like ./tests 11 11 (i.e. 11 times test no 11)
asciilifeform: ( deadly simple algo : listen for packet at all times, if received one where nonce incremented and rsa sig is valid, that's now the new packet, and now it, instead of prev, gets pulsed ( http://btcbase.org/log/2018-07-05#1831796 ) out )☝︎
asciilifeform: might be interesting to collect whole set of microshit rsa certs into phuctor.
a111: Logged on 2018-07-07 13:47 spyked: asciilifeform, phathub file contains RSA e and N only. but that's a good point, should also post the other ones under some raw form.
spyked: http://btcbase.org/log/2018-07-07#1832552 <-- updated with non-rsa keys: http://thetarpit.org/posts/y04/076-shithub-2018-06.html#selection-220.0-220.4☝︎
mircea_popescu: it's the direct equivalent of a key, actually. if you regard a rsa key as "a succession of 2048 binary questions" to which one gives exactly correct answers ; then ~choices you make~ are ultimately the basis of identity.
asciilifeform: mircea_popescu: the 6.9 -> 4.6 was in re rsa strictly, unless i misread
spyked: asciilifeform, phathub file contains RSA e and N only. but that's a good point, should also post the other ones under some raw form.
asciilifeform: 'As per the figures above, there were only about 4.6 million RSA keys in existence on GitHub on the 1st of July 2018, as opposed to the approximately 6.9 million found by JuroV' << i suspect that the culprit is the massed usg thrust towards 'use ecdsa nao!'
asciilifeform: spyked: does the csv consist strictly of the rsa keys, or all of'em ? ( asciilifeform currently cannot use non-rsa keys for anyffing )
a111: Logged on 2018-06-26 20:27 mircea_popescu: come to think of it, why am i even having "a wallet", as opposed to say a rsa'd privkey list.
asciilifeform: there's no rsa in trb
asciilifeform: well, trad bitcoin dun rsa
mircea_popescu: come to think of it, why am i even having "a wallet", as opposed to say a rsa'd privkey list.
asciilifeform: (2) is the ro (sorta misnomer, it is upgradeable) rsa checker routine, it is very loosely based on the ancient published one seen in https://github.com/coreboot/chrome-ec/blob/b9f5a3d6baae84950f5ff0c4f7c588e55944818a/chip/g/loader/launch.c , but with a few twists
asciilifeform: and it does seem to get called in the case when neither half of rom passes rsa sig...
asciilifeform: ( spoiler : seems to clumsily look for string 'escue' and some, yet to be determined, magical attribute of a candidate rsa sig )
lobbesbot: phf: Sent 2 hours and 54 minutes ago: <asciilifeform> other interesting observations: 1) loader is not the same as what appears in the src, in either 3.3 or 3.4 fw bin; not only key differs, but eggog strings, and possibly the rsa per se. 2) seems like : nowhere else in the fw is there any other routine which checksums/rsaverifies the cr50 fw , or references the rsa keyz at all other than to print keyid .
a111: Logged on 2018-06-22 18:17 asciilifeform: static const uint32_t LOADERKEY_A[RSA_NUM_WORDS + 1] = { ...blah... } where #define RSA_NUM_WORDS 96 ...
asciilifeform: !Q later tell phf other interesting observations: 1) loader is not the same as what appears in the src, in either 3.3 or 3.4 fw bin; not only key differs, but eggog strings, and possibly the rsa per se. 2) seems like : nowhere else in the fw is there any other routine which checksums/rsaverifies the cr50 fw , or references the rsa keyz at all other than to print keyid .
a111: Logged on 2018-06-22 18:03 asciilifeform: in other lulz, nobody noticed this puzzler, so i'ma put it in the l0gz : https://archive.li/i7BRf << cr50 magic rsa keys; the montgomery multiplier etc uses hardcoded constant, 96 word ( i.e. 3072 bit ) for the mults, but the keyblobs are 97 , for some strange reason, in size...
mircea_popescu: it's supposed to be in enemy hands, as part and parcel of what rsa asym cipher is.
asciilifeform: static const uint32_t LOADERKEY_A[RSA_NUM_WORDS + 1] = { ...blah... } where #define RSA_NUM_WORDS 96 ...
asciilifeform: ^ the 3072 bits that actually get rsa'd on
asciilifeform: in other lulz, nobody noticed this puzzler, so i'ma put it in the l0gz : https://archive.li/i7BRf << cr50 magic rsa keys; the montgomery multiplier etc uses hardcoded constant, 96 word ( i.e. 3072 bit ) for the mults, but the keyblobs are 97 , for some strange reason, in size...
a111: Logged on 2017-10-17 05:59 jurov: "The flaw resides in the Infineon-developed RSA Library version v1.02.013, specifically within an algorithm it implements for RSA primes generation. "
asciilifeform: (i.e. it is not in fact necessary to glitch the rsa check, but would entirely suffice to glitch the unlock command conditional jump)
a111: Logged on 2018-06-11 15:46 asciilifeform: one interesting observation, is that the update mechanism lets you flash in arbitrary crapola into 'rw' section ( it simply won't jump to it if it doesn't pass rsa(sha256(payload)) ) . so theoretically could put a nop sled there, ending with jump into the magic half of unlock routine. and then expose the thing to beta/gamma, and perhaps in a few months it will Do The Right Thing
a111: Logged on 2018-06-11 15:46 asciilifeform: one interesting observation, is that the update mechanism lets you flash in arbitrary crapola into 'rw' section ( it simply won't jump to it if it doesn't pass rsa(sha256(payload)) ) . so theoretically could put a nop sled there, ending with jump into the magic half of unlock routine. and then expose the thing to beta/gamma, and perhaps in a few months it will Do The Right Thing
asciilifeform: cnomad: dpa won't do a lick of good, the boobytrap is a rsa pub sig check, no secrets involved
mircea_popescu: alright. see the topic / read the logs / register a rsa key etc.
asciilifeform: rsa, ecc still 'in software'