July 2018 - cypherpunks-legacy

[tahoe-dev] notes from the Tahoe-LAFS Weekly Dev Call, 2012-09-11
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

Folks: As usual, I'm not taking the time to contextualize and vet all these notes. Caveat lector! Also, I've maintained my tradition of adding some of my own thoughts that weren't actually expressed out loud in the discussion. (In particular the advocacy for adding padding and the ideas about how to do so.) in attendance: Brian, David-Sarah, Andrew, Zooko (scribe) b" topic: The compression attack on HTTPS. (Not really relevant to Tahoe-LAFS, but interesting.) Brian says one possible defense against this is to move your secrets from cookies to the URL. This makes the attack impossible unless your secrets are sharing a compression context with the attack. Does anyone actually use TLS compression? Is it turned off by default? Does anyone configure it on? A similar attack is possible on HTTP encryption, if the higher-layer protocol includes attacker-controlled data in the payload. This would be relevant to Tahoe-LAFS if we added compression. However, even if we added compression, we would never mix attacker-controlled data with attacker-unknown data in the same file. However, a higher-layer protocol might mix them. One caveat: convergent encryption could allow compression between attacker-controlled and attacker-unknown data! In fact, there is a deep connection between the adaptive-chosen-plaintext-compression- violates-confidentiality ("CRIME") attack and the drewp "learn the remaining information" attack! The drewp defense -- the Added Convergence Secret -- is exactly the thing that creates independent compression contexts in order to limit the scope for attack. Zooko and (perhaps to a lesser degree) Brian are uncomfortable with the fact that LAFS currently exposes the length of your plaintext, to the byte level of precision. Zooko wants to add padding. That would probably help against the convergent-encryption-based CRIME attack which currently exists in hazy nascent form in Zooko's mind. Also, it enhances general privacy, for example an attacker might be able to recognize what files you are storing and reading just from the lengths of the files. Padding could help against that. Padding out to fixed boundary (e.g. to the next 16 bytes, or to the next 4096 bytes, or whatever) helps but the information can still leak if there are a number of files. For example, suppose you're browsing or downloading a directory containing hundreds of files of varying lengths. The attacker knows the lengths of some files that he suspects you might be browsing. Even if the ciphertext is padded out to fixed sizes, thus "coarsening" or discretizing the information, he might still be able to recognize the pattern. A better defense is to add a random amount of padding, where the random amount is determined by the (possibly convergently generated) encryption key. b" topic: engineering tools and practices We talked about usage of git. David-Sarah likes git-gui. Andrew asked if he should rebase patches when submitting pull requests and Brian said yes. Brian said always first rebase -- bring everything up to trunk -- and then rerecord it as a set of logical commits. It is not necessary to squash it all down into a single commit, unless that's what makes sense. Definitely squash out ephemeral stuff like "Oops, made a typo, oops test didn't pass, let me go back and fix that.". It often makes sense to make four patches: First refactor the code so that there is no actual functional changes, second cosmetic changes like whitespace, third update the unit tests, fourth the new code. Ideally, the revision history tells a story. b" topic: When do we kill off darcs? David-Sarah still has some patches that need to be darcs pushed. But they could diff-and-patch those to git. At some point soon we'll all agree to stop pushing patches into darcs. LeastAuthority.com's Cloud Backend is currently in darcs. We are scheduled to merge the cloud backend to trunk within three weeks. There is still the question of how to handle hyperlinks into https://tahoe-lafs.org that point at darcs patches and history. b" topic: Will Cloud Backend, leasedb, and accounting go into Tahoe-LAFS v1.11? _______________________________________________ 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: [liberationtech] Bitcoin and The Public Function of Money
by Gregory Maxwell 06 Jul '18

06 Jul '18

