#asciilifeform | 2020-11-20

feedbot: http://verisimilitudes.net/2020-11-19 << A Syndication of Verisimilitudes -- Debugging SHA

btcinfobot: Current BTC price in USD: $18245.34

watchglass: Polling 16 nodes...

watchglass: 205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.023s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 205.134.172.27:8333 : Alive: (0.083s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=657825 (Operator: asciilifeform)

watchglass: 71.114.46.209:8333 : (pool-71-114-46-209.washdc.fios.verizon.net) Alive: (0.094s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=657825 (Operator: asciilifeform)

watchglass: 205.134.172.26:8333 : Alive: (0.142s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 54.39.156.171:8333 : (ns562940.ip-54-39-156.net) Alive: (0.118s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.129s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 208.94.240.42:8333 : Alive: (0.085s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 143.202.160.10:8333 : Alive: (0.152s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 205.134.172.28:8333 : Alive: (0.133s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=657615 (Operator: whaack)

watchglass: 192.151.158.26:8333 : Alive: (0.153s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 176.9.59.199:8333 : (static.199.59.9.176.clients.your-server.de) Alive: (0.258s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=391683 (Operator: jurov)

watchglass: 84.16.46.130:8333 : (182518.pk.3pp.slovanet.sk) Alive: (0.326s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=431523

watchglass: 185.85.38.54:8333 : (tlapnet-38-54.cust.tlapnet.cz) Alive: (0.353s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=657825

watchglass: 185.163.46.29:8333 : Violated BTC Protocol: Bad header length!

cgra: asciilifeform: something about litmus.sh. 1) as peh is an external too, should check externals before calling peh

cgra: 2) i'm comparing litmus.sh to rfc4880, and i fail to get a match: this 'rsa packet' coincides with signature's unhashed sub-packet section when the section is less than 256 bytes long. in part, it's because the unhashed section length is read as a 1-byte value, and yields 0 (the high byte).

cgra: per rfc4880, unhashed sub-packet section length should be 2 bytes, not 1. and so far i couldn't figure out what 'rsa packet' could mean here. litmus.sh appears to work as long as signature's unhashed sub-packet section is shorter than 256 bytes

cgra: version 4 signature packet format from rfc

asciilifeform: cgra: ty. will take a look. fwiw item was tested w/ not only 2048-bit but 4096-bit pubkeys.

asciilifeform: the 2-byte packet length does not actually seem to occur in any signed material in asciilifeform's archive. hence not encountered this discrepancy.

cgra: i walked through 'ffa_w_borrow_expr.kv.vpatch.asciilifeform.sig' byte by byte, and also stared at 'pgpdump -il <sigfile>' of the same file

asciilifeform: cgra: here, occurs ?

cgra: well, pgpdump says the unhashed sub-section contains one item "issuer key id". but litmus labels this unhashed sub-section "rsa packet", which doesn't parse in my head

asciilifeform: cgra: litmus discards the 'key id' piece

cgra: asciilifeform: do you mean it's safe to assume "unhashed sub-packet" section will always be <256 bytes?

asciilifeform: cgra: probably not, and oughta handle 2byte case. simply, not observed it, to date, in any signed material.

cgra: right. do you still think the 'rsa packet' is a proper label for the section?

asciilifeform: cgra: per rfc, it aint : the rfc supports not only rsa. but i explicitly did not.

asciilifeform: ( litmus specifically specced to work exclusively with rsa signatures; and such as were produced by gpg 1.4.x . )

asciilifeform: given asciilifeform's test material, it is possible that litmus deviates from rfc tradition in other ways. the principal headache in its field use, however, turned out to be the fact that there moar or less is no such thing as two shell interpreters which work the same. i.e. bash is not truly portable.

cgra: ok, i see. and inspecting more of gpg 1.4.x droppings would explain the current wording better?

asciilifeform: cgra: the 'rsa packet' is what in pgpdump is labeled e.g. 'RSA m^d mod n(2048 bits)'

cgra: can you give an example? example i mentioned, is not so

asciilifeform: cgra: plz elaborate re where not-so ?

asciilifeform unfortunately must step out, will return in ~1h

cgra: in 'ffa_w_borrow_expr.kv.vpatch.asciilifeform.sig' the 'rsa packet' coincides with a unhashed sub-packet section. the two hash bytes and a signature section comes after that

cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-11-20#1025074 << sorry i didn't immediately check your link. here's the problem: in this case, 0 bytes get ignored! even though, some should've been.

snsabot: Logged on 2020-11-20 10:31:55 asciilifeform: cgra: litmus discards the 'key id' piece

asciilifeform: cgra: i get , via ./litmus.sh asciilifeform.peh ffa_w_borrow_expr.kv.vpatch.asciilifeform.sig ffa_w_borrow_expr.kv.vpatch : VALID GPG RSA signature from asciilifeform <stas@loper-os.org>

cgra: yes, and i'm arguing: by accident

asciilifeform: cgra: can you explain how ?

cgra: litmus attempts to skip the unhashed section, per one byte, the high byte of the actual size field. so it ends up skipping 0 bytes. actual length is <256, so the high byte is 0

cgra: and from then on, just happens to align. 'rsa packet' helps in this accidental alignment, but it remains a mystery to me, why this piece exists in the code

cgra: asciilifeform: easiest way to check this is print in the litmus code the supposed skip length

asciilifeform: cgra: doing this very thing atm

asciilifeform: cgra: what i'm trying to figure out is why the thing works on 100% of where tested...

cgra: because: unhashed sub section is almost always(?) <255 bytes long

asciilifeform: cgra: this btw used in addition to classic pgpdump, when was mapping out the subset of rfc used by gpg

cgra: i mean <256 bytes

asciilifeform: aha

asciilifeform: cgra: in principle, if advertising 'conforms to rfc2440', all the byte count fields oughta permit multibyte length. i did not do this, because purpose of litmus is more or less strictly to process the ~existing~ set of legacy v-signatures. but the 'read high byte 0 but still align' is bug, though i'm still at a loss re how aligns.

cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-11-20#1025070 << got an example to provide?

snsabot: Logged on 2020-11-20 10:26:15 asciilifeform: the 2-byte packet length does not actually seem to occur in any signed material in asciilifeform's archive. hence not encountered this discrepancy.

asciilifeform: cgra: evidently i'm mistaken re 'no 2-bytes' -- indeed in your example it skips 0

snsabot: Logged on 2020-11-20 10:28:26 cgra: i walked through 'ffa_w_borrow_expr.kv.vpatch.asciilifeform.sig' byte by byte, and also stared at 'pgpdump -il <sigfile>' of the same file

cgra: asciilifeform: it aligns, because you have this 'rsa packet' to cover up the lack of skip. it reads the remaining byte of the two-byte length field and finishes the skip job

cgra: this 'rsa packet' isn't used either, just another skip

asciilifeform: ooh ha

asciilifeform sees it -- the earlier skip not happens, and the low byte + keyid end up 'rsa packet'

cgra: yes :)

asciilifeform: this is 2 bugs -- 1 in comments/names. that, hilariously, adds up to working script. will have to fix.

asciilifeform: ty cgra . i'ma roll it into the earlier ch14ism patch.

cgra: yeah, had a giggle staring at it after initial confusion

asciilifeform: cgra: i'm pretty certain that you're the 1st to actually read this item.

cgra: well, with rfc on the side at least

asciilifeform: possibly at all.

asciilifeform: the few folx who downloaded, ran w/out reading..

asciilifeform: meanwhile, would like to link here recent primo lulz re: crapple's take on the 7th law .

snsabot: (alethepedia) 2020-11-20 billymg: thimbronion: was curious about the OS after reading this article https://archive.is/u7aWQ (says that the new machines will ONLY boot on the latest version of macOS, so was wondering if that also applied to non-apple operating systems)

cgra: gpg generates multiple keys,

cgra: primary and sign/encrypt key separately, apparently at minimum. but those peh conversion samples have only one key, the primary key

asciilifeform: cgra: litmus was intended only for sig verify.

cgra: and primary key apparently suffices for signing, even though gpg has this separate 'signing and encryption key'

asciilifeform: cgra: in principle gpg can be made to sign w/ subkeys. i deliberately included 0 support for subkeyism, user is to export by hand the actual modulus he signed with, when converts pubkey.

asciilifeform: subkeyism was imho by far the most destructive misfeature in classical gpg.

cgra: asciilifeform: is it that you don't have to use separate keys with gpg if you don't want to?

asciilifeform: where, if someone can arrange a sha1 collision, he can add an arbitrary subkey to your published pubkey and distribute that.

asciilifeform: and the resulting sigs will verify using 'your' pub.

cgra: this would mean to me that i could make a long-term key already, only if i can stuff it down gpg's throat for the short term

asciilifeform: in principle yes.

asciilifeform: (if you have some favourite way of genning keys, and then convert to gpg format)

asciilifeform: genning with gpg, however, is problematic.

cgra: asciilifeform: what did you have in mind re public exponent, for ffa keygen?

asciilifeform: cgra: random prime of full length (i.e. that of modulus.)

cgra: exact same process as p and q?

asciilifeform: the reasons for this are discussed in old logs.

asciilifeform: aha.

asciilifeform: idea being, various factoring tricks (and hypothetical cryptoanalysis irons) are known to rely on the use of small exponents (and often, in particular, 65535)

cgra: is my assumption correct that private exponent is a function of those, so in theory can replace d later if didn't generate optimally?

asciilifeform: whether or not this were so, ffa wins nothing from the use of small exponent (unlike e.g. gpg and other heathen arithmetrons)

cgra: (meant also that d = private exponent)

asciilifeform: private exponent is a function of the public exponent and the factors p,q.

asciilifeform: a new public exponent w/ old modulus is effectively a different key.

cgra: yeah, meant exclusively private exponent, and got the answer

asciilifeform: aha

cgra: well, asked a q of both, and fully answered :)

asciilifeform: another elementary reason to use wider bitness for public exponent -- expands the set of possible keys.

cgra: i wonder if gpg will choke on a large e

asciilifeform: cgra: iirc the largest supported e in gpg 1.4.x is 65535.

cgra: hmm, ok, then i guess it's back to mid-term gen plan

feedbot: http://mvdstandard.net/2020/11/bojo-moves-to-implement-green-environmentalism-through-improverishment-plan-as-core-of-reset-and-build-back-after-fucking-up-entire-course-of-events-this-year/ << The Montevideo Standard -- BoJo Moves To Implement "Green" Environmentalism Through Improverishment Plan As Core Of "Reset" And "Build Back" After Fucking Up Entire Course Of Events This Year

asciilifeform: meanwhile, very lulzy usg.court circus, unrelated to elections ( BingoBoingo might find of interest. and maybe locate ocr txt.. )