1200+ entries in 0.144s
a111: Logged on 2018-04-18 16:32 mircea_popescu:
http://btcbase.org/log/2018-04-18#1801945 << you'll have to explain to me the logic of this sometime. is there some expectation that all bipedals are human and made in the similitude of god or something ? animals are animals, whether superficially human or not, form does not trump structure. if they don't have the spark of humanity, which very much IS
rsa key etc, then how's he remiss using them exactly as a chunk of wood, pi
mircea_popescu:
http://btcbase.org/log/2018-04-18#1801945 << you'll have to explain to me the logic of this sometime. is there some expectation that all bipedals are human and made in the similitude of god or something ? animals are animals, whether superficially human or not, form does not trump structure. if they don't have the spark of humanity, which very much IS
rsa key etc, then how's he remiss using them exactly as a chunk of wood, pi
☝︎☟︎ a111: Logged on 2018-04-17 20:39 diana_coman: and at any rate, we end up with a "hello" packet that is the first one, containing version of comms protocol and client id string and all that jazz but *at most* some bits of the key only, followed by... more packets with the remaining, chopped-up public
rsa key
diana_coman: alternatively the hello message stays single-packet and uses a keccak hash of the public key (n,e,comment) as "account ID" so 3.1.5; then key is sent via Data packages and basically I need to define another type for
RSA public key; server can ask/expect the
RSA key *every time* to preserve same answer behaviour or otherwise only if it doesn't know the key
diana_coman: and at any rate, we end up with a "hello" packet that is the first one, containing version of comms protocol and client id string and all that jazz but *at most* some bits of the key only, followed by... more packets with the remaining, chopped-up public
rsa key
☟︎ diana_coman: but to my earlier obs: so you're fine with people creating account with any
rsa key (well, tmsr/eucrypt
rsa at least) ?
diana_coman:
rsa pubkey if de-facto account id anyway i.e. identifies uniquely one account, yes
mircea_popescu: but no, seems the correct approach is to replace 3.1.5 with "
rsa pubkey". and ACTUALLY use that as the account id.
diana_coman: re creating account: it obviously needs the client's public
rsa and atm that one is nowhere in there, yes; I thought you didn't want them in there because it's not just about "a
rsa key" but rather one registered with deedbot sort of thing
mircea_popescu: (for the oursiders : it is the agreement in minigame boardroom that
rsa helo packets from existing clients will be lowest priority, after 1. serpent packets and 2.
rsa helo packets from unknown clients. the idea is you keep your serpent keys, and continue your "session" whenever, it's kind of a stateless session)\
diana_coman:
http://btcbase.org/log/2018-04-17#1801027 --> uhm, for starters this is not correct; initial hello is meant for....initial, no "previous comms" wtf; server needs to reply not with X(answer) but with R(answer) and yes, it needs to know the public
rsa key of the account; the creation of accts is still a bit in the air as server needs to get somehow the public key
☝︎ 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].
mircea_popescu: nodehelp, Darwin_Fish, consider making a
rsa key and registering it with deedbot, then you can self voice rather than having to do this every half hour.
zx2c4: your guess about secret government conspiracies is as good as mine? some people think they are vast; others think they are small. some think ecc; others think
rsa; some think jfk; others think apollo. ...
mircea_popescu: zx2c4, they have no pill for
rsa ; which is why the ecc behaviour.
mircea_popescu: zx2c4, understand, the expectation here isn't "longer, therefore better". the situation is as described above, my key budget is 4096 bits, both ecc and
rsa are ok by this measure.
mircea_popescu: zx2c4, i am very skeptical because
rsa they hated and ecc they pushed and then suddenly everyone forgot the 90s and is all onboard.
zx2c4: mircea_popescu: ahh that ignorant and antiquated notion, that "key size implies security size". or do you think there will be some amazing GNFS-like algorithms that come out for ECC, requiring ECC to use absurdly huge keys in the same way as
RSA?
mircea_popescu: zx2c4, and the "that many attacks against
RSA dont work with ECC" claim is especially odious, as it comes from a single source, which is a criminal org with a history of manipulatively lying. what happens is that usg publishes every ~useless "attack" on
rsa and withholds the few ~working~ attacks on ecc from publishing. then you get this situation where seemingly, for the very naive surface-seekers, "ecc has advantages". it h
zx2c4: mircea_popescu: the keys in ECC are smaller. if your position is that this cant possibly mean it's more secure than
RSA, then i suppose the actual claim you're making is that 'ECC with ECC-sized keys is less secure than
RSA with
RSA-sized keys'. what's the basis for this?