On Tue, Oct 30, 2012 at 9:51 PM, StealthMonger <StealthMonger(a)nym.mixmin.net> wrote: > Yes, Bitcoin liberates trade from "public" extortion ("taxation"). It does no such thing. Under US law, for example, Barter in Bitcoins is just as taxable as bartering with coal or cows and share many similar properties (also with cash). Adding 'bit' to the name of something doesn't somehow make it magically invisible to authorities. I'm happy that Bitcoin is interesting technology that inspires fascinating political and technical discussions from people with all kinds of backgrounds and political persuasions. At the same time I'm disappointed (I used to be shocked, but that has long since worn off) by the callousb and I believe very short sighted and non-pragmaticb politics of a vocal few promote. This advocacy of dog-eat-dog and everyman as his own militia as an ultimate ideal is not a phenomena unique to Bitcoin. Many Bitcoin users I know are kind and thoughtful people and all of the developers I know are. The fact that people with vastly different views can find the system compelling is just one of its attractions and challenges. Dmytri's views don't sound incompatible with mine. I just wanted to speak up so that people wouldn't reject considering Bitcoin for something off-hand because they, like I, find StealthMonger's politics distasteful. Tying it back to the list topic. There are some interesting challenges int the context of anonymity systems 9in particular) which I think that Bitcoin, and technologies from its ecosystem, can contribute to improving. Generally preventing denial of service from resource starvation or spam is frustrated when participants are anonymous. Expensive pseudonymity can help, but making those pseudonyms expensive can be tricky (especially as computers will eventually better than humans at captha solving, already I find I have to retry stronger captchas myself several times). If Bitcoin becomes widely used then it can be an option for making pseudonyms costly in a way which may be more anonymous and equal in access than other options. (and of course, making a pseudonym _cost_ no matter in what form disenfranchises people who are poorer; which is unfortunate. Socially prudent technology uses that kind of measure as a last resort and in the least impacting form. I'm personally not a fan of web-of-trust systemsb they're strongly anti-privacy and second-order or higher trust must have complicated heuristics to avoid abuse which I fear may result in kafkaesque outcomes. It may be unjust to allow money to govern our actions, but it can be more just than the deranged correlations of a bayesian classifier.) Another point here is that Bitcoin is more than a simple 1:1 value transfer system. Bitcoins can be specified with complex rules for the criteria under which they can be redeemed. For example, I can write a transaction which can be redeemed by anyone publishing a first-preimage of a specified hash; or only according to a quorum of signers. These kinds of zero or low trust mechanismsb especially when coupled with other not yet existing infrastructureb can potentially restore the freedom to safely make transactions for people in places where the traditional methods of contract enforcement are dysfunctional or are unavailable for political or privacy reasons; or can simply be used to make strong enforcement available when it otherwise would be too expensive. From a liberty perspective I think that strongly cheat proof/resistant systems are generally preferable to post-hoc enforcementb its better to build systems that cant be cheated than to have the costs and risks of enforcement and fails for people who do cheat. Bitcoin provides underling infrastructure for building these such systems when they depend on the transferring value. So I hope that thoughtful technology people continue thinking of Bitcoin as a potential tool, and just ignore the politics of other people who like Bitcoin for different (and sometime misguided) reasons. -- Unsubscribe, change to digest, or change password 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[liberationtech] 'Internet in a Suitcase' ready for field testing
by Joel Harding 06 Jul '18

06 Jul '18

