July 2018 - cypherpunks-legacy

Out of Office AutoReply: Crypto questions
by Trei, Peter 06 Jul '18

06 Jul '18

I'm out until Jan 2. Jeff Hamell, Bill Duane, and John Worral have contact info

1 0

Logan to start express security program this summer /
by Monty Solomon 06 Jul '18

06 Jul '18

Participants register and pay yearly fee Logan to start express security program this summer Participants register and pay yearly fee By Peter J. Howe, Globe Staff | January 20, 2006 Logan International Airport will implement a ''registered traveler" program this summer that allows passengers who pass a screening check and pay a yearly fee to use special express security lines. Passengers will also have to submit fingerprints and eye scans to qualify. Other key details of the program, including how much it will cost and when it will start, are still being worked out. To boost interest in the program, participants will probably get benefits such as discounts on parking and dining at the airport, according to Thomas J. Kinton Jr., director of aviation for the Massachusetts Port Authority, which runs Logan. Logan was one of five US airports that conducted small-scale registered-traveler program trials that ended in September. At Logan, the program involved about 1,800 American Airlines frequent fliers. Registered travelers show their boarding passes and get their identities confirmed by a machine that checks either their iris or index finger tip. They still have to go through metal detectors and put their bags through X-ray scanners but often save several minutes by avoiding security lines used by the general public that can get crowded. And unless registered travelers set off a metal detector or have a banned item in their carry-on luggage, they are also exempted from so-called secondary screening patdowns by airport security officials that involve a randomly selected percentage of all travelers in general security lines. Currently, among US airports only Orlando International Airport offers a special registered traveler check-in, which has enrolled 13,000 people since June who pay $80 a year. Airports in Indianapolis, Sacramento, Calif., and San Jose also plan to offer the programs this summer. People who get registered traveler cards from Massport will be able to use them at all US airports that decide to offer the service, Kinton said yesterday. ... http://www.boston.com/news/local/massachusetts/articles/2006/01/20/logan_to… tart_express_security_program_this_summer/ ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] Logan to start express security program this summer /
by David Farber 06 Jul '18

06 Jul '18

Participants register and pay yearly fee X-Mailer: Apple Mail (2.746.2) Reply-To: dave(a)farber.net Begin forwarded message:

1 0

[tahoe-dev] Boulder Hack Fest!
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

Folks: Let's have a Hack Fest in Boulder, Colorado, and on the Internet on the weekend of March 30! David-Sarah will be in town, visiting LAE World Headquarters. Marlowe and possibly other members of the Marlowe family will drive over from Kansas City. If anybody else wants to physically attend the Hack Fest, please let me know so I can make sure to get access to a big enough conference room, and map out crash space on our floor. I know Jean Lorchat wants to be linked in over the Internet. If anybody else wants that, let me know. Regards, Zooko _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://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] 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

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: [FoRK] bitcoins vs. alchemy
by Gordon Mohr 06 Jul '18

06 Jul '18

On 12/6/12 7:56 PM, Ken Ganshirt @ Yahoo wrote: > --- On Thu, 12/6/12, Gordon Mohr <gojomo-forkxent(a)xavvy.com> wrote: > >> >> The consensus ledger then agrees that your key can spend those >> bitcoins. >> >> Only if someone gets your private key can they pretend to be the >> owner of those previously-minted-on-schedule coins. >> >> - Gordon >> > > That's the part that I don't get, even after reading. When you do > get around to spending your bitcoins, do those earlier bitcoins have > their original purchasing power? Or do they only have the more recent > "devalued" purchasing power? There is no 'devaluation event'. There's a decrease in the reward credited when someone wins the race to supply the next canonical transaction-log block. The reward used to be 50 BTC per block; now it's 25 BTC per block. It will keep halving at regular intervals until it's less than the smallest representable value in the protocol. 1 BTC from a recent 25 BTC reward is exactly the same as 1 BTC from an earlier 50 BTC reward. Age of origin doesn't matter, and in normal use, the balances that originated in different block rewards get mixed together. (A subsequent use of that mixed balance just refers back to the immediately previous mixing-use. While it is *possible* to keep looking further back to precedent transactions, it's not *necessary*.) Unfortunately the terms and analogies used to describe Bitcoin often lead to confusion. They're not really 'created by computation' or even 'discovered', but disbursed on a reward schedule that's set by the system's 'technical constitution'. Who wins the hash-collision/block-creation competition only affects to whom the values are disbursed. Thinking about them as a tangible thing (or even a specific number/solution) can also lead you astray; they're just a credit, in a shared globally-readable ledger. Based on that consensus ledger, veryone agrees a particular public-key may reassign that balance to one or more other public-keys (by submitting a signed transaction). It's more like a bunch of swiss bank accounts in the peer-cloud, than it is some collection of digital rarities kept secure via confidentiality. (You just keep your signing keys -- your bank account passwords, if you will -- secret, so that no one else can issue signed transactions drawing down your balances.) > Asked a different way, are all bitcoins of equal "value" all the > time, just as 1 "dollar" of fiat currency is always equal to any > other 1 "dollar" of that same fiat currency at any single point in > time? Or is there a different value between the earlier and more > recent. Eg. Is there some distinction based on the different > "vintages" that are baked into the "revaluation" process such that at > the same instant in time 1 unit of bitcoin mined before a devaluation > event is "worth" more than that same size unit mined after. Yes, all bitcoin balances are denominated in the same mixable/interchangeable units. Vintage doesn't matter. 1 BTC (from any block/txn) + 1 BTC (from any other block/txn) = 2 BTC (There are some other subtleties, regarding balances that were recently awarded or transferred. So by convention some balances may not be immediately/preferentially spendable. But in such cases just waiting for the blockchain to get a bit longer over 1-20 hours makes the balances completely equal.) > There seems to be an assumption in some folks' questions that there > is a difference in "value" by vintage, eg. related to/marked by each > "revaluation" stage. I'm not sure, so I have to ask the dumb > question. > > Or perhaps there is something else baked into the process such that > after a devaluation event the payout for a block is relatively > smaller than it would have been before the devaluation event to > offset the relative change in value due to the revaluation? Any assumptions involving a 'devaluation event' or 'revaluation vintages' would be based on misconceptions. Of course, the value of 1 BTC against other currencies floats around based on what people are willing to pay, but that's a different thing entirely. - Gordon > Or do I just need to change my bifocals? Or my meds. Or both. > > ...ken... _______________________________________________ FoRK > mailing list http://xent.com/mailman/listinfo/fork > > _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork ----- 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