July 2018 - cypherpunks-legacy

Re: Photos of an FBI tracking device found by a suspect
by Steven Bellovin 06 Jul '18

06 Jul '18

On Oct 8, 2010, at 11:21 16AM, Perry E. Metzger wrote: > My question: if someone plants something in your car, isn't it your > property afterwards? > > http://gawker.com/5658671/dont-post-pictures-of-an-fbi-tracking-device-you-… See http://www.wired.com/threatlevel/2010/10/fbi-tracking-device/ for even more disturbing aspects of the story -- they operated by intimidation (to say nothing of apparent ethnic and religious profiling). --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Photos of an FBI tracking device found by a suspect
by Steven Bellovin 06 Jul '18

06 Jul '18

On Oct 8, 2010, at 11:21 16AM, Perry E. Metzger wrote: > My question: if someone plants something in your car, isn't it your > property afterwards? > > http://gawker.com/5658671/dont-post-pictures-of-an-fbi-tracking-device-you-… See http://www.wired.com/threatlevel/2010/10/fbi-tracking-device/ for even more disturbing aspects of the story -- they operated by intimidation (to say nothing of apparent ethnic and religious profiling). --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [liberationtech] Finfisher Spy Kit Revealed in Bahrain
by Fabio Pietrosanti (naif) 06 Jul '18

06 Jul '18

On 7/27/12 12:58 PM, Erich M. wrote: > On 07/26/2012 04:27 AM, Jacob Appelbaum wrote: >> The FinSpy network traffic is also really interesting - the fact that they don't stand up to the most > obvious of traffic analysis is *hilarious* and so fitting. All the best, > Jake > > That should be a necessary feature AND NOT a bug. Remember, this is the > "export" version of the malware. Quite like the "law enforcement" > versions all these derivatives lack one or two essential security > features that could have been implemented easily. How come? One guess > allowed. > > This malware crap is being produced for primary use by the "national > security agencies". They'd never let you [= malware producer] sell the > same intrusion suite to foreign agencies as well without some "necessary > adaptations". Let alone to clumsy cops and - moreover - in Mid East. "National Security Agencies" of which Nation? * Gamma Group have an origin in Germany. * Then moved all the companies to UK (offshore or real moving of busines?) * mail.gammagroup.com mailserver is in Beirut, Lebanon. So it's interesting that it's not very clear "where they are based". Also on Linkedin there is *not a single person* that worked for one of their group company. In any case as far as i know there's no "export version" of software like this, not like it is for "crypto" if it reside under dual-use wassenaar agreement. The trojan producer just differentiate the products based on their capabilities and feature, basing on that the pricing. I also know of companies that asked for export permission (of monitoring technologies) to national authorities (in italy) and just because it was "difficult to understand what it is", the authorities are not able to answer within 90days, and so it's "by default allowed" . As an additional fun conspiracy theory, at 4.1km from their Munich office there is SecurStar GmbH that in 2006 developed a mobile trojan: http://pastebin.com/caxxuNe8 -naif _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[serval-project-dev] Implementing a different routing protocol
by Fraser Cadger 06 Jul '18

06 Jul '18