'Internet in a Suitcase' ready for field testing Posted By John Reed Monday, November 5, 2012 - 6:38 PM http://killerapps.foreignpolicy.com/posts/2012/11/05/internet_in_a_suitcase… When will rebels, dissidents, and activists be able to safely voice dissent and coordinate their activities online in the face of a government equipped with Western technology designed to snoop on all types of electronic communications? Maybe in as little as a year, according to Sascha Meinrath of the New America Foundation's Open Technology Institute, the man leading the effort to field the so-called Internet in a Suitcase. Internet in a Suitcase is basically a software program aimed at giving people in conflict or disaster zones the ability to establish a secure, independent wireless network over their computers and cell phones. While the system (which, despite its name, involves neither hardware nor a suitcase) is being tested and is usable right now, Meinrath and his team of developers around the globe are holding off on releasing it to groups like the Syrian rebels until they are confident that it can resist large-scale hacking by governments. What "we're now working on is the due diligence and doing an international deployment, not in the world's hot spots but rather in a post-conflict sort of area, maybe a Libya or an Egypt or another location where the benefits would be very great, but the risk to users in case, say, one of the authentication systems or part of the security mechanisms failed, would not be great," said Meinrath during a Nov. 2 interview with Killer Apps. This will allow the system to be used in the wild and expose any potential weaknesses without exposing users to the wrath of a state security agency. "Once we [feel] comfortable that the system [is] decently secure, then and only then would we be looking at deploying it to one of the world's hot spots; so a Syria or a North Korea or a China, or a Tehran kind of scenario, that kind of work, and that's probably still a year out from now, "said Meinrath. "Our focus first and foremost is, do no harm." This means that in the not-too-distant future, rebels, dissident groups, and even disaster workers will be able to use the secure wireless network designed to resist government eavesdropping. Internet in a Suitcase received a lot of attention earlier this year when it was listed as one of several U.S. government funded projects aimed at providing wireless communications networks for people in conflict zones or places rife with government monitoring of the Internet. "It's a series of software packages that can run on things like laptops or cell phones, whatever devices happen to be available on the ground -- wifi routers, whatever -- and allows them to communicate directly and securely," said Meinrath. "Instead of having to go through existing infrastructure" that could be downed by a disaster or monitored by a government "you can create alternate infrastructure." Downloading the project's software would let a rebel or activist use their cell phone or laptop to communicate directly to other users' machines via the devices' wifi chips. Since these ad hoc wifi networks feature no central control system or administrator, they are much more difficult to monitor, according to Meinrath. "This is a completely ad hoc network, there's no dependency of any device on any other device and that eliminates a central point for command and control surveillance and monitoring," said Meinrath. "We also have authentication between each hop on the network and encryption across each hop." Basically, data being transmitted is passed through a number of different machines on a network before it reaches its destination. Each of those machines asks the data for information saying that it is trustworthy. Each time the data moves, it is encrypted at multiple levels to protect against someone eavesdropping on the airwaves over which the data moves. This type of encryption is important since "we assume that a malfeasant power would be able to compromise [a device on the network] or put up their own node into a network of this sort, " said Meinrath. These mini Internets -- that, in some places where they already exist span entire metro regions -- can host a number of locally developed apps that can do everything from video and audio file sharing to tracking where vehicles and people are. "Inside that network, things are incredibly fast, often an order of magnitude faster than most people's Internet connections, and the latency is very low, so you can do all sorts of really interesting big broadband kind of services and applications if they're housed locally" on members' computers, smart phones or even a USB stick, said Meinrath. Even better, all of that connectivity is free since it is completely independent of any Internet or telecomm provider. "The killer app that I talk with a lot of folks about is, if you have a system like this, there's no reason you would ever need to pay for local phone calls again" once you've downloaded the software allowing your device to join the wifi network, "because you're just pinging machine to machine over a local network," said Meinrath. Joel Harding Information Operations Holistic Organizer (IOHO) http://toinformistoinfluence.com (703) 362-8582 -- Unsubscribe, change to digest, or change password 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [liberationtech] Efficient digital one-way communication
by Jens Christian Hillerup 06 Jul '18

06 Jul '18

