- cypherpunks - lists.cpunks.org

Subquantum Crypto Attack
by John Young 26 Jul '13

26 Jul '13

Has subquantum crypto attack been substantiated? arXiv:quant-ph/0203049v2 12 Apr 2002 Subquantum Information and Computation Antony Valentini It is argued that immense physical resources for nonlocal communication, espionage, and exponentially-fast computation are hidden from us by quantum noise, and that this noise is not fundamental but merely a property of an equilibrium state in which the universe happens to be at the present time. It is suggested that non-quantum or nonequilibrium matter might exist today in the form of relic particles from the early universe. We describe how such matter could be detected and put to practical use. Nonequilibrium matter could be used to send instantaneous signals, to violate the uncertainty principle, to distinguish non-orthogonal quantum states without disturbing them, to eavesdrop on quantum key distribution, and to outpace quantum computation (solving NP-complete problems in polynomial time). ... 6 Eavesdropping on Quantum Key Distribution Alice and Bob want to share a secret sequence of bits that will be used as a key for cryptography. During distribution of the key between them, they must be able to detect any eavesdropping by Eve. Three protocols for quantum key distribution BB84 [20], B92 [21], and E91 (or EPR) [22] are known to be secure against classical or quantum attacks (that is, against eavesdropping based on classical or quantum physics) [23]. But these protocols are not secure against a subquantum attack [7]. ... E91 is particularly interesting for it relies on the completeness of quantum theory that is, on the assumption that there are no hidden elements of reality. Pairs of spin-1/2 particles in the singlet state are shared by Alice and Bob, who perform spin measurements along random axes. For coincident axes the same bit sequence is generated at each wing, by apparently random quantum outcomes. The eavesdropper cannot elicit any information from the particles while in transit ..... because there is no information encoded there [22]. But our Eve has access to information outside the domain of quantum theory. She can measure the particle positions while in transit, without disturbing the wavefunction, and so predict the outcomes of spin measurements at the two wings (for the publicly announced axes).12 Thus Eve is able to predict the key shared by Alice and Bob.

1 0

Re: [liberationtech] CJDNS hype
by Eugen Leitl 25 Jul '13

25 Jul '13