Hi all, First of all, let me start by stating that I am very impressed with the work of the Serval Project and the Serval app. I appreciate that it is still under development, but having experimented on several Android phones I have found it really easy to use and effective. My name is Fraser Cadger and I am a third year PhD student at the University of Ulster in Northern Ireland. My project is concerned with developing a framework to allow the streaming of multimedia content both live (i.e. video call) and on-demand (recorded videos) in disaster recovery scenarios using a mesh network of WiFi-enabled devices (currently this entails a testbed of six Android phones). As I am working with Android devices this obviously adds a layer of difficult when trying to implement ad-hoc networking. After doing some searching I came across several different implementations of ad-hoc routing on Android, and after some experimentation the two I was most interested in were Serval and Commotion (who I believe the Serval Project collaborates with). In the end I decided to work with the Serval app because I felt that was the closest to what I was doing, and I also liked how it worked on the phones. Currently what I am interested in doing is implementing my own routing protocol (which is still under development) on the phones using Serval as a base. That is to say, that I want to replace the modified BATMAN code Serval uses for routing with the current version of my routing algorithm (originally written in C++ for ns-2 but re-writing in C should not be a huge problem). Obviously I realise this will not be a simple as copying and pasting my code in and that is why I am sending this message. From reading various comments in the code I understand that one of the main modifications to Serval is to restrict broadcasting to link-local nodes (i.e. not network-wide broadcasting), if I have understand the code correctly that is. The protocol I am developing is a variation of the greedy routing protocol GPSR http://www0.cs.ucl.ac.uk/staff/b.karp/gpsr/gpsr.html . Both the original GPSR and my own protocol use limited broadcasting as well; beacon (regular hello messages) are broadcast as far as one hop and nodes maintain tables of neighbours who can be reached directly only. There is no conventional collection of routes; instead each node forwards a packet to their neighbour who best meets the criterion/criteria (generally geographic location, i.e. located closest to the destination) one hop at a time. So packets are effectively passed from node to node without a formal route existing. This version of geographic routing is not perfect, and that is why we are working on several modifications, but for now I am content to have some form of working geographic routing up and running. I have been reading through the code and trying to determine what parts I need to change and where to add my code. What I am looking for is the point at which a node determines where to send a packet. I realise that this will vary depending on the packet's origin, that is to say that when a node generates a new packet it will usually be treated differently from when an intermediate node receives a packet from another node. Now, if I understand correctly Serval's version of BATMAN does not use an explicit routing table structure. I have came across a struct called subscriber defined in overlay_address.h, and from what I have read this seems to act as a record of different nodes (destinations). Within the subscriber struct there is an integer variable called reachable and this determines whether a node is reachable directly via unicast, broadcast, or must be reached indirectly. If a node must be reached indirectly then there is a field called next_hop which if I understand correctly is a pointer to another struct (the intermediate node between ourselves and the destination). Is this correct? Now, what I have noticed in the code is that sometimes next_hop contains a pointer to another next_hop (i.e. next_hop->next_hop). What I'm guessing this means is that if there are multiple intermediate nodes (i.e. to send a packet to node D node A needs to send it via B and C), then this is a way of linking them as a route. So in essence, the subscriber struct contains the route to a destination (by way of the next_hop attribute). For the actual routing, from reading the code I'm guessing that the 'overlay_route_recalc_node_metrics' function is used to determine whether a destination can be reached directly or indirectly, and if indirectly it will then assign the appropriate intermediate nodes as next_hop's. Therefore, to create or change a route this function is called. Is this correct? In my case, I would like to do things slightly differently. As I am not doing end-to-end routing I do not need a list of destinations, instead all I want is a list of 1-hop neighbours who can be accessed directly. Then from that list I would determine which of these is the most suitable as the next hop (obviously in my case this will require other stuff, for instance adding GPS coordinates to the packet header and storing this in the subscriber field) and forward the packet to that node, and so on until the packet has been delivered (or has to be dropped). The main questions I have are: - Exactly where is a packet received and the node to which it should be sent decided? - i.e. if I want to decide which node to forward a packet to where should I decide this? - I came across a method called 'overlay_mdp_receive' in mdp_client.c, is this maybe what I'm looking for? - Concerning the subscriber entity, is there an actual table/list/array of these b as I can't seem to find one? - i.e. a list of neighbours/known nodes/destinations? I apologise if my questions and this email aren't very well-worded. Essentially what I'm looking for is some advice/guidance on exactly how routing (determining intermediate nodes for nodes which cannot be reached directly) and forwarding (looking at a received/originated packet and determining which node to send it to) is done. As I indicated earlier in this message, there are a few functions/structs I have stumbled across that I think are relevant and I have made some guesses at what they are doing, so I would appreciate if someone could correct/expand on my guesses. Any help/guidance I have would be greatly appreciated. It goes without saying that any code I develop myself I will happily share, and any issues/bugs I come across with Serval will be reported. Thank you for taking the time to read this message, I'm sorry it's a bit on the long side but hopefully I've made myself clear. Regards, Fraser Ps. I realise this topic has been covered before, but I think some of the questions I am asking in this message are new. -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/serval-project-developers/-/MgHT2-tr_dcJ. To post to this group, send email to serval-project-developers(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Some notes toward a fully distributed, serverless socnet/communications network using CouchDB.
by Bryce Lynch 06 Jul '18

06 Jul '18