On Mon, Mar 4, 2013 at 4:40 PM, Michael Rogers <michael(a)briarproject.org> wrote: > Last year I spent some time playing with audio encoding of data for > transmission over handheld radios. The state of the art here is dialup > modems - on a good day they can get 56,000 bits per second over a > channel designed for voice, but that requires advanced modulation and > error correction techniques. The radio hams have packet radio (AX.25 > and APRS) running at 1,200-9,600 bps over long distances using simple > modulation and no error correction. Some early home computers used > audio cassettes for storage (300-1,200 bps, CUTS or Kansas City Standard). Nice information, thanks. Would it be wrong to assume larger data rates to be attainable on an FM "link" than over the telephone line? For music etc. FM has far superior sound quality in any case. > If you want to support purely one-way communication (no acks), you'll > need to forward error correct the data. Hamming codes and parity > checks are simple to implement but they'll eat a lot of your > bandwidth; Reed-Solomon codes are more bandwidth-efficient but also > more complex. Yes, I thought of that too in September. Luckily I've taken courses in abstract algebra and error-correcting codes at my university; I think I'd be able to write a working RS implementation from my theory books. Another thing I didn't tell in my first mail is that I've been wanting to design a protocol for metadata, too, since it doesn't really make sense to decode and save half files anyway. It would also make it possible to send the file names and file sizes beforehand so the receiver can know how much of the file s/he has already received. And yes, I want this to be truly one-way -- no acks. The idea is that I want the receiving end to need as little hardware as possible: one FM radio and one computer with a sound card (and this software). The sender obviously has access to an FM transmitter (or whatever becomes the sound carrier). This modulation algorithm should not provide authenticity of the sender, instead cryptographic signing of the data should happen at higher levels of the stack. > Some Java code for modulation, framing and error correction is here if > you're interested: > > http://briar.git.sf.net/git/gitweb.cgi?p=briar/sandpit;a=tree;f=src/net/sf/… > http://briar.git.sf.net/git/gitweb.cgi?p=briar/sandpit;a=tree;f=src/net/sf/… Thanks a lot! I'll have a look at it soon. JC -- 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

State of the art in hardware reverse-engineering
by Leichter, Jerry 06 Jul '18

06 Jul '18

Flylogic Engineering does some very interesting tampering with "tamper- resistant" parts. Most of those "secure USB sticks" you see around won't last more than a couple of minutes with these guys. See http://www.flylogic.net/blog -- Jerry --------------------------------------------------------------------- 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: [p2p-hackers] SHA1 broken?
by hal＠finney.org 06 Jul '18

06 Jul '18

The problem with the attack scenario where two versions of a program are created with the same hash, is that from what little we know of the new attacks, they aren't powerful enough to do this. All of the collisions they have shown have the property where the two alternatives start with the same initial value for the hash; they then have one or two blocks which are very carefully selected, with a few bits differing between the two blocks; and at the end, they are back to a common value for the hash. It is known that their techniques are not sensitive to this initial value. They actually made a mistake when they published their MD5 collision, because they had the wrong initial values due to a typo in Schneier's book. When people gave them the correct initial values, they were able to come up with new collisions within a matter of hours. If you look at their MD5 collision in detail, it was two blocks long. Each block was almost the same as the other, with just a few bits different. They start with the common initial value. Then they run the first blocks through. Amazingly, this has only a small impact on the intermediate value after this first block. Only a relatively few bits are different. If you or I tried to take two blocks with a few bits different and feed them to MD5, we would get totally different outputs. Changing even one bit will normally change half the output bits. The fact that they are able to change several bits and get only a small difference in the output is the first miracle. But then they do an even better trick. They now go on and do the second pair of blocks. The initial values for these blocks (which are the outputs from the previous stage) are close but not quite the same. And amazingly, these second blocks not only keep things from getting worse, they manage to heal the differences. They precisely compensate for the changes and bring the values back together. This is the second miracle and it is even greater. Now, it would be a big leap from this to being able to take two arbitrary different initial values and bring them together to a common output. That is what would be necessary to mount the code fraud attack. But as we can see by inspection of the collisions produced by the researchers (who are keeping their methodology secret for now), they don't seem to have that power. Instead, they are able to introduce a very carefully controlled difference between the two blocks, and then cancel it. Being able to cancel a huge difference between blocks would be a problem of an entirely different magnitude. Now, there is this other idea which Zooko alludes to, from Dan Kaminsky, www.doxpara.com, which could exploit the power of the new attacks to do something malicious. Let us grant that the only ability we have is that we can create slightly different pairs of blocks that collide. We can't meaningfully control the contents of these blocks, and they will differ in only a few bits. And these blocks have to be inserted into a program being distributed, which will have two versions that are *exactly the same* except for the few bits of difference between the blocks. This way the two versions will have the same hash, and this is the power which the current attacks seem to have. Kaminsky shows that you could still have "good" and "bad" versions of such a program. You'd have to write a program which tested a bit in the colliding blocks, and behaved "good" if the bit was set, and "bad" if the bit was clear. When someone reviewed this program, they'd see the potential bad behavior, but they'd also see that the behavior was not enabled because the bit that enabled it was not set. Maybe the bad behavior could be a back door used during debugging, and there is some flag bit that turns off the debugging mode. So the reviewer might assume that the program was OK despite this somewhat questionable code, because he builds it and makes sure to sign or validate the hash when built in the mode when the bad features are turned off. But what he doesn't know is, Kaminsky has another block of data prepared which has that flag bit in the opposite state, and which he can substitute without changing the hash. That will cause the program to behave in its "bad" mode, even though the only change was a few bits in this block of random data. So this way he can distribute a malicious build and it has the hash which was approved by the reviewer. And as Zooko points out, this doesn't have to be the main developer who is doing this, anyone who is doing some work on creating the final package might be able to do so. On the other hand, this attack is pretty blatant once you know it is possible. The lesson is that a reviewer should be suspicious of code whose security properties depend on the detailed contents of blocks of random-looking data. One problem with this is that there are some circumstances where it could be hard to tell. Zooko links to the example of a crypto key which could have weak and strong versions. The strong version could be approved and then the weak version substituted. There are also some crypto algorithms that use random-looking blocks of data which could have weak and strong versions. So it's not always as easy as it sounds. But most code will not have these problems, and for those programs it would be pretty conspicuous to implement Kaminsky's attacks. At present, that looks to be the best someone could do with SHA-1 or even MD5. Hal Finney _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

