tmsr - Search: rfc4880

a111: Logged on 2017-06-16 15:34 Framedragger: asciilifeform: unless #3 you meant ssh key to rfc4880 pgp converter (http://siphnos.mkj.lt/datadrop/crap-from-scans-to-be-sorted/ssh-to-pgp.py), but again, prolly not. don't remember seeing any phuctor innards tbh (except for fingerprint algo), but could just be me

asciilifeform: ( where you apply a magictransform to the whole rfc4880 turd, to get a lattice and get the privs; or at the very least, diddled rng that gives e.g. 48 bits of possible keyspace, so nobody finds straight collision, but their asic can walk it, or the like.

Framedragger: asciilifeform: unless #3 you meant ssh key to rfc4880 pgp converter (http://siphnos.mkj.lt/datadrop/crap-from-scans-to-be-sorted/ssh-to-pgp.py), but again, prolly not. don't remember seeing any phuctor innards tbh (except for fingerprint algo), but could just be me ☟︎

Framedragger: !#s rfc4880

asciilifeform: http://btcbase.org/log/2017-04-07#1640141 << Framedragger is correct, there is a wwwtronic (and rfc4880-parsing) front end, that is in python; and a wholly separate werker that actually does the number crunching, in c. ☝︎

asciilifeform: 'A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint. ' -- ye olde rfc4880

Framedragger: (the siphnos datadrop (http://siphnos.mkj.lt/datadrop/) gives the banners ("banners" folder) and keys (in various formats), including raw ssh-keyscan output (*_scan.tar.bz2), as e,N,IP CSVs (e-N-IP*), a.k.a. tmsr format, and converted openpgp (rfc4880) format.)

asciilifeform: mircea_popescu: gpg used PKCS #1 v1.5 (see rfc4880)

asciilifeform: (phuctor is very deeply baked around rfc4880 and expects all db entries to parse by it, and changing this would be a titanic labour)

asciilifeform: Framedragger: did you ever post your converter-to-rfc4880 script ?

phf: https://tools.ietf.org/html/rfc4880#page-13 (section 4.) over tcp. i have an incremental packet parser that you can attach to tcp stream and it'll give you packet-by-packet on the other end. that's probably not the right solution for going to war though

asciilifeform: was sorta stuck with it, because the rfc4880 parser was a python lib, and i did not have time to write one from scratch.

Framedragger: http://btcbase.org/log/2016-07-18#1505027 << well the rfc4880-formatted keys are already in one-file-per-key, in truth ☝︎

Framedragger: jurov: do you have a script which uses PGPy and generates rfc4880 from e,N, then?

Framedragger: asciilifeform: btw would phuctor (as it currently works) be able to import an otherwise normal openpgp / rfc4880 key either (1) no self-sig or (2) a somehow borked (nulled? haven't looked at rfc4880 data structures yet) self-sig? as i see it lotsa info is actually contained *within* the signed part, in that format..

asciilifeform: if you're structuring the 'comment' field, before long you end up with rfc4880 et al if not careful.

Framedragger: asciilifeform: do you think it's a sensible idea to try and convert ssh public keys into rfc4880, and then submit them to phuctor (possibly in bulk)? or is that something i should leave to you?

Framedragger: asciilifeform: gotcha. i have thing which converts ssh pubkey format to e,N,IP. i'll probably have a thing which generates rfc4880 (inserting ip address as comment field, say) from e,N,IP. thanks!

asciilifeform: mircea_popescu: realize that the routine posted earlier uses all of rfc4880.

asciilifeform: Framedragger: phuctor only eats rfc4880 keys. strictly.

Framedragger: oh maybe rfc4880 in itself does not include a whole certificate bloat thing. ok

asciilifeform: you can, conceivably, convert an ssh key to an rfc4880 key ☟︎

asciilifeform: it is possible in principle to write a provably-correct implementation of a subset of rfc4880, but the result is still horrendously ugly.

mats: i'm on my third attempt at this and i still haven't quite wrapped my head around rfc4880 as well as the behavior of various gpg versions

jurov: mats, ascii_field pursuant to http://tools.ietf.org/html/rfc4880#section-5.2.2 ,the pgpdump lib stops parsing right on the "Two-octet field holding left 16 bits of signed hash value" and does not go further to decode the signature

asciilifeform: ;;later tell mircea_popescu the next screamingly obvious step is to catalogue 'liar keys' - the most interesting species of which consists of keys where the claimed fingerprint stored with a modulus differs from the recomputed (by us) fingerprint. as per http://tools.ietf.org/html/rfc4880#section-12.2

asciilifeform: but rfc4880 does not specify that fp ought to be embedded in sigs.