----- Forwarded message from Caleb James DeLisle <calebdelisle(a)lavabit.com> ----- Date: Thu, 25 Jul 2013 23:58:34 +0300 From: Caleb James DeLisle <calebdelisle(a)lavabit.com> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] CJDNS hype User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, Sorry for the wait on my part as well, I was very busy last week. On 07/24/2013 05:27 AM, Michael Rogers wrote: > Hi Caleb, > > Thanks for the detailed answers - I'm sorry it's taken me so long to reply. > > - From your answers and the whitepaper I think I'm starting to understand how the switching and routing layers fit together. Would I be right in thinking that each node populates its DHT routing table with nodes that are one or more hops away at the switching layer, and that each hop at the switching layer is a link between two people who know each other? So two nodes that are neighbours at the DHT layer are't necessarily neighbours at the switching/social layer? Exactly. There is no real concept of "neighbors" at the DHT layer but there is address space distance so some nodes are "close". > > And if there's more than one candidate for a slot in the DHT routing table, am I right in thinking that some weighted combination of DHT ping time and label length is used to pick the best candidate, where label length is a combination of path length (at the switching layer) and the degree of the nodes along the path (with short paths and low-degree nodes resulting in shorter labels)? Yup. > >>> More generally, could you explain how CJDNS detects and routes around faults? > >> The simple version is that it pings at random nodes in it's table. When a node is unresponsive, it and anyone who is behind it is dropped from the table. > > A few questions about pings: > > Is it possible for a node that's being pinged to distinguish a ping from a data packet? (What would happen if a node responded correctly to pings but dropped data packets?) Yes, the destination of the ping does know that it's a ping since it needs to respond to it. If it dropped non-pings it would be unreachable and if it dropped layer3 "forward me" messages then it would break the network. > > Can a node on the switching path between the pinger and the pingee distinguish a ping from a data packet? Only by guessing based on size and timing. > > Can a node on the switching path between the pinger and the pingee respond to a ping on the pingee's behalf? Never ever. That's critical to the model that when you are told about a node that you don't trust that it's real until you're sure that you've talked to it. > >>> Could you explain what a route prefix is and how you can be sure that a set of Sybil identities will share a route prefix? How is the route prefix used in detecting and routing around faults? > >> This requires understanding the base method by which cjdns works. When I start up my router, I connect to my specified peers which I have manually configured, these are people whom I know well enough to be assured that they are honest peers. > >> Then my node's switch core assigns each one an interface index. My node then compresses the interface indexes of it's neighbors into a label and inserts the entries with key and label into it's routing table. > >> My node randomly asks nodes in it's routing table for pieces of their table, the question could be simplified as "who do you know, how do you reach them", the response from them is entries taken directly from their routing table. > >> When Alice tells me that she knows Bob and his label is 12345, I take Alice's label which might be abcd and splice them together to have a label which routes from me to Alice to Bob, then after Bob has been pinged along this path, I begin to trust it. > >> This is all an oversimplification, for the actual way it works please consult the whitepaper. > > Thanks, that's a really helpful explanation. So it seems to me that you're using the same observation as SybilGuard and similar systems: although the number of Sybils is unlimited, the number of social edges between Sybils and non-Sybils is limited, so those edges can be used to limit the impact of Sybils. > > It's a cool observation, but the devil's in the details - how do you actually apply that observation in practice? Is there some algorithm in cjdns that detects anomalous routing table entries by examining the prefixes of their switching labels? Other than short paths (labels) being preferred, there are only a few tricks aimed specifically at accidental problems. If I discover route a->b->c->d->w->x->y->z->d then I discover a->b->c->d I will replace the first with the second since I can prove that the first is an indirect representation of the second. There are no specific defenses against sybil attacks but I don't think any are needed given the fact that it's inherently different from a traditional overlay network. > >>> Could you explain why a set of Sybil identities will produce an absurdly long path, and how you can be sure that the routing table has already been populated with fast non-Sybil nodes? > >> Re the absurd length of paths, since more nodes mean more interface indexes, it stands to reason that the more interface indexes will make a longer label. Long labels are avoided by cjdns. > > Bear in mind that Sybils don't have to exist simultaneously. For example, Alice could tell me that she has one neighbour other than me, Bob. I add Bob to my routing table, but later I detect that he's not routing packets correctly, so I drop him. Then Alice tells me that Bob's no longer her neighbour but she has a new neighbour, Carol. I add Carol to my routing table, but later I detect that she's not routing packets correctly, so I drop her. Then Alice tells me that Carol's no longer her > neighbour but she has a new neighbour, Dave... > > At any given time, Alice only has two interfaces, so my labels for Bob, Carol, Dave, etc will be short. > > Obviously this is just a toy example, but it shows that in the general case a Sybil attack doesn't necessarily produce long labels. That's a valid point. We tried to avoid trapping bad behavior and dropping a node because in my opinion it is too brittle and is more likely to introduce a vulnerability. Rather than trust early and detect known bad behavior, cjdns is slow to trust. If you tell me about a new node I will generally not use it until the node I'm currently using fails. This hurts performance but helps stability once the network is functional. > >>> It sounds like you're saying that a Sybil attack won't work because the victims have already populated their routing tables prior to the attack - but what about a new node joining the network after the attack has started? > >> Unless your direct peers (with whom you have a relationship) are sybil nodes, they will keep their tables clean and when you ask them for nodes, they will give you honest nodes whom also have clean tables. You will see a few sybil nodes in your table but they will also come with many valid nodes which will cause the router to slow down it's search for nodes, curtailing their effort to pollute the routing table > > I think I need more detail to understand how this works. I receive routing information from my peers, who receive it from their own peers, etc. Each node is supposed to keep its table clean in order to share clean information with its peers - how does it do that? What operations are performed to clean the information before sharing it with peers? When I receive information from my peers, how do I know whether it's clean? I'm on very unstable ground here, possibly bullshitting... None of this has been simulated so I have to tread carefully. Basically each route has a "value", when a node is inserted, the route to that node has a value of 0, valid ping responses increment the number and timeouts halve it. High numbers and short paths are favored but even a long path is favored over a "0 value route". When you ask a node for routes, it will give you routes which are either: 1. A perfect match to the ip address you queries (even if 0 reach) 2. The highest reach node which is closet to the query target than them. (them == the node to whom you sent the query) Since cjdns populates it's table by periodically querying randomly generated ip addresses, nodes share their best paths causing a sort of "wisdom of the crowd" effect and making it difficult for a sybil attack to gain traction. > >>> Nevertheless, a node could selectively drop traffic bound for certain recursive routing hops, while forwarding other traffic, right? > >> Yes but each node is a recursive router and you're allowed to forward to any router whose address is numerically closer to the destination than your own so if someone is blocking a router, there are many others to choose from. > >> Granted we don't have any tools for detecting that a recursive router is misbehaving and blacklist it but this is an implementation cat-and-mouse game which the protocol will support. > > What mechanism in the protocol would make it possible for future implementations to detect misbehaving nodes? We would have to make some small protocol changes to make this work but what immediately comes to mind is A sending a forward request to B to forward to C then sending a switch level packet to C asking if he got the message. Only A and C need to have the protocol patch and there is already a protocol versioning system in place so this would be trivial to integrate. You have to trust C not to lie to you though. This kind of complexity is why I have tried to avoid explicit detection and why I say "cat and mouse game". > >>> The point I was trying to make in my previous email is that whatever information the packets carry to distinguish one packet from another, the adversary can use that information to target certain packets while maintaining the appearance of high overall reliability. > >> All of the distinguishing information (IPv6 header) is encrypted so the only thing is the routing label (unless you're at the recursive routing layer) > > Sorry, I'm confused about layers again. An IPv6 packet's journey across the network consists of one or more DHT hops, each of which consists of one or more switching hops, is that right? And the IPv6 header is encrypted at each DHT hop, so nodes along the switching path of each DHT hop can only read the switching label (and maybe the DHT address of the next DHT node), but not the IPv6 header? Basically correct, the switch can read the label and likely use it's routing table to determine the address of the next hop but cannot determine the destination. For performance and scalability this feature may be removed. > > How does a node learn the keys of its DHT neighbours in order to encrypt packets that only they can decrypt? (Obviously when its DHT neighbours are also its social neighbours this is easy, but what happens when they're not?) When you do a DHT query, you get the keys (and protocol version numbers) along with the paths. > >>>> Can't spoof a packet because the IPv6 address is the public key hash. > >>> Is every packet signed with the corresponding private key? Seems like that would be expensive. > >> Not signed, encrypted with an authenticator, this is very fast. If you don't know the symmetrical key, you can't modify any packet without me knowing and you obviously can't read my packets. The symmetrical key only needs to be derived once. > > I can see how that would prove to the IPv6 destination that the claimed IPv6 source was the real source of the packet - but I can't see how it would prove to any other node that the claimed source was the real source (presumably the symmetric key is only known to the source and destination). So it seems to me that it's still possible to make /some/ nodes believe that a packet originated from a different source than its true source, which might be a building block for other attacks (eg > manipulating the fault detection mechanism). Your technical analysis is spot on. There is no code which relies on the packets originating from someone else so your attack building block this is not much of an issue for me. Anyway signing packets for all the world to see not only performs poorly but is problematic in other ways. I'm not sure people would want their packets to be linked to their identity forever, they can be decrypted after all, by the destination if no one else. Thanks, Caleb > > Cheers, Michael > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR8ZF6AAoJECYAmptlsgnW+Y0P/3ts2lZ7LCAJBujU0SZKFHBn EnFdhNfXSqIGKi2wo+8zO8RIvnCC60IcMqljVbkQiqE8jTZBVwsSuIuob9P4pukm E2vwLd7PJ1s4JR/t/vxoKep84s+S5xbfJT/bNDNwBMWZSTVYUeC1a7wmou1d/uIj oBn9ELWk9iRuc5OTkNdXuCNr/tT57QjYuhIuE9KIySZ+a+Jn4TPC6cMaQ90lwbKS UFlcuDU9EvDWp4ATGSqTLhkoPp5cVqj+Kz9iGIBml3xKW50h+6Ol0C10iYo7e/qP 1AcUHa/kU6r2uCSHyQndzoL6PzWmJ4gRz1PCZe+xPPFcBojeBNdApPylmsqfvB5r YBIESmsr4mexEqrwFJqJRlvk0s1iJya47uAH3JH/23xFvYGTV4X05Eh/nrwGxo5z 5swfE2GKHIDA5SoszkGLMLu6SgpFBCQjy6lSlI6VNjh0ElL76lu2uLxxrS6XQQLw YetGH2PTgzZoaSwydG6OnZkTX9Ae5FdMNlIn68RijP26xMAY84W0M6uEEBNZvC+W Vau16LFTk6MmHi7PHtQLkjlEVLuoFX0EsPWHti8l+9my7sRCCVO4n6vD11+FSMg6 uAelkHGJ0TZEC36DiU67wnZpSo7KBBw0re2GOaewATm0NNnwm44a0ie58z7IunCM 0wu9uJ6jNuVmLM9I8C4E =2PzJ -----END PGP SIGNATURE----- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[tor-talk] Tor Weekly News — July, 24th 2013
by Eugen Leitl 25 Jul '13