More notes. I do my best thinking when I'm stuck in traffic, it seems. Again, this will need discussion, and at this point with people who've built CouchApps and can actually speak to how they do or do not work, and under what circumstances. I'm also probably missing some important stuff. ----- problem: addressing practically everybody is behind at least one NATting firewall these days IP addresses are dynamic, so you can't count on a buddy being reachable at the same IP for very long having the Network25 app post its current IP address somewhere (a field on a blog, to a mailing list, Tweet) or get a dynamic DNS hostname every time isn't really workable. in fact, it outs the user in obvious ways, and not everyone is okay with that another problem: Port forwarding. there are some solutions to this, but not all of them work well, work at all, or are suitable. multiple layers of NAT make this solution suck. solution used by TorChat, which would probably work for us: Tor hidden service addresses TorChat creates a unique hidden service address for you when you set it up. when you add people to your buddy list, it stores <public key>.onion in the list, and it's up to you to set an alias ("qwertyuiopasdfgh.onion" == "Bryce A. Lynch") on it Network25 should be able to do the same thing the Zero State is talking about using Tor for general communications in the future, anyway, this would be a perfect time to start When the Network25 socnet software starts up, it looks to see if Tor is running, if it has any hidden services configured, and if any of those services correspond to a unique port that Network25 uses shell/batch scripts FTW if not found, it tells the Tor daemon to create a hidden service descriptor, copies the public key/.onion hostname into the user's Network25 profile, and announces it to that person's friends so they know where to find zir and can start synching databases the name of the hidden service is then added to a field in your profile document, so when people friend you on the network they know how to reach you: public profile document (gets replicated) { _id: "Bryce A. Lynch", _interests: ["long walks on the beach", "moonlit nights", "massively distributed systems", "tor", "writing stuff about CouchApps in Tomboy"], _friends: ["friend", "friend", ...], _publickey: "<public key>", _toraddress: "qwertyuiopasdfgh.onion", ... } this means that CouchDB (configured to use Tor rather than IP address/ports combos) knows how to reach your copy of the socnet software and sync its copies of users' databases (profile, timeline, forums/communities/mailing lists/distribution lists/news feeds) this also helps authenticate users, in the same way that hidden services are authenticated (there is a corresponding private key which is never shared by Tor). if the public key (.onion) and private key (on your box) don't match, then the service isn't trusted because database creation in CouchDB is cheap, there is no reason why there can't be multiple databases in every user's profile b" user profile b" shared public forum (anologous to the Doctrine Zero mailing list) b" specific forums (public or not) (anologous to zs-p2p, zs-arg mailing lists) b" personal blog b" blogs specific to the projects the user is working on (which themselves can have multiple people posting to them, because they're distributed) b" private blogs/chat forums for specific people b" blog/news feed/private messages from everyone the user has friended in Network25 b database: amon_zero_public_feed b database: amon_zero_private_messages b database: amon_zero_philosophical_pontification b database: bryce_a_lynch_public_feed b database: bryce_a_lynch_project_byzantium b database: bryce_a_lynch_3d_printing b database: bryce_a_lynch_private_messages b database: zs_med_discussion b database: zs_arg_plot restricted databases are only replicated by members that are part of that project or group a list of authorized users and their corresponding public keys are part of the database for every forum a majority of people in a private forum have to vote to include that person? all messages are encrypted to the public keys of everyone authorized to participate in that form/replicate that database private databases are only replicated by people they're shared with, i.e., a personal chat feed for one other person is only in two places in the Network25 socnet, your machine and theirs consider making private databases purgeable, i.e., either or both people can have their copy of the socnet software dump the database so that there is no record of the discussion on either side this is where PKE or OTR would come into play - even if the database were recovered somehow, it should be difficult for the attacker to figure out what the cyphertext is I don't know how easy, or how safe implementing crypto at the level of a CouchApp is. all of us are going to have running copies of the Tor Browser Bundle, and all of us are going to have copies of the CouchDB stack and Network25 app, so it would be possible to use a crypto.cat-like plugin for the TBB which implements the encryption/decryption/acquisition of a buddy's public key/addition of key to the user's profile database how much disk space will this take up? I don't know yet. will CouchDB contact other nodes over Tor? I don't know yet. have to test it out. encryption/decryption of data before it enters/leaves the CouchApp? good question. I don't have enough experience yet with CouchApps to say, but would love to talk to someone who does -- The Doctor [412/724/301/703] [ZS (MED)] https://drwho.virtadpt.net/ "I am everywhere." -- You received this message because you are subscribed to the Google Groups "ZS-P2P" group. To post to this group, send email to zs-p2p(a)googlegroups.com. To unsubscribe from this group, send email to zs-p2p+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [Pigdog] Nation sees 50% rise in unfathomable headlines.
by xtrakt 06 Jul '18

06 Jul '18

On Wed, Jun 17, 2009 at 07:58:00AM -0700, jeremiah wrote: > Then, as dissent really becomes important, you'll find the tools have > been supressed and your messages criminalized. You will soon watch your > precious Itarwebz go the way of Burma or Iran. And don't try to leave! > All the new 'border security' will be doing the job of keeping you IN. Communicating in the Resistance: Lessons Learned From the Battlefield http://www.lewrockwell.com/gaddy/gaddy61.1.html > Pigdog will become REAL samizdat, again. I predict a revival of > FIDO-style relays, and maybe even scanning the back pages of Computer > Currents - for an interestingly subversive listing... This was one of the better forums, but it was slim pickings: The Mental Militia Forums: Gulchnet ramp up http://tinyurl.com/lwld9a We really need to get started on this FIDONet revival soon. Um, I've got a few external 56 modems lying around... _______________________________________________ Pigdog mailing list Pigdog(a)lists.pigdog.org http://lists.pigdog.org/listinfo.cgi/pigdog-pigdog.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Certicom? [...] [Fwd: NSA Turns To Commercial Software For Encryption]
by harley＠argote.ch 06 Jul '18