State of the art in hardware reverse-engineering
by Leichter, Jerry 06 Jul '18

06 Jul '18

Flylogic Engineering does some very interesting tampering with "tamper- resistant" parts. Most of those "secure USB sticks" you see around won't last more than a couple of minutes with these guys. See http://www.flylogic.net/blog -- Jerry --------------------------------------------------------------------- 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: [p2p-hackers] SHA1 broken?
by hal＠finney.org 06 Jul '18

06 Jul '18

The problem with the attack scenario where two versions of a program are created with the same hash, is that from what little we know of the new attacks, they aren't powerful enough to do this. All of the collisions they have shown have the property where the two alternatives start with the same initial value for the hash; they then have one or two blocks which are very carefully selected, with a few bits differing between the two blocks; and at the end, they are back to a common value for the hash. It is known that their techniques are not sensitive to this initial value. They actually made a mistake when they published their MD5 collision, because they had the wrong initial values due to a typo in Schneier's book. When people gave them the correct initial values, they were able to come up with new collisions within a matter of hours. If you look at their MD5 collision in detail, it was two blocks long. Each block was almost the same as the other, with just a few bits different. They start with the common initial value. Then they run the first blocks through. Amazingly, this has only a small impact on the intermediate value after this first block. Only a relatively few bits are different. If you or I tried to take two blocks with a few bits different and feed them to MD5, we would get totally different outputs. Changing even one bit will normally change half the output bits. The fact that they are able to change several bits and get only a small difference in the output is the first miracle. But then they do an even better trick. They now go on and do the second pair of blocks. The initial values for these blocks (which are the outputs from the previous stage) are close but not quite the same. And amazingly, these second blocks not only keep things from getting worse, they manage to heal the differences. They precisely compensate for the changes and bring the values back together. This is the second miracle and it is even greater. Now, it would be a big leap from this to being able to take two arbitrary different initial values and bring them together to a common output. That is what would be necessary to mount the code fraud attack. But as we can see by inspection of the collisions produced by the researchers (who are keeping their methodology secret for now), they don't seem to have that power. Instead, they are able to introduce a very carefully controlled difference between the two blocks, and then cancel it. Being able to cancel a huge difference between blocks would be a problem of an entirely different magnitude. Now, there is this other idea which Zooko alludes to, from Dan Kaminsky, www.doxpara.com, which could exploit the power of the new attacks to do something malicious. Let us grant that the only ability we have is that we can create slightly different pairs of blocks that collide. We can't meaningfully control the contents of these blocks, and they will differ in only a few bits. And these blocks have to be inserted into a program being distributed, which will have two versions that are *exactly the same* except for the few bits of difference between the blocks. This way the two versions will have the same hash, and this is the power which the current attacks seem to have. Kaminsky shows that you could still have "good" and "bad" versions of such a program. You'd have to write a program which tested a bit in the colliding blocks, and behaved "good" if the bit was set, and "bad" if the bit was clear. When someone reviewed this program, they'd see the potential bad behavior, but they'd also see that the behavior was not enabled because the bit that enabled it was not set. Maybe the bad behavior could be a back door used during debugging, and there is some flag bit that turns off the debugging mode. So the reviewer might assume that the program was OK despite this somewhat questionable code, because he builds it and makes sure to sign or validate the hash when built in the mode when the bad features are turned off. But what he doesn't know is, Kaminsky has another block of data prepared which has that flag bit in the opposite state, and which he can substitute without changing the hash. That will cause the program to behave in its "bad" mode, even though the only change was a few bits in this block of random data. So this way he can distribute a malicious build and it has the hash which was approved by the reviewer. And as Zooko points out, this doesn't have to be the main developer who is doing this, anyone who is doing some work on creating the final package might be able to do so. On the other hand, this attack is pretty blatant once you know it is possible. The lesson is that a reviewer should be suspicious of code whose security properties depend on the detailed contents of blocks of random-looking data. One problem with this is that there are some circumstances where it could be hard to tell. Zooko links to the example of a crypto key which could have weak and strong versions. The strong version could be approved and then the weak version substituted. There are also some crypto algorithms that use random-looking blocks of data which could have weak and strong versions. So it's not always as easy as it sounds. But most code will not have these problems, and for those programs it would be pretty conspicuous to implement Kaminsky's attacks. At present, that looks to be the best someone could do with SHA-1 or even MD5. Hal Finney _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Re: [liberationtech] Modern FIDONET for net disable countries?
by Peter Fein 06 Jul '18

