47 entries in 0.353s
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 ☟︎
a111: 42 results for "rfc4880", http://btcbase.org/log-search?q=rfc4880
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: because rfc4880 reasons.
asciilifeform: i.e. the whole fucking rfc4880/2440 business.
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?
asciilifeform: https://tools.ietf.org/html/rfc4880
asciilifeform: ;;google rfc4880
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.
asciilifeform: rfc4880 key is the fundamental object !
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.
asciilifeform: the whole rfc4880 parser has to be rewritten.
Framedragger: oh maybe rfc4880 in itself does not include a whole certificate bloat thing. ok
jurov: no, pgp rfc4880 format
asciilifeform: (as in, rfc4880 turds)
asciilifeform: pretty basic rfc4880 parser thing aha
mircea_popescu: it's also in the logs, but, https://tools.ietf.org/html/rfc4880
mircea_popescu: https://tools.ietf.org/html/rfc4880
mircea_popescu: it's rfc4880
mircea_popescu: asciilifeform isn't ssh2 rfc4880 compliant ?
asciilifeform: you can, conceivably, convert an ssh key to an rfc4880 key ☟︎
asciilifeform: not per rfc4880...
asciilifeform: smacks of the rfc4880 idiocy
asciilifeform: section 12.2 of rfc4880 sayeth,
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.
asciilifeform: davout: https://tools.ietf.org/html/rfc4880
punkman: https://tools.ietf.org/html/rfc4880
asciilifeform: http://www.loper-os.org/pub/rfc4880.html