[00:08:25] *** andar2 has quit IRC
[00:31:18] *** goussx has quit IRC
[02:17:04] *** rrr_ has quit IRC
[02:30:54] *** rrr_ has joined #bittorrent
[02:49:28] <TheSHAD0W> Hah.
[02:49:40] <TheSHAD0W> New torrent client w/ embedded search engine, called "Bit Che".
[02:54:22] <alus> hahaha
[03:10:01] *** kwinz2_ has quit IRC
[03:26:40] *** kwinz2_ has joined #bittorrent
[03:37:16] *** Pharticus has quit IRC
[03:47:34] <choykloun> what routing algorithms do clients actually use btw?
[03:57:55] *** The_8472 has quit IRC
[03:58:16] *** wadim has joined #bittorrent
[03:58:18] *** wadim is now known as The_8472
[04:04:55] *** init0 has quit IRC
[04:06:42] *** init0 has joined #bittorrent
[05:01:27] <swolchok> choykloun: bignum is totally a non-thing with DHT. it's trivial to write a comparison function for 20-byte integers.
[05:02:30] <swolchok> or to take three IDs A, B, and C, and see which of B and C is closer to A
[05:46:07] *** Switeck has quit IRC
[06:08:08] <choykloun> ya
[06:08:17] <choykloun> just check which one has the most significant bit set :p
[06:09:17] <choykloun> wondered wtf people were bringing in bignums for
[07:02:08] *** choyklou1 has joined #bittorrent
[07:17:57] *** choykloun has quit IRC
[07:28:26] *** GTHK has quit IRC
[08:02:49] *** andar has quit IRC
[08:03:50] *** andar has joined #bittorrent
[08:04:08] <choyklou1> anyone wanna talk encrypted dht with me? :P --data_out tx udp:
[08:04:09] <choyklou1> 64 31 3A 74 34 3A 11 9D F5 EB 31 3A 76 34 3A 4C 67 30 30 31 3A 79 31 3A d1:t4:....1:v4:Lg001:y1:
[08:04:12] <choyklou1> 71 31 3A 71 34 3A 70 69 6E 67 31 3A 61 64 32 3A 69 64 32 30 3A 6A 63 68 q1:q4:ping1:ad2:id20:jch
[08:04:15] <choyklou1> 67 6F 75 74 40 40 40 40 40 40 40 40 40 40 40 40 40 65 31 31 3A 70 75 62 gout@@@@@@@@@@@@@e11:pub
[08:04:19] <choyklou1> 6B 65 79 32 35 35 31 39 33 32 3A 07 F9 EB 8B 0F FF A8 A0 85 2A B6 D1 6A key2551932:.........*..j
[08:04:22] <choyklou1> C7 D1 8D EB BA 8F 18 6A D8 30 10 ED D1 01 19 CC 26 13 71 65 .......j.0......&.qe
[08:32:25] *** choyklou1 has quit IRC
[08:53:39] *** choykloun has joined #bittorrent
[08:53:49] <choykloun> ok - kex with curve25519 is definitely doable
[08:53:54] <choykloun> even if done on almost all exchanges
[08:54:06] *** Astro has quit IRC
[09:02:19] *** Astro has joined #bittorrent
[09:13:25] *** _rafi_ has joined #bittorrent
[09:14:02] *** andar has quit IRC
[09:20:36] *** The_8472 has quit IRC
[09:20:57] *** wadim has joined #bittorrent
[09:20:59] *** wadim is now known as The_8472
[09:27:31] *** K`Tetch has quit IRC
[09:32:56] *** K`Tetch has joined #bittorrent
[09:38:44] <choykloun> node 1:
[09:38:45] <choykloun> 39 3A 62 D4 C7 28 4A 3B 36 04 A6 E1 50 E8 25 10 B0 BA 6F 73 6D 57 58 2B 9:b..(J;6...P.%...osmWX+
[09:38:48] <choykloun> 69 0B 8B F8 14 FB 94 3D i......=
[09:38:50] <choykloun> node 2:
[09:38:51] <choykloun> 39 3A 62 D4 C7 28 4A 3B 36 04 A6 E1 50 E8 25 10 B0 BA 6F 73 6D 57 58 2B 9:b..(J;6...P.%...osmWX+
[09:38:54] <choykloun> 69 0B 8B F8 14 FB 94 3D i......=
[09:38:57] <choykloun> \o o/
[09:39:32] <choykloun> using curve25519.. can easily do several thousand/sec
[09:40:49] <choykloun> annyone want to implement it and speak dht encrypted with me? :PP
[09:49:01] *** choykloun- has joined #bittorrent
[09:49:20] <choykloun-> argh.. poor chinese router cant handle excessive DHT traffic.. why does it even keep state
[09:49:23] <choykloun-> its just supposed to ROUTE
[09:53:22] <choykloun-> ok so whats the formal process for getting this into some sort of standard?
[09:53:44] <choykloun-> well i shoul add actual crypto first i guess :p currently it just agrees on a key and then ignores it :)
[09:57:59] *** ckKH has joined #bittorrent
[09:58:02] <ckKH> !@!@!@!$!$!#!#!@
[10:05:52] *** choykloun has quit IRC
[10:05:57] *** ckKH is now known as choykloun
[10:09:42] <choykloun> anyway.. step #1: agree on some standard for encrypted DHT packets...
[10:09:48] <choykloun> regardless of how the key was agreed
[10:15:09] *** andar has joined #bittorrent
[10:15:27] *** choykloun- has quit IRC
[10:25:18] <alus> choykloun: what is the benefit of encrypting the DHT traffic?
[10:26:03] <alus> choykloun: curve25519 is probably the right answer, if encrypting the DHT traffic is your goal
[10:26:41] <alus> choykloun: unfortunately I think malicious peers would be and easier form of attack than wiresniffing
[11:46:38] *** _rafi2_ has joined #bittorrent
[11:48:07] *** _rafi_ has quit IRC
[11:51:24] *** kwinz2_ has quit IRC
[12:10:37] *** _rafi_ has joined #bittorrent
[12:12:55] *** _rafi2_ has quit IRC
[12:36:57] *** _rafi2_ has joined #bittorrent
[12:39:42] *** _rafi_ has quit IRC
[13:07:01] *** _rafi_ has joined #bittorrent
[13:19:54] <choykloun> alus: mostly preventing isps from intercepting/monitoring
[13:20:05] <choykloun> also it provides optional authentication
[13:20:36] <choykloun> performance doesnt seem to be an issue atleast
[13:20:59] <choykloun> my connection chokes out before the ability of my cpu to do EC does :)
[13:21:13] <choykloun> but we should at the very least have a standard for encrypted dht packets
[13:21:15] <choykloun> to mark them as such
[13:21:46] <choykloun> total data overhead is 32 bytes in each ping query and response btw
[13:21:51] <choykloun> 64 if you do auth also
[13:22:00] *** _rafi2_ has quit IRC
[13:22:46] <choykloun> works fine but i need to rework some logic
[13:22:55] <choykloun> because i was stupid when i wrote the first experimental code
[13:22:59] <choykloun> well, young and stupid
[13:23:02] <choykloun> now i'm old and stupid
[13:24:00] <choykloun> curve25519 is so fucking kickass
[13:25:48] <choykloun> anyways
[13:25:51] <choykloun> some stanardization:
[13:26:04] <choykloun> 1. marking packets as crypted and using what algo etc
[13:26:10] <choykloun> 2. naming of asymmetric ciphers
[13:26:34] <choykloun> currently i just toss a 'pubkey25519' into the dict of ping query and resp
[13:26:42] <choykloun> no packet crypto yet
[13:46:22] *** _rafi2_ has joined #bittorrent
[13:51:49] *** _rafi_ has quit IRC
[14:17:10] *** kwinz2_ has joined #bittorrent
[14:21:39] *** _rafi2_ has quit IRC
[14:23:11] *** _rafi_ has joined #bittorrent
[14:30:33] *** _rafi_ has quit IRC
[14:31:48] *** _rafi_ has joined #bittorrent
[14:45:53] *** kwinz2_ has quit IRC
[14:59:43] *** _rafi2_ has joined #bittorrent
[15:02:25] *** _rafi1_ has joined #bittorrent
[15:03:02] *** _rafi2_ has quit IRC
[15:04:10] *** _rafi_ has quit IRC
[15:49:56] *** kwinz2 has joined #bittorrent
[15:52:53] *** BentMyWookie has quit IRC
[15:59:18] *** _rafi1_ has quit IRC
[15:59:54] *** _rafi_ has joined #bittorrent
[16:02:52] *** _rafi2_ has joined #bittorrent
[16:04:09] *** _rafi_ has quit IRC
[16:11:28] *** kwinz2 has quit IRC
[16:16:06] *** Andrius has joined #bittorrent
[16:21:49] *** BentMyWookie has joined #bittorrent
[16:33:39] *** kwinz2 has joined #bittorrent
[16:43:27] *** cgreco has quit IRC
[16:47:57] *** cgreco has joined #bittorrent
[16:55:41] *** kwinz2 has quit IRC
[17:22:19] *** _rafi_ has joined #bittorrent
[17:24:36] *** _rafi2_ has quit IRC
[17:46:19] <alus> choykloun: ok.
[17:47:01] <alus> choykloun: so, what do you have so far?
[17:55:09] *** _rafi_ has quit IRC
[17:55:34] *** _rafi_ has joined #bittorrent
[18:01:13] *** _rafi2_ has joined #bittorrent
[18:02:17] *** bittwist has quit IRC
[18:02:19] *** _rafi_ has quit IRC
[18:06:04] *** Switeck has joined #bittorrent
[18:29:37] <choykloun> working implementation of key exchange,and obviously a protocol for it
[18:30:01] <choykloun> with minimal overhead etc yaddayadda
[18:33:52] <choykloun> and a proof that it doesnt cause clients to blow up :)
[18:35:04] <choykloun> not even anything but barely measurable slowdown in hooking up with 20k nodes
[18:40:48] <choykloun> jchgout (my dht implementation) itself is not suitable for use outside a lab environment
[18:41:12] <choykloun> wasnt its purpose
[18:42:18] <choykloun> also im stupid sometimes so i need to rewrite a part of the crypto code
[18:45:00] <choykloun> or well
[18:45:04] <choykloun> more stupid than usual
[18:48:02] <choykloun> and my first crypto "API" was more of a mess than a api :D
[18:49:40] <choykloun> tried to make it too abstract, kinda
[18:57:39] *** _rafi_ has joined #bittorrent
[18:58:31] *** _rafi2_ has quit IRC
[18:59:59] *** _rafi2_ has joined #bittorrent
[19:00:32] *** _rafi_ has quit IRC
[19:02:25] <TheSHAD0W> http://torrentbomb.com/the-lionshare-tracking-torrents-and-a-girl-movie-2/1193
[19:13:49] <choykloun> theshadow: can you help me out here a bit
[19:14:07] <choykloun> i want to first and foremost submit some protocol extension proposal for how encrypted dht traffic should be handled
[19:14:29] <choykloun> since currently theres obviously nothing to mark a packet as encrypted etc
[19:15:38] <alus> choykloun: you should create a thread on forum.bittorrent.org
[19:16:14] <alus> choykloun: we can discuss protocol and such there, and come up with a draft for the BEP
[19:35:59] <choykloun> no i refuse to ever read that forum again
[19:36:02] <choykloun> besides
[19:36:41] <choykloun> if i posted anything abot anything whatsoever it would end up with jch and some other guy telling im an alarmist idiot or sth like that
[19:37:49] <choykloun> in fact my dht implementation is named in honour of jch :p
[19:49:00] <The_8472> you're not being trolled. you're telling too much tales, going of on tangents, personal accounts etc.
[19:49:17] <The_8472> it's not what people want to talk about
[19:49:51] <choykloun> we've been this over before
[19:49:55] <choykloun> its not about that
[19:50:01] <The_8472> doesn't matter
[19:50:07] <choykloun> anyway
[19:50:16] <The_8472> your style to talk provokes responses you apparently don't like
[19:50:24] <choykloun> me + forum.bt -> unidentifiable black carbonized mass
[19:50:31] <choykloun> as it'd say in organicchemistry
[19:50:52] <choykloun> ya
[19:50:57] * The_8472 prefers barrels full of sulfuric acid
[19:51:12] <choykloun> hydroflouric is the best one!
[19:51:18] <choykloun> also for dissolving bodies
[19:52:12] <choykloun> someone should make a sociopsychological study of me, jch and forum.bt! :D
[19:52:28] <The_8472> i repeat: nobody cares about that
[19:53:53] <choykloun> (i didnt imply that it should involve dissolving bodies :D)
[19:54:06] <The_8472> *sigh*
[19:55:03] <The_8472> ok, let me put it this way... you have provided little information so far neither in the dDoS nor in the ECC-encryption-stuff department
[19:55:48] <The_8472> mostly gut feelings and general concerns. that's ok for a start. but people don't want stories as supplemental information... harder facts/tests/whatever are needed
[19:56:18] <choykloun> ya my original intention was to expand on it while experimenting
[19:56:31] <choykloun> as much of it is things that actually has to be tested
[19:56:41] <choykloun> as the behavior of dht is too complex to predict
[19:56:56] <choykloun> but i have like 2 1/2 jobs
[19:57:16] <choykloun> atleast thanks to xmas i have a working impl of ECC!
[19:57:29] <The_8472> well, then ask questions about existing implementations, ask for best practices we have figured out ourselves etc.
[19:58:05] <The_8472> or keep quiet until you have something substantial. rants about orwellian ISPs scheming to take over the world just irritate people and help nobody
[19:58:08] <choykloun> ive done precisely that on irc
[19:58:15] <choykloun> hm, not really how i would phrase it
[19:58:19] <The_8472> you have ranted about bencoding
[19:58:26] <The_8472> i was paraphrasing
[19:58:26] <choykloun> but ok, i come from a different dev background than some of these guys obviously
[19:58:56] <choykloun> yes but that was half-sarcasm :p
[19:59:02] <choykloun> this is kinda interesting
[19:59:12] <choykloun> coz i never have problems like this in other contexts
[19:59:23] <choykloun> think it has to do with what kind of developer works on these vs other kinds of projects?
[20:00:16] <The_8472> well, the thing is that bittorrent is not one project. we're a bunch of developers from different bittorrent-related projects. some of us have very differing perspectives.
[20:01:15] <The_8472> which occasionally lead to philosophical clashes and heated debates (private trackers vs. public, low footprint/high efficiency vs. additional features, etc.)
[20:01:29] <choykloun> heh
[20:01:35] <choykloun> atleast its not as bad as lkml.
[20:02:06] <The_8472> so it's best to keep standards-making process dry, factual and clean.
[20:02:43] <choykloun> ive never worked on dev projects that havent gone off on tangents
[20:02:48] <The_8472> i often had heated arguments with private tracker admins about the pointlessness of their concept. nevertheless i can work with them if it comes to hashing out an actual spec how something should be handled (like tracker announces)
[20:02:57] <choykloun> including ones involving large groups of ppl spanning ove the globe
[20:02:58] <choykloun> :P
[20:03:04] <choykloun> ya
[20:03:08] <choykloun> i can work with anyone except jch
[20:03:21] <choykloun> and do it in any way except posting on the forum
[20:03:23] <The_8472> ~~
[20:03:43] <choykloun> all that hasn't involved those 2 have been fine so far
[20:03:45] <The_8472> well, then there's a problem
[20:04:12] <choykloun> anyways
[20:04:36] <choykloun> what's needed is: 1. standard for encrypted dht udp bencoded blah packets 2. formalizing my curve25519 kex
[20:04:56] <choykloun> well ok first figuring out why the hell i just broke my implementation, but that's not your concern really .. :)
[20:05:36] <The_8472> 1. is a pita considering that you often talk to nodes you've never seen before or they talk to you
[20:05:37] <choykloun> i've shown that its definitely viable performance-wise
[20:05:53] <The_8472> so you'll often need at least 1 additional packet
[20:06:10] <choykloun> well obviously you'd only send encrypted packets if you have a shared encryption key already
[20:06:24] <The_8472> then your threat model gets more complicated
[20:06:35] <The_8472> since some packets are unencrypted and thus could be manipulated
[20:06:54] <choykloun> (+ maybe add some special cases for pure obfuscation)
[20:07:08] <choykloun> well
[20:07:26] <choykloun> it both nodes support c25519 the only unenc packets would be the pings
[20:07:45] <The_8472> except that you usually don't ping nodes
[20:08:10] <The_8472> pings are only needed for routing table maintenance. actual lookups never ping
[20:08:24] <choykloun> as ive interpreted the standard it would
[20:08:33] <choykloun> but it can be done with any packet in that case
[20:08:34] <The_8472> during lookups you just send a packet, receieve a reply (maybe, it's UDP after all) and will never hear of the node again
[20:08:40] <choykloun> just add the pubkey25519 field
[20:08:58] <choykloun> my impl pings all new nodes
[20:09:08] <The_8472> yeah, that's not how things work in reality
[20:09:46] <The_8472> ping + exchange would increase error rates due to packet drops. both would have to succeed
[20:09:55] <choykloun> so, now it works again.. sometimes i believe i should be prohibited from coding on my own projects :P
[20:10:16] <choykloun> the exchange can take place with ANY query
[20:10:37] <choykloun> i just picked ping since it seemed suitable to restrict it to that
[20:10:42] <The_8472> no. since you need the keys first to encrypt the exchange
[20:11:10] <choykloun> then we can add standards for pure obfuscation cryptos
[20:11:27] <choykloun> that doesnt provide secrecy but takes a lot of cpu time to decrypt on a massive (isp) scale
[20:11:38] <choykloun> and possibly to even detect on the network
[20:11:53] <choykloun> but ppl have been negative to that in the past
[20:12:11] <The_8472> sure sure, i'm just highlighting how the things you're talking about don't match up with reality right now
[20:12:35] <choykloun> ya thats kinda the purpose of a discussion isnt it
[20:13:53] <choykloun> primary goal for this specific stage was seeing whether curve25519 is efficient enough to do on a large scale, and it definitely seems to be
[20:13:58] <choykloun> passed the test with flying colors
[20:14:01] <The_8472> and big changes to the protocol need a big motivation to get people to implement it. nobody has demonstrated the necessity so far. like some real ISP actually manipulating DHT packets or whatever
[20:14:16] <choykloun> proactivity!
[20:14:27] <choykloun> isps modify bt already...
[20:14:46] <choykloun> and >50% of all traffic blocked in china is announce requests
[20:15:32] <choykloun> and companies such as PL can easily do it in their existing hardware
[20:15:36] <The_8472> yeah, but chinese devs don't talk to us, and that xunlei thingie... we don't like it
[20:15:58] <choykloun> can help you get in touch with asians
[20:16:10] <choykloun> but a lot of the users use standard clients
[20:16:16] <choykloun> so it'd "filter down" anyways
[20:16:40] <choykloun> i have real actual logs and statistics from chinese blocking :p
[20:17:11] <The_8472> see, that's something useful that should have been posted after condensing the data
[20:17:49] <choykloun> lets see where the hell i have them
[20:18:06] <choykloun> cant publish the whole things right now though.. certain issues would arise from that
[20:18:21] <The_8472> that's why i said the information should be condensed
[20:18:31] <choykloun>  i hear ya
[20:18:54] *** goussx has joined #bittorrent
[20:18:56] <choykloun> i nee to find where i put the damn tihngs heh
[20:19:00] <The_8472> that and that most people would be to lazy to analyse it anyway
[20:20:33] <choykloun> anyway what i can tell you is that the single most frequently blocked site is the tpb tracker
[20:20:52] <The_8472> s/is/was/
[20:20:56] <choykloun> it alone accounts for like half of all reqs blocked at this level
[20:21:36] <choykloun> ACCOUNTED
[20:21:42] <choykloun> i guess im too used to khmer heh
[20:23:35] <choykloun> i can barely remember to get dressed in the morning so imagine me finding logs from a few months ago ?!
[20:24:36] <choykloun> + i think i got them encrypted and never decrypted them to disk.. so that really makes grep'ing a lot easier...
[20:24:37] *** stalled_ has joined #bittorrent
[20:24:40] <choykloun> oh well
[20:24:42] <choykloun> will dig them up
[20:25:00] <choykloun> me and jl from wikileaks are planning to do some comprehensive study of the data
[20:25:34] * The_8472 goes back to experimenting with bloom filters for DHT scrapes
[20:26:26] <choykloun> sounds kewl
[20:27:30] <choykloun> i should really implement some intelligent routing in jchgout
[20:27:36] <choykloun> so it can be used for stuff besides experiments
[20:29:48] *** stalled has quit IRC
[20:30:09] *** stalled_ is now known as stalled
[20:31:10] <choykloun> here we have them
[20:31:12] <choykloun> a short snip atleast
[20:31:40] <choykloun> out of 1000 blocked http requests 970 matches GET /announce
[20:32:22] <choykloun> (!!!)
[20:32:55] *** _rafi_ has joined #bittorrent
[20:33:05] <The_8472> how about UDP announces?
[20:33:12] <choykloun> most common user agent is simply "Bittorrent"
[20:33:26] <choykloun> utorrent is popular
[20:33:34] <choykloun> bitcomet makes a surprisingly strong appearance
[20:33:40] <choykloun> what the hell is "NP0202_0_0"
[20:33:49] <choykloun> i dont have any logs of udp sorry
[20:34:13] <choykloun> but i do have logs from dns so if you know any dht nodes with static ip addrs i can search for them
[20:34:44] <The_8472> well, the bootstrap nodes router.bittorrent.com and router.utorrent.com
[20:34:52] <choykloun> good idea
[20:34:58] <choykloun> lets see if they are anywhere in this short sample
[20:35:21] <choykloun> nope
[20:36:25] <choykloun> btw all clients found doing GET /announce: azureus, BTSP, BitComet, BitTorrent, Mozilla, NP0202_0_0, qqdownload, uTorrent
[20:36:32] <choykloun> wtf.. BTSP, BayTSP?!
[20:36:35] <choykloun> and what is NP0202
[20:36:57] *** _rafi2_ has quit IRC
[20:37:17] <choykloun> obviosuly the sample is so small that a client simply not obeying announce intervals could appear much more common than it is
[20:37:36] <choykloun> but ya obviously people run common bt clients in china too
[20:38:54] <choykloun> utorrent was the only one doing a scrape
[20:39:00] <choykloun> need a bigger sample though
[20:39:05] <choykloun> i know the guy who has it
[20:39:10] <choykloun> just hasnt downloaded it on my 256k dsl
[20:42:11] <alus> I'm mildly interested in obfuscated DHT. it's completely possible, and could be done fairly cheaply
[20:42:22] <choykloun> and ive done it with a lot of protocols in the past
[20:42:31] <alus> we always suspected Sandvine was reading DHT packets, but since Comcast is paying users back for that "service"...
[20:42:32] <choykloun> its very possible to prevent large scale traffic analysis
[20:42:39] <choykloun> but still making the penalty for each node ver small
[20:42:57] <choykloun> and i know the guys at PL who build the boxes that do this
[20:42:59] <choykloun> which helps :)
[20:44:54] <choykloun> and im somewhat versed in asic/fpga design
[20:45:07] <choykloun> or atleast how to make it as difficult as possible to do something in hardware
[20:45:31] <alus> require massive amounts of state per node ;)
[20:45:32] <The_8472> note that some BT implementations run on hardware too
[20:45:43] <choykloun> the_8472: BT ASICs ??? please show me !
[20:45:49] <The_8472> not asics
[20:45:52] <choykloun> alus: not a good idea in the BT case :P
[20:45:52] <The_8472> embedded systems
[20:45:57] <choykloun> thats still in software
[20:45:59] <choykloun> unless they use fpga's
[20:46:04] <choykloun> then its uhm
[20:46:06] <choykloun> soft hardware?
[20:46:16] <The_8472> well, closer to hardware i meant
[20:46:25] <The_8472> in resource-constrained environments
[20:46:34] <choykloun> even the stuff running on a microcontroller is software :p
[20:46:38] <choykloun> and THAT'S resource-constrained :)
[20:47:06] <choykloun> i wonder if people get happy if our new alarm system ships with an embedded bt+dht client..hmm :)
[20:48:10] <choykloun> i should try sending the rent-a-cops a panic alarm with the message "OUT OF DEXTER EPS" and see what happens !
[20:48:17] <The_8472> anyway, for encryption there would be several conflicting goals: minimize the number of additional packets needed, minimize the state that inidividual nodes have to keep around (stateless implementations based on a few local, secret constants are preferable), keep CPU time down, keep the protocol complexity down
[20:48:31] <The_8472> oh... and defend against as many threats as possible so we get something for our effort
[20:48:43] <choykloun> yes yes yes and yes
[20:48:57] <choykloun> one of the key things to make asic difficult is using a fair bit of memory
[20:49:15] <choykloun> so they have to access the bus
[20:49:26] <choykloun> instead of storing it locally
[20:49:44] <choykloun> i hvent kept up with asic design
[20:50:04] <choykloun> but we'd need something that an asic might have in 10 years or so ?
[20:50:22] <choykloun> could use some constant thats a bit expensive to calculate
[20:50:29] <choykloun> that way you can precalculate as much as fits in memory
[20:50:43] <choykloun> pi could be an excellent choice
[20:50:46] <The_8472> nono
[20:50:59] <The_8472> wrong approach ^^
[20:51:06] <choykloun> ok?
[20:51:27] <The_8472> you basically have to use semi-secret information that is expensive to gather and keep up to date.
[20:51:37] <choykloun> wasnt that what i just said
[20:51:47] <The_8472> pi isn't semi-secret
[20:51:55] <choykloun> or are you meaning on a "higher" level
[20:52:01] <choykloun> no but it doesnt have to be
[20:52:30] <The_8472> more like the bittorrent obfuscation protocol. the infohashes are technically public but in effect only the clients using them know them, a MITM attack would require you to first gather tons of infohashes and then pick the right one on the first attempt.
[20:52:30] <choykloun> the reason is that the ASIC will be slowed down like 100-fold by having to access RAM on the bus to get digits of pi
[20:52:38] <choykloun> instead of just using its internal flipflops
[20:53:01] <The_8472> defending against asics in particular is not something you want to do, it's to specific
[20:53:02] <choykloun> problem with dht is that nothing is known when two nodes first meet
[20:53:14] <The_8472> we might know their node IDs
[20:53:15] <choykloun> well it also defends against parallellization in general
[20:53:23] <choykloun> besides isps would run this in asics
[20:53:27] <choykloun> well mix of asics and sw
[20:53:33] <choykloun> _might_
[20:53:34] <choykloun> :(
[20:53:42] <choykloun> and nodeid's can change
[20:54:09] <choykloun> what's wrong with pi?
[20:54:18] <choykloun> or any similar calculation
[20:54:23] <choykloun> (i recall using discrete logarithms)
[20:54:45] <The_8472> it's essentially a fixed constant. not really all that useful. it doesn't provide real security in the cryptographic sense
[20:54:55] <choykloun> no but thats not what we're after
[20:55:02] <The_8472> yes, it is
[20:55:03] <choykloun> we're after making decryption on a large scale too expensive
[20:55:27] <choykloun> and after KEX is done they cant read it anyway so
[20:55:30] <The_8472> first you have to achieve security at the crypto-level system, according to a specific threat model. then you can look at making it more expensive for a particular attacker
[20:55:35] <choykloun> then its cryptographically secure
[20:56:04] <choykloun> we basically just need to protect it until the key is agreed
[20:56:13] <choykloun> then we have actual cryptographical security
[20:56:41] <choykloun> and we could focus especially on making MITMing the key exchanges as expensive as possible
[20:56:46] <The_8472> i.e. defend against MITM or manipulation of unencrypted parts of the traffic. in the worst case they could just syphon off all local DHT traffic into a local dummy DHT by intercepting bootstraps for example
[20:57:21] <choykloun> tehre are several things to defend against
[20:57:32] <choykloun> traffic patterns/analysis detecting/blocking DHT
[20:57:40] <The_8472> yes, and ASICs is a low-level concern. you have to consider high-level goals first
[20:57:45] <choykloun> passive snooping of ppl's downloads
[20:57:55] <choykloun> active manipulation
[20:57:55] <choykloun> etc
[20:58:05] <The_8472> now you're going in the right direction
[20:58:16] <choykloun> we're just approaching this from different backgrounds
[20:58:33] <choykloun> i think of what tech they would use to do this
[20:58:40] <choykloun> and how to defend against that tech
[20:58:50] <The_8472> then they just change the tech
[20:58:54] <choykloun> no
[20:59:03] <choykloun> tech as in ASIC/FPGA based traffic analysis boxes
[20:59:33] <The_8472> yes, that defends only against those. not against similar but differently implemented attacks
[20:59:35] <choykloun> once we have something concrete i'll run it by some friends at packetlogic and get their comments
[20:59:46] <choykloun> it would provide protection against all large-scale attacks
[20:59:49] <The_8472> e.g. a regular PC aiming only at a few targets instead of many
[21:00:00] <choykloun> ah yes thats correct
[21:00:25] <choykloun> but if they know the ip addrs of those few targets we are screwed anyways
[21:00:37] <choykloun> well we can implement support for signed KEX
[21:00:38] <The_8472> think further
[21:00:42] <choykloun> but that would require them to exchange keys in advance
[21:00:48] <choykloun> and also curve25519 cant do "real" signing
[21:00:51] <choykloun> its a bit pain in the ass
[21:01:08] <The_8472> they could first attack the few, gather information about nearby nodes and widen their net or whatever
[21:01:14] <The_8472> high level security first
[21:01:26] <choykloun> but one thing would definitely be to make the traffic appear as random as possible
[21:01:31] <choykloun> no signatures
[21:01:34] <choykloun> easily done
[21:01:59] <choykloun> done it many times but usually for evil purposes
[21:02:20] <The_8472> that doesn't work all too well, DHTs cause pretty unique traffic patterns that should stand out. even more than bittorrent peer-peer traffic and they can already spot that one even when it's encrypted
[21:02:36] <Switeck> I'm not so sure...
[21:02:49] <choykloun> by pattern i mean pattern matching
[21:02:56] <choykloun> IDS stuff
[21:03:00] <Switeck> most of the Bittorrent peer-to-peer traffic that's being 'spotted' is because they are handed a handy list from the tracker
[21:03:09] <The_8472> yeah, flow behavior, timing and things like that
[21:03:21] <choykloun> for the real tinfoilhats, make a DHT-over-DNS standard and run that
[21:03:22] <Switeck> Plus, once they deduce your incoming port based on that...it's elementary
[21:03:29] <The_8472> Switeck, i tried DHT-only, tracker disabled with someone who was affected. they still got shaped
[21:03:53] <Switeck> they have to be firewalled with random outgoing ports to have a prayer
[21:04:07] <choykloun> could use spoofing
[21:04:09] <Switeck> and too many ISPs throttle unknown traffic by default
[21:04:13] <choykloun> atleast from non-residential connections
[21:04:23] <choykloun> you see 5 different sources
[21:04:25] <The_8472> choykloun, not practical
[21:04:26] <choykloun> you dont know which is real
[21:04:36] <choykloun> maybe not for general dht use no
[21:04:45] <The_8472> then it's out of the window ^^
[21:04:48] <Switeck> So if it was someone on Bell ADSL in Canada, Rogers Cable in Canada, or BT Central ADSL in the UK...or any podunk ISP in some 3rd world country, that comes as no surprise. :P
[21:05:08] <The_8472> was tiscali iirc
[21:05:12] <choykloun> im on a podunk isp in a 3rd world country and i have a totally unfiltered connection with my own /24 :P
[21:05:21] <Switeck> oh, carphone warehouse!
[21:05:40] <choykloun> but i know that some thai isps do funny things with PEX
[21:05:43] <Switeck> They declared war on BitTorrent and even YouTube
[21:05:58] <choykloun> we're gonna play with announce proxying at the isp someday
[21:06:11] <choykloun> since the problem here is interantional transit
[21:06:17] <choykloun> capacity within the country is fine
[21:06:21] <choykloun> fiber is even cheaper than in the west
[21:06:31] <choykloun> and copyright doesnt exist as a cultural concept
[21:07:15] <choykloun> lets see if some of my earlier work for an experimental decentralized p2p system is usable
[21:07:35] <choykloun> its quite tinfoilhat level though
[21:08:08] <choykloun> code says more than 1000 words so lemme show you the tx function
[21:08:18] <choykloun> its tcp though but principle is the same regardless of whether its tcp or x25
[21:08:56] <choykloun> http://thefin.knark.net/memoryhole/user/spwrite.txt
[21:09:36] <choykloun> thats the layer that randomizes packet contents and sizes
[21:09:51] <The_8472> well, that code is unreadable, but from the comments it reminds me of the bittorrent encryption handshake
[21:10:01] <choykloun> haha wtf its not :D
[21:10:09] <choykloun> its like 1/3 comments :P
[21:10:35] <The_8472> usually i don't read comments, i read code. in java we write code that speaks for itself ^^
[21:10:58] <choykloun> in C we comment so people whose brains have been damaged by java can read it :PPP
[21:11:01] <choykloun> anyway
[21:11:15] <choykloun> format is basically like this
[21:11:33] <choykloun> [1 byte nonce length][nonce][data encrypted with nonce+any shared key][random padding]
[21:11:41] <The_8472> https://azsmrc.svn.sourceforge.net/svnroot/azsmrc/azsmrcplugins/trunk/lbms/plugins/mldht/kad/PopulationEstimator.java
[21:12:11] <choykloun> the_8472: my condoleances
[21:12:48] <The_8472> it's readable and practically doesn't need comments except to explain the rationale for algorithms
[21:12:50] <choykloun> if you can find the solaris src check out their malloc impl
[21:12:55] <choykloun> has a really nice balanced tree
[21:13:31] <choykloun> well in the code snippet i showed nothing except the specifics of the lib calls might need explanation
[21:14:36] <choykloun> only thing that might be unclear is the place where the data is re-encrypted
[21:15:07] <choykloun> just do a grep for all comments and just read them, that will prevent you from being confused by actual computer language code :)
[21:15:20] <The_8472> the comments are fine
[21:16:15] <choykloun> anyway
[21:16:19] <choykloun> you see the basic concept
[21:16:33] <choykloun> thats my standard way of easily randomizing traffic
[21:16:58] <choykloun> this one is adapted for a specific protocol obviously
[21:17:24] <choykloun> and dht realities puts some limitations on how thick your tinfoilhat can be
[21:17:55] <choykloun> proposal #1: the marker for an encrypted/obfuscate dht packet is that it starts with ANYTHING EXCEPT 'd'
[21:20:09] <choykloun> proposal #2: all encrypted packets should use a fixed length nonce, any size randomization should be done by padding at the end
[21:21:26] <choykloun> proposal #3: all encrypted packets should include some sort of 'encryption session ID' like we discussed earlier.. could just be a random 32 bit int (i doubt dht will grow big enough for the birthday paradox to come into play here..)
[21:22:15] <choykloun> proposal #4: randomization doesnt have to be cryptographically strong but it MUST provide an even statistical distribution
[21:22:25] <choykloun> comments?
[21:23:26] <The_8472> too low level.
[21:23:33] <choykloun> im a low-level guy :)
[21:24:13] <The_8472> first describe the threat model, then which packets should be encrypted, which nodes have which kind of information they can use for encryption etc.
[21:24:27] <choykloun> now you remind me of my dayjob(s) :(
[21:24:39] <choykloun> threat model we have pretty clear already no
[21:24:50] <The_8472> nope
[21:24:57] <choykloun> and as far as the rest it should very well be up to each developer
[21:25:06] <The_8472> nope
[21:25:07] <choykloun> we just need a basic protocol
[21:25:22] <The_8472> efficiency is important, so it has to be tightly integrated
[21:25:29] <choykloun> ok ok
[21:25:58] <choykloun> #1-#4 ove there are basically relevant for all sorts of interception
[21:26:13] <The_8472> they're cryptography 101 ^^
[21:26:17] <choykloun> yup
[21:26:23] <choykloun> on purpose
[21:26:35] <choykloun> to be as inexpensive as possible for the endpoints
[21:28:10] <choykloun> could do anything from client-side puzzles to ssh-style host key exchange to prevent MITM of KEX, but all that's dependent on having an agreed protocol to send encrypted stuff in the first place
[21:28:48] <choykloun> currently all my curve implementation does is dump the agreed key to the debug log .. :P
[21:29:45] <choykloun> and to do any large scale experiments obviously a common protocol is needed
[21:31:09] <The_8472> the tricky part is not coming up with some packet formats. the tricky part is figureing out how to use local information that an attacker might now know, how to piggyback information about other peers in the lookups etc.
[21:31:20] <The_8472> i.e. interaction of encryption and the regular dht behavior
[21:31:26] <choykloun> yup
[21:31:43] <choykloun> but like i said
[21:31:50] <choykloun> need some common ground for lab stuff
[21:33:42] <The_8472> there is no DHT testbed. so we basically design things on the draftboard, do some basic simulations if necessary and then roll them out ^^
[21:34:02] <choykloun> depends on what you mean by testbed :P
[21:34:20] <choykloun> atleast i know that adding a pubkey field to ping reqs doesnt break existing impls
[21:34:24] <choykloun> but adding a large t field does
[21:34:48] <Switeck> How about getting DHT to work via proxy? XD
[21:34:54] <choykloun> udp via proxy
[21:35:00] <choykloun> not reaaally
[21:35:05] <choykloun> there is some sort of support in socks5 iirc
[21:35:16] <choykloun> get some nice souls to set up dht tcp->udp gateways maybe :P
[21:35:55] <Switeck> Unless you can hide all the little ip 'burps' inside a single ip stream, ISPs will no doubt DPI it to death no matter what encryption you're using.
[21:36:12] <Switeck> ISPs have already proved they don't care what they step on if they want to reduce file sharing.
[21:36:21] <choykloun> ive made interactive traffic look like http before :p
[21:36:46] <choykloun> so DHT-over-anything is a good future project
[21:36:48] <Switeck> Most of the time, they won't even admit to disrupting
[21:37:04] <choykloun> heh yah
[21:37:11] <Switeck> DHT-over-anything avoids more complex DHT encryption
[21:37:19] <choykloun> luckily i know everyone at my isp :p
[21:37:30] <choykloun> well its a compliment
[21:37:53] <The_8472> i suggest not working on making the traffic unidentifiable. just preventing manipulation and passive eavesdropping should do the job.
[21:37:58] <Switeck> I almost called enough to get the same tech support person more than once... (on ComCast)
[21:38:03] <choykloun> the_8472: kinda goes hand-in-hand
[21:38:11] <choykloun> if you cant detect it you cant manipulate it
[21:38:31] <choykloun> and basically you can do two things to prevent manipulation (of the KEX, such as mitm or disabling it altogether):
[21:38:38] <choykloun> 1. increasing computational expense
[21:38:46] <choykloun> 2. use signed KEX
[21:38:48] <Switeck> if you don't know how current detection is done, hiding could prove difficult.
[21:39:02] <choykloun> i know how its done
[21:39:11] <choykloun> i know the guys building the boxes that does precisely that
[21:39:25] <choykloun> in fact i was offered a job doing lowlevel hardware stuff there :p
[21:39:53] <choykloun> since WINK WINK nowadays people have forgotten how to write real code in ASM and just use java and similar hodgepodges WINK WINK :D
[21:40:32] <Switeck> I read a lot about Sandvine...I'm aware of a couple competing DPI products
[21:40:45] <choykloun> packetlogic is neat
[21:40:49] <Switeck> At least 1 is out of Israel.
[21:41:09] <choykloun> at least its not as bad as in the telco market
[21:41:10] <Switeck> But those are hardware devices, not a bordermanager software
[21:41:37] <choykloun> you know that AXE (probably the most common PTSN switch) has a nice point-and-click interface for call interception right :D
[21:42:35] <Switeck> managed switch
[21:42:48] <choykloun> Interception Management System
[21:42:52] <choykloun> client runs on solaris cde
[21:43:23] <The_8472> i know can code asm, i just don't want to. the required verbosity keeps you from doing real work
[21:43:25] <choykloun> the day PL starts supporting DHT interception i can get all the details about it
[21:43:52] <choykloun> the_8472: so let me test you :) which code is faster on a modern cpu:
[21:43:59] <choykloun> decl %ecx
[21:44:01] <choykloun> jnz 1b
[21:44:02] <choykloun> or
[21:44:03] <choykloun> loop 1b
[21:44:28] <choykloun> and which of
[21:44:31] <choykloun> 1:
[21:44:36] <choykloun> movl (%esi),%eax
[21:44:42] <choykloun> movl %eax,(%edi)
[21:44:50] <choykloun> addl $4,%esi
[21:44:52] <choykloun> addl $4,%edi
[21:44:57] <choykloun> subl $4,%ecx
[21:44:58] <choykloun> jnz 1b
[21:45:01] <choykloun> or
[21:45:06] <choykloun> rep movsl
[21:45:12] <choykloun> :)
[21:45:21] <The_8472> lo, that has nothing to do with coding assembler. that's memorizing instruction overhead tables. it's even more menial work.
[21:45:44] *** _rafi2_ has joined #bittorrent
[21:45:54] <choykloun> no its a fundamental part
[21:45:58] <choykloun> :P
[21:46:15] <choykloun> and you can answer both by knowing how a modern cpu operates :P
[21:46:26] 
[21:46:39] <choykloun> i do both
[21:46:51] *** _rafi_ has quit IRC
[21:46:51] <choykloun> but optimizing asm for modern cpus is rarely worth effort
[21:47:00] <choykloun> unless you have a special app where you need to optimize for size etc
[21:47:04] <The_8472> exactly
[21:47:09] <choykloun> i once spent 1 full day optimizing jenkins hash
[21:47:24] <choykloun> following everything in the current intel optimization guides, the official
[21:47:45] <choykloun> and eventually i managed to save 2 ticks per iteration over gcc -O3
[21:47:46] <choykloun> !
[21:48:00] <The_8472> waste of time if you ask me, unless your app is reaaaaally heavy on string-keyed hashtables
[21:48:57] <choykloun> yes
[21:49:01] <choykloun> but its fun exercise
[21:49:16] <The_8472> my i7 rarely reaches 10% load. 1080p video decoding in x64 code... 5-11% load. i have to do brute numbercrunching, compiling or games at high details to actually wake it from its slumber.
[21:49:33] <The_8472> so, runtime complexity is far more of an issue than constant overhead
[21:49:45] <choykloun> quite often when doing vulndev/exploit work you havet o write size-optimized asm
[21:49:46] <K`Tetch> you need to try loading it then, I suggest running muon1 on it ;-)
[21:49:52] <choykloun> or asm with certain restrictions
[21:49:56] <choykloun> like no high bits
[21:50:40] <The_8472> K`Tetch, i toyed with eureqa a bit. it's fun ^^
[21:51:00] <choykloun> no high bits was fun :)
[21:51:14] <choykloun> having it search for and load the actual code from another place in mem where i could use high bits
[21:51:56] <choykloun> part of my favorite exploit... it has a single target "All vulnerable versions of [secret!], all x86 Linux and *BSD"
[21:52:06] <choykloun> 100% success rate on the first try
[21:53:10] <choykloun> so you se
[21:53:10] <choykloun> e
[21:53:13] <choykloun> it comes in handy
[21:53:17] <The_8472> bloom filter works, returns a inserted element estimate. intersections next
[21:53:36] <choykloun> cool
[21:53:42] <choykloun> hm
[21:53:54] <choykloun> maybe you can help me optimize the memory management in my esbuf lib
[21:54:31] <choykloun> usual advice is "malloc does it better than you" but i think there are some optimizations that can be made
[21:56:06] <choykloun> i have an idea of keeping track of the most commonly allocated and deallocated contexts and having them already set up the next time its allocated
[21:56:10] <choykloun> with some buffers already in place etc
[21:56:20] <The_8472> are the buffers pointers to memory locations or structures that contain pointers to memory locations?
[21:56:30] <choykloun> http://estoykh.com/opensource/esbuf/
[21:56:37] <choykloun> to answer your question, structures
[21:56:52] <choykloun> basically all manipulation is/should be done via the api
[21:57:54] <The_8472> hrrm, the question is... can they be moved?
[21:57:57] <choykloun> yes
[21:58:21] <choykloun> already are when the underlying memory is realloc()ed and such
[21:58:52] <The_8472> ok. are your buffers short-lived, long-lived or a mix of both?
[21:58:55] *** Waldorf has joined #bittorrent
[21:59:02] <choykloun> mix
[21:59:11] <choykloun> let me explain the concept
[21:59:17] <The_8472> that calls for generational allocation
[21:59:20] <choykloun> you dont just allocate a buffer out of nowhere
[21:59:26] <choykloun> every buffer belongs to a ctx
[21:59:49] <choykloun> and for example all bufs used in a function might be in one ctx that's freed on return
[22:00:05] <choykloun> all used by a specific client might be in one thats freed when the client disconnects
[22:00:11] <choykloun> or some might be global/permanent
[22:00:12] <choykloun> etc
[22:00:43] <choykloun> provides extremely smooth memory mgmt
[22:00:52] <choykloun> and leak hunting on the rare occasion it occurs
[22:00:55] <The_8472> so you can basically kill the context and it kills all assocaited buffers?
[22:01:05] <choykloun> exactly
[22:01:11] <choykloun> you never free the bufs directly
[22:01:19] <choykloun> well i guess there is some func to do it but i never do
[22:02:50] <The_8472> well, in that case you can allocate short-lived contexts simply out of a pre-allocated block of memory by bumping a pointer atomically. once the context expires you can reuse the region from 0
[22:03:24] <The_8472> if the region overflows you move everything to regular malloc since it'll live longer than expected
[22:03:31] <choykloun> the ctx itself isnt a block of memory though
[22:03:36] <choykloun> its just a linked list of the bufs
[22:03:52] <The_8472> yes, but allocating within the context can be done this way
[22:03:53] <choykloun> but i could add some logic that tries to merge the bufs in memory
[22:04:22] <choykloun> was thinking of keeping much of the ctx in place
[22:04:36] <choykloun> so when the same buffer is allocated again it just gets it straight from there
[22:04:41] <choykloun> or one of a matching size
[22:04:57] <The_8472> well, you should look into the generational part of the java garbage collector. young/old generations seem appropriate to your scenario, especially since you can move them
[22:05:03] <choykloun> i do some padding so sizes tend to align up nicely
[22:05:09] <choykloun> i dont do GC
[22:05:13] <choykloun> and i never will :P
[22:05:19] <The_8472> i didn't say you should
[22:05:41] <The_8472> but freeing on killing the context is close enough to a garbage collection to apply the concept of generational allocation
[22:05:47] <choykloun> ah k
[22:05:51] <choykloun> yeah
[22:05:56] <choykloun> its goal is kinda to achieve the same thing
[22:05:58] <choykloun> but with full control
[22:07:55] <The_8472> the basic idea is that nothing is cheaper than bumping a pointer and that most things are short-lived. so you pre-allocate a relatively large chunk of continous memory and just "allocate" individual buffers by bumping the pointer within that chunk
[22:08:10] <choykloun> ya i do that within the buffers themselves
[22:08:20] <choykloun> you give a hint of how big it will be when you allocate
[22:08:35] <The_8472> oh, buffers are variable-size?
[22:08:39] <choykloun> yeah
[22:08:45] <choykloun> thats one of the other points
[22:08:47] <choykloun> dynamic memory mgmt
[22:08:48] <The_8472> ok, that complicates things significantly
[22:09:00] <choykloun> esbuf_sprintf(foo, "%s%u", bar, blutti);
[22:09:18] <choykloun> esbuf_appendf(foo, "%s", sabbay);
[22:09:39] <choykloun> not really since if we focus on the most common case of ctx alloc/dealloc, functions
[22:09:49] <choykloun> they will often end up being the same size each call
[22:11:45] <The_8472> read http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#1.1.%20Generations|outline
[22:11:48] <The_8472> might give you an idea
[22:12:21] <choykloun> esbuf solves a lot of classic C memory mgmt issues
[22:12:24] <choykloun> and string issues
[22:12:28] <choykloun> standard libc is just plain awful
[22:12:39] <choykloun> both for ease of use, prevention of leaks, and security
[22:12:42] <The_8472> there i agree ^^
[22:12:47] <choykloun> esbuf is tinfoil-hat level when it comes to security
[22:13:43] <choykloun> it uses one optional function pointer for a debug info callback to the application
[22:13:58] <choykloun> and function pointers are often very very handy when exploiting stuff
[22:14:00] <choykloun> so guess what i do
[22:14:12] <choykloun> i map a dedicated page for it
[22:14:14] <choykloun> read-only
[22:14:36] <choykloun> and check out the randomized magic :>
[22:14:53] <choykloun> a lot of it is aimed at preventing a bug not related to esbuf from being leveraged by it
[22:15:15] <choykloun> since as long as you stick to the provided functions/macros, the worst thing that can happen is that it commits suicide
[22:15:47] <choykloun> anyways
[22:16:01] <choykloun> n Log: Storing node (nodeid 0x6a636867, from 127.0.0.1:4242)
[22:16:01] <choykloun> got pubkey25519 in ping response
[22:16:01] <choykloun> dht_crypto_peer_add(127.0.0.1, 4242)
[22:16:01] <choykloun> found at idx 418587
[22:16:01] <choykloun> dht_crypto_peer_entry_agree(0xc29357c) state 1
[22:16:05] <choykloun> A9 C3 9A 9B 35 1C 75 2A EA 25 2C 64 3D 3C 82 7B 48 4B E5 7C 93 0B 1B 02 ....5.u*.%,d=<.{HK.|....
[22:16:09] <choykloun> 4D 01 4A 83 54 B8 6B 46 M.J.T.kF
[22:16:11] <choykloun> client doing dht announce
[22:16:14] <choykloun> client doing dht announce
[22:16:16] <choykloun> client doing dht announce
[22:16:20] <choykloun> jchgout starting to feel a bit lonely
[22:16:22] <The_8472> spam...
[22:16:33] <choykloun> i mean, it can talk to a lot of others, but not in its preferred language !
[22:16:40] <choykloun> nah not when theres 2 ppl active in the chan
[22:16:53] <The_8472> deploy some more of your own nodes in your lan ^^
[22:16:56] <choykloun> ya
[22:17:02] <The_8472> or even on the same host under different ports
[22:17:03] <choykloun> unfortunately i only have my laptop here
[22:17:11] <choykloun> well i guess the company dev server is another node
[22:17:17] <choykloun> ya
[22:17:20] <choykloun> i do that currently
[22:17:31] <The_8472> multiple IPs on a network card + multiple ports = gazillion of nodes!
[22:17:31] <choykloun> ports are hardcoded (ehm) but i use two different make lines
[22:17:38] <choykloun> well i have my own /24
[22:17:50] <choykloun> i can play over the real internet!
[22:19:00] <choykloun> so lets see here
[22:19:01] <choykloun> what do i have
[22:19:10] <choykloun> 1 box at office behind nat but with vpn
[22:19:12] <choykloun> 1 box in SE
[22:19:25] <choykloun> maybe alarm company doesnt mind me using a lab box for non-alarm lab
[22:23:14] <choykloun> and oh
[22:23:20] <choykloun> i have like 4 soekris embedded boxes lying around
[22:35:19] <choykloun> hm
[22:35:21] <choykloun> Sat Dec 26 03:41:44 CET 2009 Mysec: The appliance is in PRODUCTION mode.
[22:35:22] <choykloun> Sat Dec 26 03:41:44 CET 2009 Mysec: Started setmode
[22:35:22] <choykloun> Sat Dec 26 03:41:44 CET 2009 Mysec: Startup ended at Sat Dec 26 03:41:44 CET 2009
[22:35:25] <choykloun> MC 55 Alarm transmitter
[22:35:27] <choykloun> Mysec Sweden AB
[22:35:30] <choykloun> alarm transmitter
[22:35:36] <choykloun> thats almost the same thing as filesharing, right? :D
[22:35:52] <choykloun> would be hilarious if they shipped with BT software
[22:37:39] <choykloun> or even if there was traces of it in flash lol
[22:38:34] <choykloun> fuck i really need to get my sparcs shipped here
[22:38:48] *** Snoopotic has joined #bittorrent
[22:38:51] <choykloun> would be useful now.. they are horribly slow at normal DH/RSA
[22:39:25] <choykloun> my ss5-110 took like 3secs for a simple y=g^x mod p; z=y'^x mod p exchange
[22:41:07] <choykloun> hm does the nacl curve lib build on vms
[22:43:42] <The_8472> sounds like some horribly slow hardware
[22:43:50] <choykloun> its just slow on certain stuff
[22:43:53] <choykloun> like floating point
[22:44:25] <choykloun> on I/O it kicks the asses of PCs released as late as 2001-2002
[22:44:34] <The_8472> you don't need floating point to do calculte DH
[22:44:40] <The_8472> it's all bigint arithmetic
[22:44:46] <choykloun> no but floatng poiint and bignum
[22:44:53] <choykloun> i dont know the precise reason its slow on bignum actually
[22:45:14] <choykloun> and well its 110MHz
[22:45:27] <choykloun> but served me well as primary workstation 1998-2005 !
[22:45:41] *** _rafi_ has joined #bittorrent
[22:46:58] <choykloun> how slow is a 2048 bit DH op on a pentium 200MHz?
[22:47:12] *** _rafi2_ has quit IRC
[22:48:47] <choykloun> anyone wanna talk dht with me btw
[22:48:51] <choykloun> 88.80.20.41 port 4224
[22:51:33] <The_8472> aren't you maintaining a routing table?
[22:51:42] <choykloun> something resembling a routing table
[22:51:53] <choykloun> and these nodes are isolated from the rest of the world
[22:52:00] <The_8472> i see
[22:52:05] <choykloun> currenntly it does 1 thing
[22:52:14] <choykloun> find the closest nodes and announce an info_hash to them
[22:52:24] <The_8472> it doesn't respond to queries?
[22:52:28] <choykloun> yes it does
[22:52:40] <choykloun> or hm
[22:52:41] <choykloun> does it
[22:52:52] <choykloun> lemme check what ive commented out
[22:53:01] <The_8472> well, then they're not really isolated. because once you query external nodes they'll learn of your IP/Port and query you if they can use you
[22:53:08] <choykloun> ya it responds
[22:53:15] <choykloun> ya
[22:53:18] <choykloun> wouldnt cause any harm though
[22:53:32] <choykloun> i test it on real dht all the time
[22:54:22] <choykloun> but dht would probably cause a matter/antimatter explosion if everyone ran routing like this :P
[22:55:09] <The_8472> routing is not the issue. accurately maintaining your routing table and responding to queries is the important part
[22:55:19] <choykloun> it does
[22:55:26] <The_8472> unless you need hundreds of packets for every lookup
[22:55:51] <choykloun> but not effectively enough for reallife widespread use
[23:02:56] <choykloun> heh just realized i need to manage id's a bit better than a #define :PP
[23:03:07] <choykloun> will have it set at compile time instead perhaps :P
[23:12:00] *** DWKnight has quit IRC
[23:16:04] <choykloun> echo foo|awk '{ for (i = 1; i < 16 - length($1); i ++) printf("\\x%.2x", int(rand() * 255)); print $1 }'
[23:16:11] <choykloun> how to generate your very own nodeid in 1 line of awk!
[23:17:55] <choykloun> ok should be 20 :p
[23:19:25] <The_8472> byte[] id = new byte[20];new Random().nextBytes(id);
[23:19:54] <The_8472> 1 line of groovy!
[23:21:01] <choykloun> btw would ssh style hostkey auth / signed kex be worth pursuing at all
[23:23:56] <The_8472> what would you sign it with..
[23:24:06] <choykloun> problem is you dont know the nodeid before youve exchanged some packets
[23:24:10] <The_8472> that would mean we'd have to distribute pubkeys over other nodes
[23:24:12] <choykloun> just like ssh
[23:24:18] <choykloun> first time you see a new node you get his pubkey
[23:25:36] <choykloun> well hm you do kknow his nodeid from the response to the query which is the same time you get his pubkey and signature
[23:25:39] <choykloun> so it would be doable
[23:28:04] <The_8472> thinking of it. almost all points on the curve are useable, right?
[23:28:33] <choykloun> problem is that the nacl lib has no actual signing function
[23:28:53] <The_8472> hmac with the session key
[23:29:31] <choykloun> you need to sign the KEX pub value with your pubkey obviously
[23:29:47] <choykloun> but it has functions that do the same but they require both parties to ahve eachothers pubkeys
[23:30:49] <The_8472> how many bits do points on the curve have?
[23:30:57] <choykloun> 256
[23:31:04] <choykloun> http://cr.yp.to/ecdh.html
[23:31:26] <The_8472> hrrm, is there one with ~160 bits?
[23:31:27] <choykloun> The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys. Relevant lower-level facts: the number of points of this elliptic curve over the base field is 8 times the prime 2^252 + 27742317777372353535851937790883648493; the number of points of the twist is 4 times the prime 2^253 - 55484635554744707071703875581767296995
[23:31:42] <choykloun> i know what you are thinking :)
[23:31:57] <choykloun> and yes using nodeid or such would be very much possible
[23:32:01] <choykloun> just pad it
[23:32:04] <The_8472> no
[23:32:09] <The_8472> it would have to be the public key
[23:32:15] <The_8472> which is generated from the private key
[23:32:20] <choykloun> ah
[23:32:28] <choykloun> then no sorry
[23:32:28] <The_8472> that's the issue here
[23:32:44] <choykloun> but well
[23:32:58] <choykloun> you can use a 160 bit one and then just stick the values into 25519
[23:33:26] <The_8472> that doesn't work i think
[23:33:45] <choykloun> why not
[23:33:55] <choykloun> c25519 accepts any value as pub keys
[23:34:02] <The_8472> you would lack the appropriate private keys
[23:34:26] <choykloun> yeah you'd generate the pub key from the priv key using a 160 bit curve
[23:35:04] <The_8472> using wrong curve parameters with ECC makes things horribly insecure
[23:35:43] <choykloun> read the papers about curve25519
[23:35:48] <choykloun> like i said
[23:35:54] <choykloun> like it says*
[23:36:00] <choykloun> any value can be the public key
[23:36:16] <The_8472> hrrm
[23:36:20] <choykloun> but ii dont know ECC math
[23:36:23] <choykloun> ole good disc logs i can do
[23:37:51] <The_8472> <choykloun> any value can be the public key <- you don't pick public keys in DH, you pick a private one and generate the public value from it
[23:37:58] <choykloun> yes i know
[23:38:05] <choykloun> thats why i said you generate it using a 160 bit curve
[23:38:16] <choykloun> or well
[23:38:23] <choykloun> the secret key is also just a random value in 25519
[23:38:29] <choykloun> just with some restrictions
[23:38:39] <choykloun> h.
[23:38:43] <choykloun> Computing secret keys. Inside your program, to generate a 32-byte Curve25519 secret key, start by generating 32 secret random bytes from a cryptographically safe source: mysecret[0], mysecret[1], ..., mysecret[31]. Then do
[23:38:47] <choykloun> mysecret[0] &= 248; mysecret[31] &= 127; mysecret[31] |= 64;
[23:38:49] <choykloun> to create a 32-byte Curve25519 secret key mysecret[0], mysecret[1], ..., mysecret[31].
[23:39:06] <choykloun> shouldve thought of that first of all but nacl lib provides such convenient key gen functions :P
[23:39:37] <choykloun> hmm
[23:40:34] <choykloun> oh well
[23:40:44] <choykloun> not worth any effort to save a little traffic/space
[23:42:21] <The_8472> it's not about traffic. if node id = public key then you would already have 1 part of the exchange every time you contact a node
[23:42:34] <choykloun> ya exactly
[23:44:00] <choykloun> hm
[23:44:02] <choykloun> could do some hack here
[23:44:15] <choykloun> where a node is published as being 2 nodes
[23:44:27] <choykloun> you understand what i mean
[23:59:22] <choykloun> what happens with a normal client if you publish the same host:port with different nodeid
[23:59:29] <choykloun> or could publish the second with a hash of host:port
[23:59:47] <The_8472> wohoo, intersect works too :)





top