06 Jul '18

I & some other Telecomix agents have discussed using a local Usenet (NNTP) for exactly this purpose a few times since Tahrir. Run it off a liveCD + adhoc wifi or OpenWRT, with web gateway interface (so random users can participate without needing to install software). Long distance backhaul by dialup modem or motorcycle courier w/ USB stick. Rather than trying to build in centralized security/identity, force everything to anonymity/pseudonymity (the 4chan model). You don't need the access to the global Internet to organize your city... On Dec 27, 2012 11:54 AM, "Jerzy Eogiewa" <jerzyma(a)interia.eu> wrote: > Hello! > > I wonder, is some FIDONET type service existing for countries where all > telecom is disabled? Kind of "sneakernet" for large packets of messages to > be delivered. > > 1- I write message to [username, address or hash], encrypt with > public/private pair. > 2- Trusted "sneakernet" collector with some software physically arrives > and grabs my message, updates my 'ball' (or blob?) of crypted messages, in > case other sneakernet collector comes. > 3- Maybe when delivery is 100% confirmed this gets added to ball so it can > be pruned? > > And so on. Bitcoin style blockchain confirmation seems useful? > > Does any service like this existing now? > > -- > Jerzy Eogiewa -- jerzyma(a)interia.eu > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password 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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Abridged info on RISKS (comp.risks)
by RISKS-request＠csl.sri.com 06 Jul '18

06 Jul '18

The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request(a)csl.sri.com containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe(a)csl.sri.com or risks-unsubscribe(a)csl.sri.com depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall(a)newcastle.ac.uk>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks(a)CSL.sri.com with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r <http://the.wiretapped.net/security/info/textfiles/risks-digest/> . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: <http://www.csl.sri.com/illustrative.html> for browsing, <http://www.csl.sri.com/illustrative.pdf> or .ps for printing ------------------------------ End of RISKS-FORUM Digest 24.73 ************************ ----- 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