06 Jul '18

>Besides 4K-RSA + AES-256 + SHA-256 are all way way way stronger [...] Amusing that you choose 4K-bit RSA. Wasn't 2K supposedly to be total overkill recently? Actually wasn't 1K supposed to be overkill not long ago? Heck 768 seemed extravagant when everyone was on 512. A mere 15 years ago, 320 bits was thought to be enough. According to my logs, here are the > 320-bit factorisations that I ran today: 572972811505140538587970948254484718069 * 229535232834749685352787191218483748328512852024528924422553 31051130972407042496629431420168004379 * 22580614860205576513432855281188300547296895576002618168141213 1651123615682793488297475146389977666821 * 431607931720940152250713570720678507192603271368450344325511 876748124621739787801748776119951008903 * 625940962036087307316308134093495176626898913441644936896711 A mere 15 years ago, 160-ish bits was thought to be enough for ECC. Strangely, that's about 50 million times harder than the biggest cases of ECC broken to date. R PS: Oops, another one while I was typing: 4177340769425990287179093985822571 * 40278974418865128339952649479779348554858008977767026467354360871 .-. .-. / \ .-. .-. / \ / \ / \ .-. _ .-. / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / `-' `-' \ / \ / \ \ / `-' `-' \ / `-' `-' _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 0.97c removed an attachment of type application/pgp-signature]

1 0

Re: [Pigdog] Nation sees 50% rise in unfathomable headlines.
by xtrakt 06 Jul '18

06 Jul '18

On Wed, Jun 17, 2009 at 07:58:00AM -0700, jeremiah wrote: > Then, as dissent really becomes important, you'll find the tools have > been supressed and your messages criminalized. You will soon watch your > precious Itarwebz go the way of Burma or Iran. And don't try to leave! > All the new 'border security' will be doing the job of keeping you IN. Communicating in the Resistance: Lessons Learned From the Battlefield http://www.lewrockwell.com/gaddy/gaddy61.1.html > Pigdog will become REAL samizdat, again. I predict a revival of > FIDO-style relays, and maybe even scanning the back pages of Computer > Currents - for an interestingly subversive listing... This was one of the better forums, but it was slim pickings: The Mental Militia Forums: Gulchnet ramp up http://tinyurl.com/lwld9a We really need to get started on this FIDONet revival soon. Um, I've got a few external 56 modems lying around... _______________________________________________ Pigdog mailing list Pigdog(a)lists.pigdog.org http://lists.pigdog.org/listinfo.cgi/pigdog-pigdog.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [tahoe-dev] Resurrecting Mojo Nation
by Tony Arcieri 06 Jul '18

06 Jul '18

If you're interested in the ideas of MojoNation you might check out my project the Cryptosphere: https://github.com/tarcieri/cryptosphere On Sat, Jun 9, 2012 at 9:07 PM, Jack Byer <ftn768(a)gmail.com> wrote: > Recently on the Bitcoin forums the idea came up to form a digital > currency-based filesharing network and that thread > (https://bitcointalk.org/index.php?topic=86384.0) reminded me of MN, > leading to a discussion of whether or not it would be practical to > bring back the idea of a market-based computing resource allocation. I'm shooting for a barter economy instead of a digital currency. -- Tony Arcieri _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Certicom? [...] [Fwd: NSA Turns To Commercial Software For Encryption]
by harley＠argote.ch 06 Jul '18

06 Jul '18

>Besides 4K-RSA + AES-256 + SHA-256 are all way way way stronger [...] Amusing that you choose 4K-bit RSA. Wasn't 2K supposedly to be total overkill recently? Actually wasn't 1K supposed to be overkill not long ago? Heck 768 seemed extravagant when everyone was on 512. A mere 15 years ago, 320 bits was thought to be enough. According to my logs, here are the > 320-bit factorisations that I ran today: 572972811505140538587970948254484718069 * 229535232834749685352787191218483748328512852024528924422553 31051130972407042496629431420168004379 * 22580614860205576513432855281188300547296895576002618168141213 1651123615682793488297475146389977666821 * 431607931720940152250713570720678507192603271368450344325511 876748124621739787801748776119951008903 * 625940962036087307316308134093495176626898913441644936896711 A mere 15 years ago, 160-ish bits was thought to be enough for ECC. Strangely, that's about 50 million times harder than the biggest cases of ECC broken to date. R PS: Oops, another one while I was typing: 4177340769425990287179093985822571 * 40278974418865128339952649479779348554858008977767026467354360871 .-. .-. / \ .-. .-. / \ / \ / \ .-. _ .-. / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / `-' `-' \ / \ / \ \ / `-' `-' \ / `-' `-' _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 0.97c removed an attachment of type application/pgp-signature]

1 0