25 Jul '13

----- Forwarded message from dope457 <dope457(a)riseup.net> ----- Date: Wed, 24 Jul 2013 14:06:09 +0200 From: dope457 <dope457(a)riseup.net> To: tor-news(a)lists.torproject.org, tor-talk(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — July, 24th 2013 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News July 24th, 2013 ======================================================================== Welcome to the 4th issue of Tor Weekly News, the weekly newsletter that covers what is happening in the great Tor community. The next newsletter is going to be posted to the resurrected tor-news mailing-list. Just subscribe! [1] [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-news Summer Development Meeting 2013 ------------------------------- About 40 core Tor contributors gathered over July 22-23 at the Technische Universität München [2] in Germany for this year's Summer Development Meeting [3]. That's quite a number, and as could be expected, there are a huge number of topics up for discussion — the brainstorming session generated around 150. Gunner from Aspiration Tech [4] is once again facilitating the meeting, helping everyone focus on the most pressing issues. Rough notes from some of the break-out sessions are now up on the wiki. A list of the topics and a brief summary of the discussions are given below: * Love for volunteers: strategies for outreach and long-term support; identifying where they're most needed [5] * Censorship and pluggable transports: documenting the now-large number of pluggable transports; discussing countries' differing censorship strategies [6] * Fundraising: funding outlook seems to be positive, although diversity in funding sources is needed to reduce dependency on single institutions like the US Government [7] * Website Translation: notes from a discussion which led to the definition of a new translation review process and a list of actionables [8] * Service infrastructure: multiple fundamental services could use some more love: GetTor (TBB by email), website, Trac, check.tp.org, BridgeDB; shutting down unmaintained services [9] * Operational security: random notes on OpSec for Tor people [10] On the sidelines of the dev meeting, Roger and Jake are doing a public talk on the topic of 'Tor and the Censorship Arms Race'. [11] If you want to meet people who spend their day making Tor a reality, you can join them for a public hack day [12] on Friday, July 26, 2013. Bring your ideas, questions, projects, and technical expertise with you! [2] http://www.tum.de/ [3] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [4] http://aspirationtech.org/ [5] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [6] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [7] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [8] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [9] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [10] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [11] https://gnunet.org/tor2013tum [12] https://blog.torproject.org/blog/join-us-tor-hack-day-munich-germany Remote descriptor fetching in Stem ---------------------------------- Damian Johnson announced [13] having implemented remote descriptor fetching in Stem [14], a feature to migrate more metrics measurement tools to Python [15]. “Its usage is pleasantly simple” wrote Damian. See for yourself in the excellent documentation! [16] [13] https://lists.torproject.org/pipermail/tor-dev/2013-July/005156.html [14] https://stem.torproject.org/ [15] https://lists.torproject.org/pipermail/tor-dev/2013-May/004924.html [16] https://stem.torproject.org/api/descriptor/remote.html Orbot 12.0.1 call for beta testing ---------------------------------- After a long interval, Nathan Freitas announced the release of a new version of Orbot - a client for the Tor network on Android mobile devices [17]. For Orbot 12.0.1, the developers have “switched versioning styles to a simpler major.minor.bugfix model”, wrote Nathan. He continues with a call for testing: “Since we haven't done a release in a while, and we have some new build tools, I mostly want to make sure I have not done something terribly wrong in the build process. Please confirm back if you are able to successfully use this release.” Updates in 12.0.1: * Updated to Tor 0.2.4.15-RC * flashy screen bug fixed now shows traffic * Stats in notification area * better handling of preference settings * Changes added superuser permission for Cyanogen You can download and start testing this release here [18] or here [19]. [17] https://lists.torproject.org/pipermail/tor-talk/2013-July/029063.html [18] https://rink.hockeyapp.net/apps/92ace552aa5344d1a802decb71525897/ [19] https://guardianproject.info/releases/Orbot-release-12.0.1-beta-1.apk Miscellaneous development news ------------------------------ Lunar reported on the trip to Brussels for LSM 2013. [20] To sum it up, “people are really supportive of what we do these days”. anonym outlined [21] the release schedule for Tails 0.20. intrigeri announced [22] that Tails has switched to a more conventional task manager. It might now be easier for you to see what needs to be done. Have a look at the current list of 496 open issues [23], there might be something waiting just for you. Tor developers would love to find an easier way to debug tor when the daemon crashes. Nick Mathewson came up with an initial piece of code that could (when complete) dump stack traces on assertion, crash, or general trouble to the logs. There's more work to be done before it can be merged in Tor. Feel free to help — especially if you know how to do this on Windows or BSD. [24] Nick Mathewson along with Andrea created a wiki page for initial 0.2.5 series ticket triage [25]. If you have your own agenda for 0.2.5, you should be talking to them now! Kostas Jakeliunas reported on their GSoC project about producing a searchable metrics archive. [26] Arturo reported on his activities on Ooni probe in June. [27] Pierre Lalet announced [28] that he started working on an implementation of the Tor protocol in Python. The intent is to have an independent implementation to test Tor. As the author puts it, "the purpose is NOT to implement a secure or robust implementation that could be an alternative to Tor." Have a look at the code [29]: "Comments, fixes and questions welcome !" [20] https://lists.torproject.org/pipermail/tor-reports/2013-July/000292.html [21] https://mailman.boum.org/pipermail/tails-dev/2013-July/003292.html [22] https://mailman.boum.org/pipermail/tails-dev/2013-July/003297.html [23] https://labs.riseup.net/code/projects/tails/issues [24] https://trac.torproject.org/projects/tor/ticket/9299 [25] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/025/TicketTr… [26] https://lists.torproject.org/pipermail/tor-dev/2013-July/005158.html [27] https://lists.torproject.org/pipermail/tor-reports/2013-July/000291.html [28] https://lists.torproject.org/pipermail/tor-dev/2013-July/005161.html [29] https://github.com/cea-sec/TorPylle Upcoming events --------------- Jul 26 | Tor Hack Day | München, Germany | https://blog.torproject.org/blog/join-us-tor-hack-day-munich-germany | Jul 31-05 | Tor at OHM | Geestmerambacht, Netherlands | https://ohm2013.org/ | Aug 1-4 | Runa Sandvik @ DEF-CON 21 | Rio Hotel, Las Vegas, USA | https://www.defcon.org/html/defcon-21/dc-21-index.html | Aug 13 | Roger at the 3rd USENIX Workshop on Free and Open Communications on the Internet | Washington, DC, USA | https://www.usenix.org/conference/foci13/ This issue of Tor Weekly News has been assembled by Lunar, dope457, harmony, moskvax, malaparte, whabib, and David Fifield. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [30], write down your name and subscribe to the team mailing-list [31] if you want to get involved! [30] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [31] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Reduced NSA TA History
by John Young 24 Jul '13

24 Jul '13

Th NSA Traffic Analysis history reduced from 11.5MB to 3.2MB: http://cryptome.org/2013/07/nsa-traffic-analysis.pdf

1 0

NSA History of Traffic Analysis
by John Young 24 Jul '13

24 Jul '13

NSA released on 23 July 2013 "The History of Traffic Analysis: World War I-Vietnam." http://www.nsa.gov/about/_files/cryptologic_heritage/publications/misc/traf… It notes the formation of T/A (Traffic Analysis) and C/A (Cryptanalysis) as the two elements of code-breaking, using the mail analogy of T/A for the envelope, C/A for the contents. As noted elsewhere T/A is now publicized as "metadata."

1 0

Join us for a public hack day on Friday, July 26, 2013 in Munich, Germany.
by Eugen Leitl 24 Jul '13

24 Jul '13

https://blog.torproject.org/blog/join-us-tor-hack-day-munich-germany JOIN US - Tor Hack Day, Munich, Germany Posted July 8th, 2013 by kelley in dev meeting hack day Join us for a public hack day on Friday, July 26, 2013 in Munich, Germany. Thank you to our hosts at the Technische Universität München (http://www.tum.de) The agenda and conversations will be determined by you and Tor's team of developers and researchers - so bring your ideas, questions, projects and technical expertise with you! This event is open to the public and free of charge - no RSVP necessary. Friday, July 26, 2013 Start Time: 10:00 am Location: LRZ building, Sminarraum (H.E. 008), Bolzmannstrabe 1, 85748 Garching, Germany. NOTE: the room is to the right of the main entrance. For questions please contact execdir(a)torproject.org

1 0

Re: Python Random Number Generator for OTP
by Bill Stewart 24 Jul '13

24 Jul '13

> > >Â Why not use /dev/random, instead of "ensuring you have entropy"Â > > /dev/random limits the output size to the > estimated entropy. So it has abysmal > performance unless there are high performance entropy sources available. This is for a one-time pad. Limiting the output size to the estimated entropy is a *requirement*. Abysmal performance is fine, because you're going to transfer the pad using a briefcase handcuffed to a courier's arm or some similarly high-cost high-latency physical distribution method, though if you've got a higher-performance entropy source, great. > After the initial seeding this gains very little security in practice. If "gains very little security in practice" is good enough for you, you don't need a one-time pad. Yes, the pseudo-random bits you get out of /dev/urandom will probably be much better than the bits the Russians got by mashing down the keys on typewriters, and you're probably not going to be attacked with the persistence of the Venona decrypters, but don't waste your time using one-time pads unless you're going to use them perfectly. You're much better off using a long-enough RSA key and some Diffie-Hellman session key generation. (Of course, you still want good random numbers for those, but /dev/random is plenty fast enough for that, at least on any non-virtual machine.)

3 3

Re: Gnu PG is more Safe ?
by Anthony Papillion 24 Jul '13

24 Jul '13

On Jul 23, 2013, at 9:01 PM, oxopz7(a)riseup.net wrote: > Hello everybody! > > I hope all are fine, and doing well! > > I'm good member :) I hope you will accept me! Welcome to the list! It's good to see so many new members coming on board. I'm new myself. > I like to ask about GNU PG, if is more safe than other kind of > software! > that talks about Crypto ? Because GnuPG is open source, it's been extensively peer reviewed and found safe and secure. That doesn't mean it's perfect and has no errors. But they are much less likely to exist in GnuPG than in some other solutions; particularly proprietary ones. > I like to ask also about good resources in Crypto, specially about > SSL/TLS? One of the best ways to learn about tech topics is reading RFC's. The entire way SSL/TLS operates is detailed in an RFC. Read I'd and you will be infinately more informed. Unfortunately, I can't really recommend any good crypto list because I've not found many. To learn about FnuPG and practice, you might want to look at the PGPNET list. Another of interest might be Cryptography. Regards and Welcome! Anthony

7 9

Re: [serval-project-dev] mesh networking patent application - prior art request
by Eugen Leitl 24 Jul '13

24 Jul '13

----- Forwarded message from Bryce Lynch <virtualadept(a)gmail.com> ----- Date: Tue, 23 Jul 2013 13:41:35 -0400 From: Bryce Lynch <virtualadept(a)gmail.com> To: serval-project-developers(a)googlegroups.com Subject: Re: [serval-project-dev] mesh networking patent application - prior art request Reply-To: serval-project-developers(a)googlegroups.com On Tue, Jul 23, 2013 at 7:54 AM, Dan Staples < danstaples(a)opentechinstitute.org> wrote: > That's sickening. Not paying a dime in US taxes on billions of dollars > of profit apparently isn't enough for GE, now they have to patent mesh > technology. > Mesh networking is too potentially dangerous to go unrestricted. That said, I just posted a bunch of stuff to that thread with as many links to verifiable code commits in public repos as I could. Anybody so inclined to check my work, please do, and some up-votes would be nice if they don't suck too badly. -- The Doctor [412/724/301/703] [ZS] https://drwho.virtadpt.net/ "I am everywhere." -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe(a)googlegroups.com. To post to this group, send email to serval-project-developers(a)googlegroups.com. Visit this group at http://groups.google.com/group/serval-project-developers. 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Crowdfunding code reviews [was: GnuPG Safe]
by grarpamp 24 Jul '13

24 Jul '13

On Tue, Jul 23, 2013 at 11:08 PM, Peter Gutmann <pgut001(a)cs.auckland.ac.nz> wrote: > Having code that's open source doesn't help at all if no-one looks at it. It is easy to write code. Harder to write it securely. Even harder to spot your own mistakes. And unless perfect written from the start, will need reviewed and fixed. Yet time to review and fix is not as free as the time writing it, is often viewed as a chore, and happens far less than open source assumes it does. Are we developed enough to begin putting together lists of most critical libraries/tools/apps and pipelining them through a crowdfunded independant peer review program? (501c3 perhaps) Or at least put bounties on the same lists.

1 0