Re: On the orthogonality of anonymity to current market demand
Chris Palmer [EMAIL PROTECTED] writes: James A. Donald writes: Further, genuinely secure systems are now becoming available, notably Symbian. What does it mean for Symbian to be genuinely secure? How was this determined and achieved? By executive fiat. Peter.
Re: Multiple passports?
Bill Stewart wrote: When I saw the title of this thread, I was assuming it would be about getting Mozambique or Sealand or other passports of convenience or coolness-factor like the Old-School Cypherpunks used to do :-) Actually the only passports that are significantly more convenient than US or UK ones (i.e. are more likely to get you in to more places with less fuss from locals in dark glasses) are from the northern European states without a reputation as colonialists - in particular Scandinavian countries Ireland. Everyone likes them. I know plenty of people who used to keep both an Irish and a British passport. Unlike you picky Americans our governments don't have any objection to people being citizens of as many places as they an get away with. And in the days of emigration (all has changed now) you could get an Irish passport if your granny had once spent a wet weekend in Downpatrick. All our passports are being assimilated into EU ones at the moment so I don't know if this has changed. We used to do the Israel/everywhere else thing as well and also would issue spare passports for other places that were unpopular. IIRC Pakistan at one time looked askance at passports that had been to India. South African visitors weren't popular in many countries. And I'm pretty sure that Britain sometimes issued spares to people who wanted to go to the USA after visiting Cuba or Iran (both increasingly popular holiday destinations from here) I strongly suspect that this has changed now that UK pass laws are taken as dictation from the USA.
[EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
- Forwarded message from Kerry Bonin [EMAIL PROTECTED] - From: Kerry Bonin [EMAIL PROTECTED] Date: Mon, 31 Oct 2005 07:25:20 -0800 To: Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] Frank, In my experience w/ pretty hardcore authentication and security domains, it is pretty much impossible to guarantee that a remote node connecting over an untrusted network is running trusted code. For every clever way to try and detect a compromised client, there are even more clever ways to subvert the detection process. The simplest model - simply reverse engineer the network traffic via packet capture, and write a client that looks identical from the network traffic. One example of a common client validation approach is requesting a strong checksum of some random range of the client or its dataset, but this is pretty trivial to circumvent once you have a complete copy of the client and have reverse engineered its checksum algorithm. In my experience, if you really care about what your node are doing, then NEVER trust ANY node - validate every bit of every packet. If you are trying to catch compromised nodes, there are clever ways to do that - build heuristic models that examine what nodes are doing, and forward captures to admin nodes for human analysis for heuristic refinement and analysis of what your attackers are up to. While it is in theory impossible to allow users to do anything and still catch a user doing something they're not supposed to, it may be possible to specify terms in your EULA that define constraints users would not typically violate, and respond with penalties that are not too strong for the corner cases where a user triggers a false positive by crossing the line. An example of this in the file sharing domain would be temporary bans on nodes that initiated too many searches in some time frame, suggesting spidering. On the other hand, clever counter-heuristics and large numbers of zombies can defeat most heuristics - see SPAM for many examples... Kerry Frank Moore wrote: Matthew Kaufman wrote: I think what you're asking here is is it possible to design a p2p network such that the peers must be running the official code that does the right thing, instead of running some subverted code that does something 'wrong'? Matthew, Very eloquently put. Yes, this is exactly what I was asking. We supply the client as well as the server and we just need to make sure that any client that joins the network is our client and not a 'rogue'. The one exception is that you *can* in some cases design the network such that peers that don't behave properly are shunned or dropped by the rest of the network, assuming that such behavior is detectable. For instance, in a distributed file store, you could store test data and see if it sticks around... If it doesn't, that peer is cheating. We have a way (we think) of authenticating the stream put out by a peer, so we can catch a 'rogue' client this way, but it seems more logical to prevent someone from logging into the network in the first place. Thanks for your help, Frank. ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ___ p2p-hackers mailing list [EMAIL PROTECTED] 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 message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: On the orthogonality of anonymity to current market demand
James A. Donald writes: Further, genuinely secure systems are now becoming available, notably Symbian. What does it mean for Symbian to be genuinely secure? How was this determined and achieved? -- http://www.eff.org/about/staff/#chris_palmer signature.asc Description: Digital signature
Re: packet traffic analysis
I very much doubt it. Where did that factor of half come frome. During lulls, you are constantly sending chaff packets. On average, you're halfway through transmitting a chaff packet when you want to send a real one. The system has to wait for it to finish before sending another. QED. Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis. I'm talking about a stream, with packets embedded in it. For circuit-switched circuits, this is no problem. For a packet-switched network, you must packetize the stream, which is unrelated to the packets embedded in the stream. This is somewhat inefficent, which is why I suggested that it is more applicable ot something like PPP, SSH, or OpenVPN links, which are already virtual circuits. This is a fair criticism, but just think of the number of such circuit/packet conversions when someone uses a TCP virtual circuit over packet-based IP over an analog POTS link, which is itself a virtual circuit that is packetized and sent over a circuit (long-haul wirepair or fiber) in the telco network. If you explain to me how an eavesdropper can tell where plaintext packet begins or ends, then I'll agree with you that it is indeed vulnerable to length analysis. A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed. That might or might not be a problem. With ECB, it's vulnerable to analysis (chaff is constant, so encryption of it is constant). With some modes, the amount you can transmit is limited (e.g. CTR mode). Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. It could very well be that it's a bad idea to send a lot of constant plaintext under other modes, as well. For example, if most of the data is constant, then you have a close approximation of known-plaintext. The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary. It's not necessary to run a PRNG on the receiver. You just have to be able to tell when you're looking at random data, or an encrypted version of an escape sequence and a valid packet, which can be recognized, as per your point 4a. If you find that it's not a legitimate packet, you treat it as PRNG data, and start looking for the encrypted escape sequence. However, with a 32-bit escape sequence, the chances of getting such a false positive are low. I personally think sending encrypted versions of constant data under the same key you use for real data is not crazy, but somewhat imprudent. Do you know what the unicity distance is? Have you read of attacks that require a large amount of ciphertext encrypted under the same key? -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: Multiple passports?
Bill Stewart wrote: When I saw the title of this thread, I was assuming it would be about getting Mozambique or Sealand or other passports of convenience or coolness-factor like the Old-School Cypherpunks used to do :-) Actually the only passports that are significantly more convenient than US or UK ones (i.e. are more likely to get you in to more places with less fuss from locals in dark glasses) are from the northern European states without a reputation as colonialists - in particular Scandinavian countries Ireland. Everyone likes them. I know plenty of people who used to keep both an Irish and a British passport. Unlike you picky Americans our governments don't have any objection to people being citizens of as many places as they an get away with. And in the days of emigration (all has changed now) you could get an Irish passport if your granny had once spent a wet weekend in Downpatrick. All our passports are being assimilated into EU ones at the moment so I don't know if this has changed. We used to do the Israel/everywhere else thing as well and also would issue spare passports for other places that were unpopular. IIRC Pakistan at one time looked askance at passports that had been to India. South African visitors weren't popular in many countries. And I'm pretty sure that Britain sometimes issued spares to people who wanted to go to the USA after visiting Cuba or Iran (both increasingly popular holiday destinations from here) I strongly suspect that this has changed now that UK pass laws are taken as dictation from the USA.
Re: Multiple passports?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Gutmann wrote: Gregory Hicks [EMAIL PROTECTED] writes: As for applying for one now, I think the deadline for the non-RFID passwords is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if your application is not in processing by 31 Oct, then you get the new, improved, RFID passport.) Ahh, but if you get one of the first passports issued then there are likely to still be some teething problems present, leading to sporadic failures of the first batch of RFID devices. I have a funny feeling that this is going to happen to my new passport when it arrives. Peter. I don't have a good feeling about this at all. My passport is actually invalid as a form of ID for anyone who checks closely(the BMV did!) because the gov't printed the wrong birthdate on mine! I went to Germany and back just after the embassy attacks in africa(things were on high alert briefly then) with no questions on it. Try to renew my lost drivers license with it and suddenly its a damn problem. As far as I can tell, they used the month of issue as the birth month as well. A small mistake...but obviously an important one. What ways do you suppose there will be for them to screw up these RFID tags? These days ones libel to get branded a terrorist with the wrong info... - -- Chris Clymer - [EMAIL PROTECTED] PGP: E546 19B6 D1EC 47A7 CAA0 8623 C807 398C CD27 15B8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.7 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDZnnuyAc5jM0nFbgRAvBaAKDFUH2QFmKJqIk7WYkw5esWUy/MsACgwWvH iHYKEguTdSdU0wRTIeI4lZg= =UyJk -END PGP SIGNATURE- begin:vcard fn:Chris Clymer n:Clymer;Chris org:Youngstown Linux User Group adr:;;252 Colonial Drive;Canfield;Ohio;44406;United States of America email;internet:[EMAIL PROTECTED] title:Founder tel;cell:330.507.3651 x-mozilla-html:FALSE url:http://www.chrisclymer.com version:2.1 end:vcard
Re: packet traffic analysis
Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. My mistake, OFB does not have this property. I thought there was a common mode with this property, but it appears that I am mistaken. If it makes you feel any better, you can consider the PRNG the encryption of constant text, perhaps using the real datastream as some kind of IV. The content of the chaff is not relevant; ideally you would use a high-bandwidth HWRNG such as Quantis. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: On the orthogonality of anonymity to current market demand
Chris Palmer [EMAIL PROTECTED] writes: James A. Donald writes: Further, genuinely secure systems are now becoming available, notably Symbian. What does it mean for Symbian to be genuinely secure? How was this determined and achieved? By executive fiat. Peter.
Re: On the orthogonality of anonymity to current market demand
James A. Donald writes: Further, genuinely secure systems are now becoming available, notably Symbian. Chris Palmer [EMAIL PROTECTED] What does it mean for Symbian to be genuinely secure? How was this determined and achieved? There is no official definition of genuinely secure, and it is my judgment that Symbian is unlikely to suffer the worm, virus and trojan problems to the extent that has plagued other systems.
Re: packet traffic analysis
In the context of: If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis. Travis H. wrote: I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet. I very much doubt it. Where did that factor of half come frome. I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis. I've seen analysis systems that do exactly this. So the question is, are you trying to thwart traffic analysis, or not? I should point out that encrypting PRNG output may be pointless, *is* pointless, as previously discussed. and perhaps one optimization is to stop encrypting when switching on the chaff. A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed. Some minor details involving resynchronizing when the PRNG happens to The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary.
RE: [EMAIL PROTECTED]: Skype security evaluation]
A similar approach enabled Bleichenbacher's SSL attack on RSA with PKCS#1 padding. This sounds very dangerous to me. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk Sent: Friday, October 28, 2005 5:07 AM To: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: [EMAIL PROTECTED]: Skype security evaluation] Wasn't there a rumor last year that Skype didn't do any encryption padding, it just did a straight exponentiation of the plaintext? Would that be safe, if as the report suggests, the data being encrypted is 128 random bits (and assuming the encryption exponent is considerably bigger than 3)? Seems like it's probably OK. A bit risky perhaps to ride bareback like that but I don't see anything inherently fatal. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Passport Hell (was [Clips] Re: [duodenalswitch] Re: Konstantin)
--- begin forwarded text Delivered-To: [EMAIL PROTECTED] Date: Mon, 31 Oct 2005 09:55:05 -0500 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] Re: [duodenalswitch] Re: Konstantin Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] --- begin forwarded text Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Mailing-List: list [EMAIL PROTECTED]; contact [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Date: Mon, 31 Oct 2005 09:11:08 EST Subject: Re: [duodenalswitch] Re: Konstantin Reply-To: [EMAIL PROTECTED] it was time to renew my passport again (2nd renewal ,,not first) ..cause I want to go to Curitiba, Brasil in June to have my hernia repair and get some PS with Dr. C for loose skin and muscles... (a face lift would be nice hmmm) So I applied like everyone else does submit old passport with application, ... I get a letter back from the Department of Homeland Security that says I am refused because there is not enough info to prove my identity Thats all the proof normally required. They tell me with any further application to submit four documents all created b4 1985. (b4 1985??? jessh!) So I do... my Birth Certificate ...my daughters B-certificate (cause my name is on it), my first marriage certificate, my first divorce papers and an original payroll register from the company I worked for in 1984 (with all my vitals on it). They then turned me down again saying its just not enough proof () And they were the ones who requested them. They have now asked me for ... all my medical records from before 1995, my second marriage certificate, all my school transcripts from 1959 till high school graduation, and a voter registration certificate from 1994. I also asked congressman Tom Lantos to intervene on my behalf and he tried..and they told him (nicely) to mind his own business I think I am to be trapped within this gilded cage forever I was to be sent by my corporation to China to represent them there (in January)... but apparently not now and it also looks like I will have to save up alot of money to have my PS done here in the states so I guess the Face lift is out I wonder if Dr. C does house calls? Sad, frustrated and Depressed Konstantin If you don't mind me asking, why are they rejecting your renewal? I have a friend who is an immigration attorney and I know he will ask when I bring it up to him. You can email me privately if you prefer. Jennifer --- In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I would love to learn the Rapier and archery... But right now I would settle for the Department of homeland Security to stop rejecting my Passport renewal forms and let me travel (sigh) Any one know a good reverse immigration attorney? Blessed be Konstantin [Non-text portions of this message have been removed] Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/duodenalswitch/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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' ___ Clips mailing list [EMAIL PROTECTED] http://www.philodox.com/mailman/listinfo/clips --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: On the orthogonality of anonymity to current market demand
hi ( 05.10.26 09:17 -0700 ) James A. Donald: While many people are rightly concerned that DRM will ultimately mean that the big corporation, and thus the state, has root access to their computers and the owner does not, it also means that trojans, viruses, and malware does not. do you really think this is true? doesn't microsoft windows prove that remote control of computers only leads to compromise? [especially in our heavily networked world] and doesn't history show that big corporations are only interested in revenue- so that if they get revenue by forcing you to pay them fees for 'upkeep' of your digital credentials to keep your computer working they are going to do that. the problems 'solved' by DRM can also be solved by moving to an operating system where you have control of it, instead of an operating system filled with hooks so other people can control your computer. and that operating system is freely available ... -- \js oblique strategy: don't be frightened of cliches
Re: On the orthogonality of anonymity to current market demand
At 10:22 AM -0500 10/31/05, [EMAIL PROTECTED] wrote: and doesn't history show that big corporations are only interested in revenue One should hope so. ;-) Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: Multiple passports?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Gutmann wrote: Gregory Hicks [EMAIL PROTECTED] writes: As for applying for one now, I think the deadline for the non-RFID passwords is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if your application is not in processing by 31 Oct, then you get the new, improved, RFID passport.) Ahh, but if you get one of the first passports issued then there are likely to still be some teething problems present, leading to sporadic failures of the first batch of RFID devices. I have a funny feeling that this is going to happen to my new passport when it arrives. Peter. I don't have a good feeling about this at all. My passport is actually invalid as a form of ID for anyone who checks closely(the BMV did!) because the gov't printed the wrong birthdate on mine! I went to Germany and back just after the embassy attacks in africa(things were on high alert briefly then) with no questions on it. Try to renew my lost drivers license with it and suddenly its a damn problem. As far as I can tell, they used the month of issue as the birth month as well. A small mistake...but obviously an important one. What ways do you suppose there will be for them to screw up these RFID tags? These days ones libel to get branded a terrorist with the wrong info... - -- Chris Clymer - [EMAIL PROTECTED] PGP: E546 19B6 D1EC 47A7 CAA0 8623 C807 398C CD27 15B8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.7 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDZnnuyAc5jM0nFbgRAvBaAKDFUH2QFmKJqIk7WYkw5esWUy/MsACgwWvH iHYKEguTdSdU0wRTIeI4lZg= =UyJk -END PGP SIGNATURE- begin:vcard fn:Chris Clymer n:Clymer;Chris org:Youngstown Linux User Group adr:;;252 Colonial Drive;Canfield;Ohio;44406;United States of America email;internet:[EMAIL PROTECTED] title:Founder tel;cell:330.507.3651 x-mozilla-html:FALSE url:http://www.chrisclymer.com version:2.1 end:vcard
Re: On the orthogonality of anonymity to current market demand
James A. Donald writes: Further, genuinely secure systems are now becoming available, notably Symbian. What does it mean for Symbian to be genuinely secure? How was this determined and achieved? -- http://www.eff.org/about/staff/#chris_palmer signature.asc Description: Digital signature
Re: On the orthogonality of anonymity to current market demand
James A. Donald writes: Further, genuinely secure systems are now becoming available, notably Symbian. Chris Palmer [EMAIL PROTECTED] What does it mean for Symbian to be genuinely secure? How was this determined and achieved? There is no official definition of genuinely secure, and it is my judgment that Symbian is unlikely to suffer the worm, virus and trojan problems to the extent that has plagued other systems.
Re: packet traffic analysis
I very much doubt it. Where did that factor of half come frome. During lulls, you are constantly sending chaff packets. On average, you're halfway through transmitting a chaff packet when you want to send a real one. The system has to wait for it to finish before sending another. QED. Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis. I'm talking about a stream, with packets embedded in it. For circuit-switched circuits, this is no problem. For a packet-switched network, you must packetize the stream, which is unrelated to the packets embedded in the stream. This is somewhat inefficent, which is why I suggested that it is more applicable ot something like PPP, SSH, or OpenVPN links, which are already virtual circuits. This is a fair criticism, but just think of the number of such circuit/packet conversions when someone uses a TCP virtual circuit over packet-based IP over an analog POTS link, which is itself a virtual circuit that is packetized and sent over a circuit (long-haul wirepair or fiber) in the telco network. If you explain to me how an eavesdropper can tell where plaintext packet begins or ends, then I'll agree with you that it is indeed vulnerable to length analysis. A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed. That might or might not be a problem. With ECB, it's vulnerable to analysis (chaff is constant, so encryption of it is constant). With some modes, the amount you can transmit is limited (e.g. CTR mode). Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. It could very well be that it's a bad idea to send a lot of constant plaintext under other modes, as well. For example, if most of the data is constant, then you have a close approximation of known-plaintext. The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary. It's not necessary to run a PRNG on the receiver. You just have to be able to tell when you're looking at random data, or an encrypted version of an escape sequence and a valid packet, which can be recognized, as per your point 4a. If you find that it's not a legitimate packet, you treat it as PRNG data, and start looking for the encrypted escape sequence. However, with a 32-bit escape sequence, the chances of getting such a false positive are low. I personally think sending encrypted versions of constant data under the same key you use for real data is not crazy, but somewhat imprudent. Do you know what the unicity distance is? Have you read of attacks that require a large amount of ciphertext encrypted under the same key? -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. My mistake, OFB does not have this property. I thought there was a common mode with this property, but it appears that I am mistaken. If it makes you feel any better, you can consider the PRNG the encryption of constant text, perhaps using the real datastream as some kind of IV. The content of the chaff is not relevant; ideally you would use a high-bandwidth HWRNG such as Quantis. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/28/05, Daniel A. Nagy [EMAIL PROTECTED] wrote: Irreversibility of transactions hinges on two features of the proposed systetm: the fundamentally irreversible nature of publishing information in the public records and the fact that in order to invalidate a secret, one needs to know it; the issuer does not learn the secret at all in some implementnations and only learns it when it is spent in others. In both cases, reversal is impossible, albeit for different reasons. Let's say, Alice made a payment to Bob, and Ivan wishes to reverse it with the possible cooperation of Alice, but definitely without Bob's help. Alice's secret is Da, Bob's secret is Db, the corresponding challenges are, respectively, Ca and Cb, and the S message containing the exchange request Da-Cb has already been published. In the first case, when the secret is not revealed, there is simply no way to express reverslas. There is no S message with suitable semantics semantics, making it impossible to invalidate Db if Bob refuses to reveal it. The issuer can still invalidate it even though you have not explicitly defined such an operation. If Alice paid Bob and then convinces the issuer that Bob cheated her, the issuer could refuse to honor the Db deposit or exchange operation. From the recipient's perspective, his cash is at risk at least until he has spent it or exchanged it out of the system. The fact that you don't have an issuer invalidates cash operation in your system doesn't mean it couldn't happen. Alice could get a court order forcing the issuer to do this. The point is that reversal is technically possible, and you can't define it away just by saying that the issuer won't do that. If the issuer has the power to reverse transactions, the system does not have full ireversibility, even though the issuer hopes never to exercise his power. In the second case, Db is revealed when Bob tries to spend it, so Ivan can, in principle, steal (confiscate) it, instead of processing, but at that point Da has already been revealed to the public and Alice has no means to prove that she was in excusive possession of Da before it became public information. That is an interesting possibility, but I can think of a way around it. Alice could embed a secret within her secret. She could base part of her secret on a hash of an even-more-secret value which she would not reveal when spending/exchanging. Then if it came to where she had to prove that she was the proper beneficiary of a reversed transaction, she could reveal the inner secret to justify her claim. Now, one can extend the list of possible S messages to allow for reversals in the first scenario, but even in that case Ivan cannot hide the fact of reversal from the public after it happened and the fact that he is prepared to reverse payments even before he actually does so, because the users and auditors need to know the syntax and the semantics of the additional S messages in order to be able to use Ivan's services. That's true, the public visibility of the system makes secret reversals impossible. That's very good - one of the problems with e-gold was that it was never clear when they were reversing and freezing accounts. Visibility is a great feature. But it doesn't keep reversals from happening, and it still leaves doubt about how final transactions will be in this system. CP
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
On Sat, Oct 29, 2005 at 08:42:35PM -0400, Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. Actually, an RFID can be ridiculously reliable. It will also depend on how much harassment a traveler will be exposed to, when travelling. Being barred from entry will definitely prove sufficient deterrment. The only question is, what could (believably) damage the RFID? Microwaving it will blow up the chip, and cause a scorched spot. Severing the antenna would be enough for the chip to become mute. Violetwanding or treating with a Tesla generator should destroy all electronics quite reliably -- you always have to check, of course. Also, the ID is quite expensive, and a frequent traveller will wind up with a considerable expense, and hassle. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Return of the death of cypherpunks.
From: James A. Donald [EMAIL PROTECTED] Sent: Oct 28, 2005 12:09 PM To: [EMAIL PROTECTED] Subject: Return of the death of cypherpunks. From: Eugen Leitl [EMAIL PROTECTED] .. The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist. Well, political controversy seems like the least interesting thing about the list--to the extent we're all babbling about who needs killing and who's not a sufficiently pure libertarian/anarchocapitalist and which companies are selling out to the Man, the list is nothing special. The cool thing is the understanding of crypto and computer security techology as applied to these concerns that are political. And the coolest thing is getting smart people who do real crypto/security work, and write working code, to solve problems. The ratio of political wanking to technical posts and of talkers to thinkers to coders needs to be right for the list to be interesting. .. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb --John Kelsey
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
At 01:31 AM 10/30/05 -0700, Bill Stewart wrote: They've said they'll fall back on the traditional If we can't read the passport it's invalid and you'll need to replace it before we'll let you leave the country technique, just as they often do with expired passports and sometimes What is the procedure (or are they secret :-) for passports which become damaged whilst travelling out of country? With a drivers license, if the magstrip doesn't work, they type in the numbers. But the biometrics are not encoded, its just a convenience. With a passport, they're relying on the chip or no? (Mechanical damage to the chip should work as well as RF or antenna damage. You will have to find the chip and crack it, mere flexing of the paper carrier doesn't work by design.)
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. The only question is, what could (believably) damage the RFID? EMP? Could be tuned, even, since the RFID is resonant at a known frequency. There's a standard for excitation field strength, so all one should need to do would be hit the chip with 50-100x the expected input. Unless the system is shunted with a zener or some such, you should be able to fry it pretty easily. Now put that chip-cooker in a trash can right by the main entrance to an airport and perform some public service. -- Roy M. Silvernail is [EMAIL PROTECTED], and you're not It's just this little chromium switch, here. - TFT Dspam-pprocmail-/dev/null-bliss http://www.rant-central.com
RE: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. The only question is, what could (believably) damage the RFID? -TD From: Eugen Leitl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv]] Date: Sat, 29 Oct 2005 20:54:13 +0200 - Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Fri, 28 Oct 2005 17:49:06 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Edward Hasbrouck [EMAIL PROTECTED] Date: October 28, 2005 11:07:28 AM EDT To: [EMAIL PROTECTED] Subject: Re: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv] From: Lin, Herb [EMAIL PROTECTED] *Front* cover? Does that mean that if I hold the passport the wrong way, the skimmer will have a free ride? FWIW: (1) The sample RFID passports that Frank Moss passed around at CFP, which looked like http://travel.state.gov/passport/eppt/eppt_2501.html, had the RFID chip (which was barely detectable by feel) in the *back* cover. The visible data page was/is, as with current passports, in the *front* cover. This is not compliant with the ICAO specifications, which recommend having the chip in the same page as the visible data, to make it more difficult to separate them. I can only guess that it was hard to laminate the visible data without damaging the chip, if it was in the same page. But it's interesting in light of the importance supposedly being placed on compliance with ICAO standards. (2) Moss had 2 sample RFID passports, 1 with and 1 without the shielding. He cliamed it was a layer in the entire outer cover (front and back), but it wasn't detectable by feel. I have more threat scenarios for the latest flavor of RFID passport at: http://hasbrouck.org/blog/archives/000869.html Edward Hasbrouck [EMAIL PROTECTED] http://hasbrouck.org +1-415-824-0214 - You are subscribed as [EMAIL PROTECTED] 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 __ ICBM: 48.07100, 11.36820http://www.leitl.org 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]
Re: Multiple passports?
On Sun, Oct 30, 2005 at 03:05:25AM +, Justin wrote: If I apply for a new one now, and then apply for a another one once the gov starts RFID-enabling them, will the first one be invalidated? Or can I have two passports, the one without RFID to use, and the one with RFID to play with? Here in Germany the current ID (sans smartcard/rfid/biometics) will be valid until expiry date. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Any comments on BlueGem's LocalSSL?
At 11:10 AM -0700 10/28/05, James A. Donald wrote: I am a reluctant convert to DRM. At least with DRM, we face a smaller number of threats. I have had it explained to me, many times more than I want to remember, :-), that strong crypto is strong crypto. It's not that I'm unconvinceable, but I'm still unconvinced, on the balance. OTOH, if markets overtake the DRM issue, as most cypherpunks I've talked to think, then we still have lots of leftover installed crypto to play around with. Cheers, RAH Who still thinks that digital proctology is not the same thing as financial cryptography. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: Multiple passports?
Gregory Hicks [EMAIL PROTECTED] writes: As for applying for one now, I think the deadline for the non-RFID passwords is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if your application is not in processing by 31 Oct, then you get the new, improved, RFID passport.) Ahh, but if you get one of the first passports issued then there are likely to still be some teething problems present, leading to sporadic failures of the first batch of RFID devices. I have a funny feeling that this is going to happen to my new passport when it arrives. Peter.
Re: Blood, Bullets, Bombs and Bandwidth
On 2005-10-22T01:51:50-0400, R.A. Hettinga wrote: --- begin forwarded text Tyler and Jayme left Iraq in May 2005. The Arbil office failed; there wasn't enough business in Kurdistan. They moved to London, where Tyler still works for SSI. His time in Iraq has transformed him to the extent that, like Ryan, he doesn't think he can ever move back to the USA. His years of living hyperintensely, carrying a gun, building an organization from scratch in a war zone, have distanced him from his home. His friends seem to him to have stagnated. Their concerns seem trivial. And living with real, known, tangible danger has bred contempt for what he calls America's culture of fear. Tyler likes the high-speed lifestyle so much that he ditched it and moved to London? I doubt he's carrying a gun there. -- The six phases of a project: I. Enthusiasm. IV. Search for the Guilty. II. Disillusionment. V. Punishment of the Innocent. III. Panic.VI. Praise Honor for the Nonparticipants.
RE: Return of the death of cypherpunks.
I don't agree. One thing we do know is that, although Crypto is available and, in special contexts, used, it's use in other contexts is almost counterproduct, sending up a red flag so that those that Protect Our Freedoms will come sniffing around and bring to bear their full arsenal of technologies and, possibly, dirty tricks. Merely knowing that you are using stego/crypto in such contexts can cause a lot of attention come your way, possibly in actual meatspace, which in many cases is almost worse than not using crypto at all In addition, although strong and unbreakable Crypto exists, one thing a stint on Cypherpunks teaches you is that it is only rarely implemented in such a way as to actually be unbreakable to a determined attacker, particularly if there are not many such cases to examine in such contexts. The clear moral of this story is that, to increase the odds of truly secure communication, etc, Crypto in such contexts must become much more ubiquitous, and I still think Cypherpunks has a role to play there and indeed has played that role. Such a role is, of course, far more than a mere cheerleading role,a fact that merits a continued existence for Cypherpunks in some form or another. -TD Only when Crypto is used ubiquitousl From: James A. Donald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Return of the death of cypherpunks. Date: Fri, 28 Oct 2005 12:09:36 -0700 -- From: Eugen Leitl [EMAIL PROTECTED] While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that needs killing thing (okay, it was funny for a while). The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist. I recently read up on the Kerberos protocol, and thought, how primitive. Back in the bad old days, we did everything wrong, because we did not know any better. And of course, https sucks mightily because the threat model is both inappropriate to the real threats, and fails to correspond to the users mental model, or to routine practices on a wide variety of sites, hence users glibly click through all warning dialogs, most of which are mere noise anyway. These problems, however, are no explicitly political, and tend to be addressed on lists that are not explicitly political, leaving cypherpunks with little of substance. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb
Re: Return of the death of cypherpunks.
-- James A. Donald: Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist. John Kelsey The ratio of political wanking to technical posts and of talkers to thinkers to coders needs to be right for the list to be interesting. These days, if one is seriously working on overthrowing the state by advancing to crypto anarchy (meaning both anarchy that is hidden, in that large scale cooperation procedes without the state taxing it, regulating it, supervising it, and licensing it, and anarchy that relies on cryptography to resist the state) it is not necessary or advisable to announce what one is up to. For example, Kerberos needs to be replaced by a more secure protocol. No need to add And I am concerned about this because I am an anarchist And so one discusses it on another list. (Kerberos tickets are small meaningful encrypted packets of information, when they should be random numbers. Being small, they can be dictionary attacked.) --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Y068Cy3Zv9GExXRbP24QJP5WmHGLz5VKyqNYFKbx 45fkOIGeiTkFnaM7p/URjB/kgn+0mcg8fMsMLmDy7
Re: Any comments on BlueGem's LocalSSL?
At 7:51 PM -0400 10/28/05, R.A. Hettinga wrote: OTOH, if markets overtake the DRM issue, ^ moot, was what I meant to say... Anyway, you get the idea. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: Multiple passports?
Date: Sun, 30 Oct 2005 03:05:25 + From: Justin [EMAIL PROTECTED] If I apply for a new one now, and then apply for a another one once the gov starts RFID-enabling them, will the first one be invalidated? Or can I have two passports, the one without RFID to use, and the one with RFID to play with? I am not a State Dept person, but my experiences in this are... If you get a new one, the old one has to accompany the application and is invalidated when the new one is issued. (Invalidated by stamping the 'data' page with big red block letters INVALID.) The old, now invalid is returned with the new one... The only people that I knew that had two passports were those with an Official (red) passport or a Diplomatic (black) passport. If they wanted to go play tourist, they had to also have a tourist (Blue) passport. As for applying for one now, I think the deadline for the non-RFID passwords is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if your application is not in processing by 31 Oct, then you get the new, improved, RFID passport.) Regards, Gregory Hicks -- The six phases of a project: I. Enthusiasm. IV. Search for the Guilty. II. Disillusionment. V. Punishment of the Innocent. III. Panic.VI. Praise Honor for the Nonparticipants. - I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
At 01:42 AM 10/30/2005, Roy M. Silvernail wrote: Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. They've said they'll fall back on the traditional If we can't read the passport it's invalid and you'll need to replace it before we'll let you leave the country technique, just as they often do with expired passports and sometimes do with just-about-to-expire passports if you're a Suspicious-Acting Person like Dave del Torto. The only question is, what could (believably) damage the RFID? If you want to damage the RFID of a passport you're playing with, microwave ovens should do just fine. I don't know if Rivest's RFID-blocker chips use the same frequency or codespace as the passport RFIDs, but you could also leave one of them in the back of your passport. Now put that chip-cooker in a trash can right by the main entrance to an airport and perform some public service. I'd be surprised if you could put out enough energy to cook the passport RFIDs of people walking by at normal speed without also causing lots of other electrical problems.
Re: Multiple passports?
On 10/30/05, Gregory Hicks [EMAIL PROTECTED] wrote: The only people that I knew that had two passports were those with an Official (red) passport or a Diplomatic (black) passport. If they wanted to go play tourist, they had to also have a tourist (Blue) passport. I wasn't able to find a reference to support this on http://state.gov, but I know it's possible to get two passports if you plan to travel to both Israel and a country that refuses to admit people with Israeli stamps in their passports. /jgt
Re: Multiple passports?
When I saw the title of this thread, I was assuming it would be about getting Mozambique or Sealand or other passports of convenience or coolness-factor like the Old-School Cypherpunks used to do :-) On 10/30/05, Gregory Hicks [EMAIL PROTECTED] wrote: The only people that I knew that had two passports were those with an Official (red) passport or a Diplomatic (black) passport. If they wanted to go play tourist, they had to also have a tourist (Blue) passport. A few years ago, before heading on an overseas trip, I was unable to locate my current passport. After dealing with a voicemail system adapted from a Kafka novel, and bringing myself, my previous expired passport and other id, a couple official-sized photographs and cash through the secret-handshake elevator into a big waiting room for a long morning, they made me a new passport. (If you need to replace a passport more than a month before your planned travel, you're supposed to use the regular process at the Post Office and maybe pay extra for Express Mail if you're impatient. If you need to replace a passport within 3 days of travel, they've got expedited processes at major passport offices like San Francisco. But if you need to replace your passport two weeks before the trip, there's no way to talk to a human being, just Kafka's voicemailbot, so you have to wait until 3 days before the trip to get an appointment for the emergency expedited process instead of going in when you and they aren't busy :-) They informed me that the lost passport was now invalid and I should turn it in if I find it, because if I were to use it to get back into the country it would be rejected with extreme prejudice, since its number is now on the lost passports list. Of course the next day when I was packing, the passport showed up on the closet floor under the suitcase, and unlike the previous passport which I took in to replace when it was about to expire, it doesn't have holes punched in it and Expired stamped on it. For domestic air travel since the recent military coup, I normally bring a passport as ID, since it's a request from the former United States government asking foreign governments like the current TSA White People to let me pass, and I'd rather carry the technically-invalid one with me instead of the valid one just in case I lose it. I think I've also used it to travel from the EU back to the US, but I'd expect that the La Migra thugs will eventually improve their databases, possibly even before my old one expires, especially because Homeland Security wants to RFIDize us. I was considering losing my current passport before the RFID things get started, but it doesn't look like there's time, so I've got about 5 years to hope that the Republicans get thrown out on their asses in the next election and the Democrats decide that returning to the Constitution will sell better than continuing the Permanent State of Yellowalertness. Given the previous Clinton Administration's behavior, I don't expect the Hillary Clinton Administration to do any better. At 09:27 PM 10/29/2005, Jay Goodman Tamboli wrote: I wasn't able to find a reference to support this on http://state.gov, but I know it's possible to get two passports if you plan to travel to both Israel and a country that refuses to admit people with Israeli stamps in their passports. I don't think the US normally lets you have two passports, or if they do they almost certainly have the same number. But at least during the 1980s, Israel would be happy to give you a separate piece of paper with to carry with your passport that they'd stamp when you entered and left instead of stamping the passport itself. I don't remember if I did that or if I decided not to worry about it because I'd visited the Arab countries before going to Israel and didn't expect to get back any time soon.
RE: [EMAIL PROTECTED]: Skype security evaluation]
A similar approach enabled Bleichenbacher's SSL attack on RSA with PKCS#1 padding. This sounds very dangerous to me. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk Sent: Friday, October 28, 2005 5:07 AM To: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: [EMAIL PROTECTED]: Skype security evaluation] Wasn't there a rumor last year that Skype didn't do any encryption padding, it just did a straight exponentiation of the plaintext? Would that be safe, if as the report suggests, the data being encrypted is 128 random bits (and assuming the encryption exponent is considerably bigger than 3)? Seems like it's probably OK. A bit risky perhaps to ride bareback like that but I don't see anything inherently fatal. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: packet traffic analysis
I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. I should point out that encrypting PRNG output may be pointless, and perhaps one optimization is to stop encrypting when switching on the chaff. The peer can then encrypt the escape sequence as it would appear in the encrypted stream, and do a simple string match on that. In this manner the peer does not have to do any decryption until the [encrypted] escape sequence re-appears. Another benefit of this is to limit the amount of material encrypted under the key to legitimate traffic and the escape sequences prefixing them. Some minor details involving resynchronizing when the PRNG happens to produce the same output as the expected encrypted escape sequence is left as an exercise for the reader. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
One other point with regard to Daniel Nagy's paper at http://www.epointsystem.org/~nagydani/ICETE2005.pdf A good way to organize papers like this is to first present the desired properties of systems like yours (and optionally show that other systems fail to meet one or more of these properties); then to present your system; and finally to go back through and show how your system meets each of the properties, perhaps better than any others. This paper is lacking that last step. It would be helpful to see the epoint system evaluated with regard to each of the listed properties. In particular I have concerns about the finality and irreversibility of payments, given that the issuer keeps track of each token as it progresses through the system. Whenever one token is exchanged for a new one, the issuer records and publishes the linkage between the new token and the old one. This public record is what lets people know that the issuer is not forging tokens at will, but it does let the issuer, and possibly others, track payments as they flow through the system. This could be grounds for reversibility in some cases, although the details depend on how the system is implemented. It would be good to see a critical analysis of how epoints would maintain irreversibility, as part of the paper. CP
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On Fri, Oct 28, 2005 at 02:18:43PM -0700, cyphrpunk wrote: In particular I have concerns about the finality and irreversibility of payments, given that the issuer keeps track of each token as it progresses through the system. Whenever one token is exchanged for a new one, the issuer records and publishes the linkage between the new token and the old one. This public record is what lets people know that the issuer is not forging tokens at will, but it does let the issuer, and possibly others, track payments as they flow through the system. This could be grounds for reversibility in some cases, although the details depend on how the system is implemented. It would be good to see a critical analysis of how epoints would maintain irreversibility, as part of the paper. I agree, this discussion is missing, indeed. I will definitely include it, should I write another paper on the subject. Irreversibility of transactions hinges on two features of the proposed systetm: the fundamentally irreversible nature of publishing information in the public records and the fact that in order to invalidate a secret, one needs to know it; the issuer does not learn the secret at all in some implementnations and only learns it when it is spent in others. In both cases, reversal is impossible, albeit for different reasons. Let's say, Alice made a payment to Bob, and Ivan wishes to reverse it with the possible cooperation of Alice, but definitely without Bob's help. Alice's secret is Da, Bob's secret is Db, the corresponding challenges are, respectively, Ca and Cb, and the S message containing the exchange request Da-Cb has already been published. In the first case, when the secret is not revealed, there is simply no way to express reverslas. There is no S message with suitable semantics semantics, making it impossible to invalidate Db if Bob refuses to reveal it. In the second case, Db is revealed when Bob tries to spend it, so Ivan can, in principle, steal (confiscate) it, instead of processing, but at that point Da has already been revealed to the public and Alice has no means to prove that she was in excusive possession of Da before it became public information. Now, one can extend the list of possible S messages to allow for reversals in the first scenario, but even in that case Ivan cannot hide the fact of reversal from the public after it happened and the fact that he is prepared to reverse payments even before he actually does so, because the users and auditors need to know the syntax and the semantics of the additional S messages in order to be able to use Ivan's services. -- Daniel
Re: On Digital Cash-like Payment Systems
From: cyphrpunk [EMAIL PROTECTED]
Sent: Oct 27, 2005 9:15 PM
To: James A. Donald [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com, [EMAIL PROTECTED]
Subject: Re: On Digital Cash-like Payment Systems
On 10/26/05, James A. Donald [EMAIL PROTECTED] wrote:
How does one inflate a key?
Just make it bigger by adding redundancy and padding, before you
encrypt it and store it on your disk. That way the attacker who wants
to steal your keyring sees a 4 GB encrypted file which actually holds
about a kilobyte of meaningful data. Current trojans can steal files
and log passwords, but they're not smart enough to decrypt and
decompress before uploading. They'll take hours to snatch the keyfile
through the net, and maybe they'll get caught in the act.
Note that there are crypto schemes that use huge keys, and it's
possible to produce simple variants of existing schemes that use
multiple keys. That would mean that the whole 8GB string was
necessary to do whatever crypto thing you wanted to do. A simple
example is to redefine CBC-mode encryption as
C[i] = E_K(C[i-1] xor P[i] xor S[C[i-1] mod 2^{29}])
where S is the huge shared string, and we're using AES. Without
access to the shared string, you could neither encrypt nor decrypt.
CP
--John
Re: packet traffic analysis
In the context of: If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis. Travis H. wrote: I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet. I very much doubt it. Where did that factor of half come frome. I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis. I've seen analysis systems that do exactly this. So the question is, are you trying to thwart traffic analysis, or not? I should point out that encrypting PRNG output may be pointless, *is* pointless, as previously discussed. and perhaps one optimization is to stop encrypting when switching on the chaff. A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed. Some minor details involving resynchronizing when the PRNG happens to The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary.
Re: On the orthogonality of anonymity to current market demand
hi ( 05.10.26 09:17 -0700 ) James A. Donald: While many people are rightly concerned that DRM will ultimately mean that the big corporation, and thus the state, has root access to their computers and the owner does not, it also means that trojans, viruses, and malware does not. do you really think this is true? doesn't microsoft windows prove that remote control of computers only leads to compromise? [especially in our heavily networked world] and doesn't history show that big corporations are only interested in revenue- so that if they get revenue by forcing you to pay them fees for 'upkeep' of your digital credentials to keep your computer working they are going to do that. the problems 'solved' by DRM can also be solved by moving to an operating system where you have control of it, instead of an operating system filled with hooks so other people can control your computer. and that operating system is freely available ... -- \js oblique strategy: don't be frightened of cliches
Re: packet traffic analysis
Good catch on the encryption. I feel silly for not thinking of it. If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis. I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet. And then there's the bandwidth tradeoff you mention, which is probably of a larger concern (although bandwidth will increase over time, whereas the speed of light will not). I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets and creating all your chaff as packets. Let's assume the link is encrypted as before. Then you merely introduce your legitimate packets with a certain escape sequence, and pad between these packets with either zeroes, or if you're more paranoid, some kind of PRNG. In this way, if the link is idle, you can stop generating chaff and start generating packets at any time. I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. This is not a tiny hack, but avoids much of the overhead in your technique. It could easily be applied to something like openvpn, which can operate over a TCP virtual circuit, or ppp. It'd be a nice optimization if you could avoid retransmits of segments that contained only chaff, but that may or may not be possible to do without giving up some TA resistance (esp. in the presence of an attacker who may prevent transmission of segments). -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: On the orthogonality of anonymity to current market demand
At 10:22 AM -0500 10/31/05, [EMAIL PROTECTED] wrote: and doesn't history show that big corporations are only interested in revenue One should hope so. ;-) Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. The only question is, what could (believably) damage the RFID? EMP? Could be tuned, even, since the RFID is resonant at a known frequency. There's a standard for excitation field strength, so all one should need to do would be hit the chip with 50-100x the expected input. Unless the system is shunted with a zener or some such, you should be able to fry it pretty easily. Now put that chip-cooker in a trash can right by the main entrance to an airport and perform some public service. -- Roy M. Silvernail is [EMAIL PROTECTED], and you're not It's just this little chromium switch, here. - TFT Dspam-pprocmail-/dev/null-bliss http://www.rant-central.com
Re: Multiple passports?
When I saw the title of this thread, I was assuming it would be about getting Mozambique or Sealand or other passports of convenience or coolness-factor like the Old-School Cypherpunks used to do :-) On 10/30/05, Gregory Hicks [EMAIL PROTECTED] wrote: The only people that I knew that had two passports were those with an Official (red) passport or a Diplomatic (black) passport. If they wanted to go play tourist, they had to also have a tourist (Blue) passport. A few years ago, before heading on an overseas trip, I was unable to locate my current passport. After dealing with a voicemail system adapted from a Kafka novel, and bringing myself, my previous expired passport and other id, a couple official-sized photographs and cash through the secret-handshake elevator into a big waiting room for a long morning, they made me a new passport. (If you need to replace a passport more than a month before your planned travel, you're supposed to use the regular process at the Post Office and maybe pay extra for Express Mail if you're impatient. If you need to replace a passport within 3 days of travel, they've got expedited processes at major passport offices like San Francisco. But if you need to replace your passport two weeks before the trip, there's no way to talk to a human being, just Kafka's voicemailbot, so you have to wait until 3 days before the trip to get an appointment for the emergency expedited process instead of going in when you and they aren't busy :-) They informed me that the lost passport was now invalid and I should turn it in if I find it, because if I were to use it to get back into the country it would be rejected with extreme prejudice, since its number is now on the lost passports list. Of course the next day when I was packing, the passport showed up on the closet floor under the suitcase, and unlike the previous passport which I took in to replace when it was about to expire, it doesn't have holes punched in it and Expired stamped on it. For domestic air travel since the recent military coup, I normally bring a passport as ID, since it's a request from the former United States government asking foreign governments like the current TSA White People to let me pass, and I'd rather carry the technically-invalid one with me instead of the valid one just in case I lose it. I think I've also used it to travel from the EU back to the US, but I'd expect that the La Migra thugs will eventually improve their databases, possibly even before my old one expires, especially because Homeland Security wants to RFIDize us. I was considering losing my current passport before the RFID things get started, but it doesn't look like there's time, so I've got about 5 years to hope that the Republicans get thrown out on their asses in the next election and the Democrats decide that returning to the Constitution will sell better than continuing the Permanent State of Yellowalertness. Given the previous Clinton Administration's behavior, I don't expect the Hillary Clinton Administration to do any better. At 09:27 PM 10/29/2005, Jay Goodman Tamboli wrote: I wasn't able to find a reference to support this on http://state.gov, but I know it's possible to get two passports if you plan to travel to both Israel and a country that refuses to admit people with Israeli stamps in their passports. I don't think the US normally lets you have two passports, or if they do they almost certainly have the same number. But at least during the 1980s, Israel would be happy to give you a separate piece of paper with to carry with your passport that they'd stamp when you entered and left instead of stamping the passport itself. I don't remember if I did that or if I decided not to worry about it because I'd visited the Arab countries before going to Israel and didn't expect to get back any time soon.
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
At 01:42 AM 10/30/2005, Roy M. Silvernail wrote: Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. They've said they'll fall back on the traditional If we can't read the passport it's invalid and you'll need to replace it before we'll let you leave the country technique, just as they often do with expired passports and sometimes do with just-about-to-expire passports if you're a Suspicious-Acting Person like Dave del Torto. The only question is, what could (believably) damage the RFID? If you want to damage the RFID of a passport you're playing with, microwave ovens should do just fine. I don't know if Rivest's RFID-blocker chips use the same frequency or codespace as the passport RFIDs, but you could also leave one of them in the back of your passport. Now put that chip-cooker in a trash can right by the main entrance to an airport and perform some public service. I'd be surprised if you could put out enough energy to cook the passport RFIDs of people walking by at normal speed without also causing lots of other electrical problems.
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
On Sat, Oct 29, 2005 at 08:42:35PM -0400, Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. Actually, an RFID can be ridiculously reliable. It will also depend on how much harassment a traveler will be exposed to, when travelling. Being barred from entry will definitely prove sufficient deterrment. The only question is, what could (believably) damage the RFID? Microwaving it will blow up the chip, and cause a scorched spot. Severing the antenna would be enough for the chip to become mute. Violetwanding or treating with a Tesla generator should destroy all electronics quite reliably -- you always have to check, of course. Also, the ID is quite expensive, and a frequent traveller will wind up with a considerable expense, and hassle. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Multiple passports?
On Sun, Oct 30, 2005 at 03:05:25AM +, Justin wrote: If I apply for a new one now, and then apply for a another one once the gov starts RFID-enabling them, will the first one be invalidated? Or can I have two passports, the one without RFID to use, and the one with RFID to play with? Here in Germany the current ID (sans smartcard/rfid/biometics) will be valid until expiry date. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
At 01:31 AM 10/30/05 -0700, Bill Stewart wrote: They've said they'll fall back on the traditional If we can't read the passport it's invalid and you'll need to replace it before we'll let you leave the country technique, just as they often do with expired passports and sometimes What is the procedure (or are they secret :-) for passports which become damaged whilst travelling out of country? With a drivers license, if the magstrip doesn't work, they type in the numbers. But the biometrics are not encoded, its just a convenience. With a passport, they're relying on the chip or no? (Mechanical damage to the chip should work as well as RF or antenna damage. You will have to find the chip and crack it, mere flexing of the paper carrier doesn't work by design.)
Re: Multiple passports?
On 2005-10-29T21:17:25-0700, Gregory Hicks wrote: Date: Sun, 30 Oct 2005 03:05:25 + From: Justin [EMAIL PROTECTED] If I apply for a new one now, and then apply for a another one once the gov starts RFID-enabling them, will the first one be invalidated? Or can I have two passports, the one without RFID to use, and the one with RFID to play with? I am not a State Dept person, but my experiences in this are... As for applying for one now, I think the deadline for the non-RFID passwords is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if your application is not in processing by 31 Oct, then you get the new, improved, RFID passport.) The Department intends to begin the electronic passport program in December 2005. The first stage will be a pilot program in which the electronic passports will be issued to U.S. Government employees who use Official or Diplomatic passports for government travel. This pilot program will permit a limited number of passports to be issued and field tested prior to the first issuance to the American traveling public, slated for early 2006. By October 2006, all U.S. passports, with the exception of a small number of emergency passports issued by U.S. embassies or consulates, will be electronic passports. http://edocket.access.gpo.gov/2005/05-21284.htm (2005-10-25 Fed. Reg.) It sounds like it's fairly safe to get a new passport after Halloween... at least until January. -- The six phases of a project: I. Enthusiasm. IV. Search for the Guilty. II. Disillusionment. V. Punishment of the Innocent. III. Panic.VI. Praise Honor for the Nonparticipants.
Re: Blood, Bullets, Bombs and Bandwidth
On 2005-10-22T01:51:50-0400, R.A. Hettinga wrote: --- begin forwarded text Tyler and Jayme left Iraq in May 2005. The Arbil office failed; there wasn't enough business in Kurdistan. They moved to London, where Tyler still works for SSI. His time in Iraq has transformed him to the extent that, like Ryan, he doesn't think he can ever move back to the USA. His years of living hyperintensely, carrying a gun, building an organization from scratch in a war zone, have distanced him from his home. His friends seem to him to have stagnated. Their concerns seem trivial. And living with real, known, tangible danger has bred contempt for what he calls America's culture of fear. Tyler likes the high-speed lifestyle so much that he ditched it and moved to London? I doubt he's carrying a gun there. -- The six phases of a project: I. Enthusiasm. IV. Search for the Guilty. II. Disillusionment. V. Punishment of the Innocent. III. Panic.VI. Praise Honor for the Nonparticipants.
Re: Blood, Bullets, Bombs and Bandwidth
At 11:59 PM + 10/30/05, Justin wrote: Tyler likes the high-speed lifestyle so much that he ditched it and moved to London? He and Jayme are back in Kurdistan, now. Don't know for how long, though. He's teaching a new class of engineers, including crypto and security stuff. Watched their jaws drop when he 'em how to break WEP, that kind of thing. They handed him his Browning at the airfield when he landed. :-) Of course, they're touchy-feely liberals through-and-through, but here's hoping they've learned a little about anarchocapitalism having watched it firsthand, albeit temporarily. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: Multiple passports?
Gregory Hicks [EMAIL PROTECTED] writes: As for applying for one now, I think the deadline for the non-RFID passwords is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if your application is not in processing by 31 Oct, then you get the new, improved, RFID passport.) Ahh, but if you get one of the first passports issued then there are likely to still be some teething problems present, leading to sporadic failures of the first batch of RFID devices. I have a funny feeling that this is going to happen to my new passport when it arrives. Peter.
Re: On Digital Cash-like Payment Systems
From: cyphrpunk [EMAIL PROTECTED]
Sent: Oct 27, 2005 9:15 PM
To: James A. Donald [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com, [EMAIL PROTECTED]
Subject: Re: On Digital Cash-like Payment Systems
On 10/26/05, James A. Donald [EMAIL PROTECTED] wrote:
How does one inflate a key?
Just make it bigger by adding redundancy and padding, before you
encrypt it and store it on your disk. That way the attacker who wants
to steal your keyring sees a 4 GB encrypted file which actually holds
about a kilobyte of meaningful data. Current trojans can steal files
and log passwords, but they're not smart enough to decrypt and
decompress before uploading. They'll take hours to snatch the keyfile
through the net, and maybe they'll get caught in the act.
Note that there are crypto schemes that use huge keys, and it's
possible to produce simple variants of existing schemes that use
multiple keys. That would mean that the whole 8GB string was
necessary to do whatever crypto thing you wanted to do. A simple
example is to redefine CBC-mode encryption as
C[i] = E_K(C[i-1] xor P[i] xor S[C[i-1] mod 2^{29}])
where S is the huge shared string, and we're using AES. Without
access to the shared string, you could neither encrypt nor decrypt.
CP
--John
Re: Return of the death of cypherpunks.
From: James A. Donald [EMAIL PROTECTED] Sent: Oct 28, 2005 12:09 PM To: [EMAIL PROTECTED] Subject: Return of the death of cypherpunks. From: Eugen Leitl [EMAIL PROTECTED] ... The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist. Well, political controversy seems like the least interesting thing about the list--to the extent we're all babbling about who needs killing and who's not a sufficiently pure libertarian/anarchocapitalist and which companies are selling out to the Man, the list is nothing special. The cool thing is the understanding of crypto and computer security techology as applied to these concerns that are political. And the coolest thing is getting smart people who do real crypto/security work, and write working code, to solve problems. The ratio of political wanking to technical posts and of talkers to thinkers to coders needs to be right for the list to be interesting. ... --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb --John Kelsey
Re: Return of the death of cypherpunks.
-- James A. Donald: Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist. John Kelsey The ratio of political wanking to technical posts and of talkers to thinkers to coders needs to be right for the list to be interesting. These days, if one is seriously working on overthrowing the state by advancing to crypto anarchy (meaning both anarchy that is hidden, in that large scale cooperation procedes without the state taxing it, regulating it, supervising it, and licensing it, and anarchy that relies on cryptography to resist the state) it is not necessary or advisable to announce what one is up to. For example, Kerberos needs to be replaced by a more secure protocol. No need to add And I am concerned about this because I am an anarchist And so one discusses it on another list. (Kerberos tickets are small meaningful encrypted packets of information, when they should be random numbers. Being small, they can be dictionary attacked.) --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Y068Cy3Zv9GExXRbP24QJP5WmHGLz5VKyqNYFKbx 45fkOIGeiTkFnaM7p/URjB/kgn+0mcg8fMsMLmDy7
RE: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. The only question is, what could (believably) damage the RFID? -TD From: Eugen Leitl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv]] Date: Sat, 29 Oct 2005 20:54:13 +0200 - Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Fri, 28 Oct 2005 17:49:06 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Edward Hasbrouck [EMAIL PROTECTED] Date: October 28, 2005 11:07:28 AM EDT To: [EMAIL PROTECTED] Subject: Re: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv] From: Lin, Herb [EMAIL PROTECTED] *Front* cover? Does that mean that if I hold the passport the wrong way, the skimmer will have a free ride? FWIW: (1) The sample RFID passports that Frank Moss passed around at CFP, which looked like http://travel.state.gov/passport/eppt/eppt_2501.html, had the RFID chip (which was barely detectable by feel) in the *back* cover. The visible data page was/is, as with current passports, in the *front* cover. This is not compliant with the ICAO specifications, which recommend having the chip in the same page as the visible data, to make it more difficult to separate them. I can only guess that it was hard to laminate the visible data without damaging the chip, if it was in the same page. But it's interesting in light of the importance supposedly being placed on compliance with ICAO standards. (2) Moss had 2 sample RFID passports, 1 with and 1 without the shielding. He cliamed it was a layer in the entire outer cover (front and back), but it wasn't detectable by feel. I have more threat scenarios for the latest flavor of RFID passport at: http://hasbrouck.org/blog/archives/000869.html Edward Hasbrouck [EMAIL PROTECTED] http://hasbrouck.org +1-415-824-0214 - You are subscribed as [EMAIL PROTECTED] 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 __ ICBM: 48.07100, 11.36820http://www.leitl.org 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]
Re: Multiple passports?
Date: Sun, 30 Oct 2005 03:05:25 + From: Justin [EMAIL PROTECTED] If I apply for a new one now, and then apply for a another one once the gov starts RFID-enabling them, will the first one be invalidated? Or can I have two passports, the one without RFID to use, and the one with RFID to play with? I am not a State Dept person, but my experiences in this are... If you get a new one, the old one has to accompany the application and is invalidated when the new one is issued. (Invalidated by stamping the 'data' page with big red block letters INVALID.) The old, now invalid is returned with the new one... The only people that I knew that had two passports were those with an Official (red) passport or a Diplomatic (black) passport. If they wanted to go play tourist, they had to also have a tourist (Blue) passport. As for applying for one now, I think the deadline for the non-RFID passwords is about 3 days away (31 Oct 2005), but I could be wrong. (In other words, if your application is not in processing by 31 Oct, then you get the new, improved, RFID passport.) Regards, Gregory Hicks -- The six phases of a project: I. Enthusiasm. IV. Search for the Guilty. II. Disillusionment. V. Punishment of the Innocent. III. Panic.VI. Praise Honor for the Nonparticipants. - I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
Re: Multiple passports?
On 10/30/05, Gregory Hicks [EMAIL PROTECTED] wrote: The only people that I knew that had two passports were those with an Official (red) passport or a Diplomatic (black) passport. If they wanted to go play tourist, they had to also have a tourist (Blue) passport. I wasn't able to find a reference to support this on http://state.gov, but I know it's possible to get two passports if you plan to travel to both Israel and a country that refuses to admit people with Israeli stamps in their passports. /jgt
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/28/05, Daniel A. Nagy [EMAIL PROTECTED] wrote: Irreversibility of transactions hinges on two features of the proposed systetm: the fundamentally irreversible nature of publishing information in the public records and the fact that in order to invalidate a secret, one needs to know it; the issuer does not learn the secret at all in some implementnations and only learns it when it is spent in others. In both cases, reversal is impossible, albeit for different reasons. Let's say, Alice made a payment to Bob, and Ivan wishes to reverse it with the possible cooperation of Alice, but definitely without Bob's help. Alice's secret is Da, Bob's secret is Db, the corresponding challenges are, respectively, Ca and Cb, and the S message containing the exchange request Da-Cb has already been published. In the first case, when the secret is not revealed, there is simply no way to express reverslas. There is no S message with suitable semantics semantics, making it impossible to invalidate Db if Bob refuses to reveal it. The issuer can still invalidate it even though you have not explicitly defined such an operation. If Alice paid Bob and then convinces the issuer that Bob cheated her, the issuer could refuse to honor the Db deposit or exchange operation. From the recipient's perspective, his cash is at risk at least until he has spent it or exchanged it out of the system. The fact that you don't have an issuer invalidates cash operation in your system doesn't mean it couldn't happen. Alice could get a court order forcing the issuer to do this. The point is that reversal is technically possible, and you can't define it away just by saying that the issuer won't do that. If the issuer has the power to reverse transactions, the system does not have full ireversibility, even though the issuer hopes never to exercise his power. In the second case, Db is revealed when Bob tries to spend it, so Ivan can, in principle, steal (confiscate) it, instead of processing, but at that point Da has already been revealed to the public and Alice has no means to prove that she was in excusive possession of Da before it became public information. That is an interesting possibility, but I can think of a way around it. Alice could embed a secret within her secret. She could base part of her secret on a hash of an even-more-secret value which she would not reveal when spending/exchanging. Then if it came to where she had to prove that she was the proper beneficiary of a reversed transaction, she could reveal the inner secret to justify her claim. Now, one can extend the list of possible S messages to allow for reversals in the first scenario, but even in that case Ivan cannot hide the fact of reversal from the public after it happened and the fact that he is prepared to reverse payments even before he actually does so, because the users and auditors need to know the syntax and the semantics of the additional S messages in order to be able to use Ivan's services. That's true, the public visibility of the system makes secret reversals impossible. That's very good - one of the problems with e-gold was that it was never clear when they were reversing and freezing accounts. Visibility is a great feature. But it doesn't keep reversals from happening, and it still leaves doubt about how final transactions will be in this system. CP
Re: Any comments on BlueGem's LocalSSL?
At 9:11 PM +1300 10/28/05, Peter Gutmann wrote: The West Coast Labs tests report that they successfully evade all known sniffers, which doesn't actually mean much since all it proves is that LocalSSL is sufficiently 0-day that none of the sniffers target it yet. The use of SSL to get the keystrokes from the driver to the target app seems somewhat silly, if sniffers don't know about LocalSSL then there's no need to encrypt the data, and once they do know about it then the encryption won't help, they'll just dive in before the encryption happens. Absent any real data, crypto-dogma :-) says that you need hardware-encryption, physical sources of randomness, and all sorts of other stuff to really solve this problem. On the other hand, such hardware solutions usually come hand-in-hand with the whole hierarchical is-a-person PKI book-entry-to-the-display I-gotcher-digital-rights-right-here-buddy mess, ala Palladium, etc. Like SSL, then -- and barring the usual genius out there who flips the whole tortoise over to kill it, which is what you're really asking here -- this thing might work good enough to keep Microsoft/Verisign/et al. in business a few more years. To the rubes and newbs, it's like Microsoft adopting TLS, or Intel doing their current crypto/DRM stuff, which, given the amount iPod/iTunes writes to their bottom line now, is apparently why Apple really switched from PPC to Intel now instead of later. You know they're going to do evil, but at least the *other* malware goes away. So, sure. SSL to the keys. That way Lotus *still* won't run, and business gets done in Redmond a little while longer. Cheers, RAH Somewhere, Dr. Franklin is laughing, of course... -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
At 9:27 PM -0700 10/27/05, cyphrpunk wrote: Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. So, as Carl Ellison says, get it from the source. Self-signing is fine, in that case. Certificates, CRLs, etc., become more and more meaningless as the network becomes more geodesic. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! Feh. You sound like one of those newbs who used to leave the plastic wrap on his 3.5 floppy so he wouldn't get viruses... Cheers, RAH What part of non-hierarchical and P2P do you not understand? -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [PracticalSecurity] Anonymity - great technology but hardly used
At 8:41 PM -0700 10/27/05, cyphrpunk wrote: Where else are you going to talk about this shit? Talk about it here, of course. Just don't expect anyone to listen to you when you play list-mommie. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
[EMAIL PROTECTED]: RE: [p2p-hackers] P2P Authentication]
- Forwarded message from Matthew Kaufman [EMAIL PROTECTED] - From: Matthew Kaufman [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 19:28:53 -0700 To: 'Peer-to-peer development.' [EMAIL PROTECTED] Subject: RE: [p2p-hackers] P2P Authentication X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Reply-To: Peer-to-peer development. [EMAIL PROTECTED] Alen Peacock: Personally, I'm put off by the centralization. I'm not really concerned about the library size or complexity of PKI,. In fact, my experience indicates that implementing centralized CAs is a good deal less complex than trying to distribute identity verification throughout the system with no centralization. Agreed... Hierarchical PKI with a single root is distinctly easier than multiple roots, random chains of trust, or reputation models, which is why we've started with the simplest design for the default PKI that ships with the amicima MFP and MFPNet libraries. Completely decentralized p2p applications have the advantage of being especially resilient to DoS and other attacks on centrality. Introducing centralized components negates this advantage. It negates some advantages, not all. In the case of using CAs in a p2p app, the entire network can be disabled by attacking the CAs. As has already been pointed out, the network still runs, but new clients can't be authenticated. However, it is possible to make that unlikely... For instance, if enough trusted entities already have the ability to sign keys, you can reduce the odds that an attacker can successfully disable ALL of the CAs. Adding additional roots to the PKI, especially if they are public roots that are unlikely to be disabled, also helps... It doesn't seem likely that the world will shut down the existing secure web PKI in order to take your P2P app off the air. p2p networks pose an interesting challenge because you have to design for the fact that malicious or misbehaving clients *will* be present. This is actually true of the entire Internet and isn't unique to p2p networks at all. All protocol implementations and higher level applications that run on them must be designed to deal with malicious or misbehaving clients will be present... See buffer overflows of mail servers and http servers, for instance. Since there is no single entity or known group of entities controlling the nodes (as in typical distributed applications), there is no way to enforce adherence to protocols other than with the protocols themselves. This isn't about p2p networks at all, but about open-source distribution, it seems. Lots of totally proprietary p2p and client-server applications have been shipped where a single entity controls the implementation... Skype comes to mind as an example in the P2P space. These have the temporary advantage of unpublished protocols and implementations, but this won't stop a dedicated attacker for long, which brings us back to the original point, that everything attached to the Internet needs to assume that malicious and misbehaving things will try to mess things up. Whether or not that really matters is another point... There's numerous ways one could build a highly incorrect Gnutella peer, for instance, and yet it doesn't seem to have become commonplace. This may sound idealistic and naive, perhaps justly so, but the further away from protocols that require centralized architectures we get, the better (IMHO, of course). Well, that's why we're all here on the P2P hackers list, I suppose, because we believe that decentralization is good, but it doesn't really change the most basic of the design parameters at all. Matthew Kaufman [EMAIL PROTECTED] www.amicima.com ___ p2p-hackers mailing list [EMAIL PROTECTED] 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 message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Thu, Oct 27, 2005 at 11:28:42PM -0400, R.A. Hettinga wrote: The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that needs killing thing (okay, it was funny for a while). The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [PracticalSecurity] Anonymity - great technology but hardly used
From: Eugen Leitl [EMAIL PROTECTED] Sent: Oct 27, 2005 3:22 AM To: Shawn K. Quinn [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PracticalSecurity] Anonymity - great technology but hardly used ... It's never about merit, and not even money, but about predeployed base and interoperability. In today's world, you minimize the surprise on the opposite party's end if you stick with Redmondware. (Businessfolk hate surprises, especially complicated, technical, boring surprises). Not only that, but this is often sensible. Have you noticed the bizarre misfit between our allegedly phonetic alphabet and how things are spelled? Why don't we get everyone to change that? Or the silly insistence of sticking with a base 60 time standard? Or the whole atrocity of English measurements that the US still is stuck with? Oh yeah, because there's an enormous installed base, and people are able to do their jobs with them, bad though these tools are. ... OpenOffice Co usually supports a subset of Word and Excel formats. If you want to randomly annoy your coworkers, use OpenOffice to process the documents in MS Office formats before passing them on, without telling what you're doing. Much hilarity will ensue. I'll note that you can do the same thing by simply using slightly different versions of Word. MS takes a bad rap for a lot of their software (Excel and Powerpoint are pretty nice, for example), but Word is a disaster. Eugen* Leitl a href=http://leitl.org;leitl/a --John Kelsey
Re: Any comments on BlueGem's LocalSSL?
-- R.A. Hettinga [EMAIL PROTECTED] Intel doing their current crypto/DRM stuff, [...] You know they're going to do evil, but at least the *other* malware goes away. I am a reluctant convert to DRM. At least with DRM, we face a smaller number of threats. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ctySJF5hgF1q9fil61pohBVLfj/aT4jWZ/KUf29x 4GuXiNXRF+nY3+3LFo8YpvV4w1S5dwf+LcuAsZWWe
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On Fri, Oct 28, 2005 at 02:18:43PM -0700, cyphrpunk wrote: In particular I have concerns about the finality and irreversibility of payments, given that the issuer keeps track of each token as it progresses through the system. Whenever one token is exchanged for a new one, the issuer records and publishes the linkage between the new token and the old one. This public record is what lets people know that the issuer is not forging tokens at will, but it does let the issuer, and possibly others, track payments as they flow through the system. This could be grounds for reversibility in some cases, although the details depend on how the system is implemented. It would be good to see a critical analysis of how epoints would maintain irreversibility, as part of the paper. I agree, this discussion is missing, indeed. I will definitely include it, should I write another paper on the subject. Irreversibility of transactions hinges on two features of the proposed systetm: the fundamentally irreversible nature of publishing information in the public records and the fact that in order to invalidate a secret, one needs to know it; the issuer does not learn the secret at all in some implementnations and only learns it when it is spent in others. In both cases, reversal is impossible, albeit for different reasons. Let's say, Alice made a payment to Bob, and Ivan wishes to reverse it with the possible cooperation of Alice, but definitely without Bob's help. Alice's secret is Da, Bob's secret is Db, the corresponding challenges are, respectively, Ca and Cb, and the S message containing the exchange request Da-Cb has already been published. In the first case, when the secret is not revealed, there is simply no way to express reverslas. There is no S message with suitable semantics semantics, making it impossible to invalidate Db if Bob refuses to reveal it. In the second case, Db is revealed when Bob tries to spend it, so Ivan can, in principle, steal (confiscate) it, instead of processing, but at that point Da has already been revealed to the public and Alice has no means to prove that she was in excusive possession of Da before it became public information. Now, one can extend the list of possible S messages to allow for reversals in the first scenario, but even in that case Ivan cannot hide the fact of reversal from the public after it happened and the fact that he is prepared to reverse payments even before he actually does so, because the users and auditors need to know the syntax and the semantics of the additional S messages in order to be able to use Ivan's services. -- Daniel
Re: Any comments on BlueGem's LocalSSL?
At 11:10 AM -0700 10/28/05, James A. Donald wrote: I am a reluctant convert to DRM. At least with DRM, we face a smaller number of threats. I have had it explained to me, many times more than I want to remember, :-), that strong crypto is strong crypto. It's not that I'm unconvinceable, but I'm still unconvinced, on the balance. OTOH, if markets overtake the DRM issue, as most cypherpunks I've talked to think, then we still have lots of leftover installed crypto to play around with. Cheers, RAH Who still thinks that digital proctology is not the same thing as financial cryptography. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: Any comments on BlueGem's LocalSSL?
At 7:51 PM -0400 10/28/05, R.A. Hettinga wrote: OTOH, if markets overtake the DRM issue, ^ moot, was what I meant to say... Anyway, you get the idea. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: packet traffic analysis
Good catch on the encryption. I feel silly for not thinking of it. If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis. I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet. And then there's the bandwidth tradeoff you mention, which is probably of a larger concern (although bandwidth will increase over time, whereas the speed of light will not). I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets and creating all your chaff as packets. Let's assume the link is encrypted as before. Then you merely introduce your legitimate packets with a certain escape sequence, and pad between these packets with either zeroes, or if you're more paranoid, some kind of PRNG. In this way, if the link is idle, you can stop generating chaff and start generating packets at any time. I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. This is not a tiny hack, but avoids much of the overhead in your technique. It could easily be applied to something like openvpn, which can operate over a TCP virtual circuit, or ppp. It'd be a nice optimization if you could avoid retransmits of segments that contained only chaff, but that may or may not be possible to do without giving up some TA resistance (esp. in the presence of an attacker who may prevent transmission of segments). -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: packet traffic analysis
I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next escape sequence introducing a legitimate packet. I should point out that encrypting PRNG output may be pointless, and perhaps one optimization is to stop encrypting when switching on the chaff. The peer can then encrypt the escape sequence as it would appear in the encrypted stream, and do a simple string match on that. In this manner the peer does not have to do any decryption until the [encrypted] escape sequence re-appears. Another benefit of this is to limit the amount of material encrypted under the key to legitimate traffic and the escape sequences prefixing them. Some minor details involving resynchronizing when the PRNG happens to produce the same output as the expected encrypted escape sequence is left as an exercise for the reader. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
RE: Return of the death of cypherpunks.
I don't agree. One thing we do know is that, although Crypto is available and, in special contexts, used, it's use in other contexts is almost counterproduct, sending up a red flag so that those that Protect Our Freedoms will come sniffing around and bring to bear their full arsenal of technologies and, possibly, dirty tricks. Merely knowing that you are using stego/crypto in such contexts can cause a lot of attention come your way, possibly in actual meatspace, which in many cases is almost worse than not using crypto at all In addition, although strong and unbreakable Crypto exists, one thing a stint on Cypherpunks teaches you is that it is only rarely implemented in such a way as to actually be unbreakable to a determined attacker, particularly if there are not many such cases to examine in such contexts. The clear moral of this story is that, to increase the odds of truly secure communication, etc, Crypto in such contexts must become much more ubiquitous, and I still think Cypherpunks has a role to play there and indeed has played that role. Such a role is, of course, far more than a mere cheerleading role,a fact that merits a continued existence for Cypherpunks in some form or another. -TD Only when Crypto is used ubiquitousl From: James A. Donald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Return of the death of cypherpunks. Date: Fri, 28 Oct 2005 12:09:36 -0700 -- From: Eugen Leitl [EMAIL PROTECTED] While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that needs killing thing (okay, it was funny for a while). The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist. I recently read up on the Kerberos protocol, and thought, how primitive. Back in the bad old days, we did everything wrong, because we did not know any better. And of course, https sucks mightily because the threat model is both inappropriate to the real threats, and fails to correspond to the users mental model, or to routine practices on a wide variety of sites, hence users glibly click through all warning dialogs, most of which are mere noise anyway. These problems, however, are no explicitly political, and tend to be addressed on lists that are not explicitly political, leaving cypherpunks with little of substance. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Thu, Oct 27, 2005 at 11:28:42PM -0400, R.A. Hettinga wrote: The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that needs killing thing (okay, it was funny for a while). The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
At 9:27 PM -0700 10/27/05, cyphrpunk wrote: Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. So, as Carl Ellison says, get it from the source. Self-signing is fine, in that case. Certificates, CRLs, etc., become more and more meaningless as the network becomes more geodesic. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! Feh. You sound like one of those newbs who used to leave the plastic wrap on his 3.5 floppy so he wouldn't get viruses... Cheers, RAH What part of non-hierarchical and P2P do you not understand? -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On 10/26/05, Shawn K. Quinn [EMAIL PROTECTED] wrote: On Tue, 2005-10-25 at 23:40 -0500, Travis H. wrote: Many of the anonymity protocols require multiple participants, and thus are subject to what economists call network externalities. The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format. 1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? This is off-topic. Let's not degenerate into random Microsoft bashing. Keep the focus on anonymity. That's what the cypherpunks list is about. CP
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Thu, 2005-10-27 at 23:28 -0400, R.A. Hettinga wrote: RAH Who thinks anything Microsoft makes these days is, by definition, a security risk. Indeed, the amount of trust I'm willing to place in a piece of software is quite related to how much of its source code is available for review. Surprisingly, I'm not the only one that feels this way. -- Shawn K. Quinn [EMAIL PROTECTED]
Re: [PracticalSecurity] Anonymity - great technology but hardly used
At 8:18 PM -0700 10/27/05, cyphrpunk wrote: Keep the focus on anonymity. That's what the cypherpunks list is about. Please. The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. Cheers, RAH Who thinks anything Microsoft makes these days is, by definition, a security risk. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
From: Kerry Bonin [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for 100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, 30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... It's great to see this guy showing up yet another of the false dogmas of the crypto hacker community: PKI can't work. According to this view, only old fogies and tight ass bureaucrats believe in certifying keys. All the cool kids know that the best key is a bare key. After all, MITM attacks never really happen, this was just an invented threat designed to force poor college kids into paying hundreds of dollars a year for a verisign certificate. But when we come into the P2P world things look very different. Where MITM would require special positioning in the old net, in a distributed P2P network, everyone's a MITM! Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! CP
Re: [PracticalSecurity] Anonymity - great technology but hardly used
At 12:23 PM -0700 10/27/05, Major Variola (ret) wrote: Why don't you send her comma-delimited text, Excel can import it? But, but... You can't put Visual *BASIC* in comma delimited text... ;-) Cheers, RAH Yet another virus vector. Bah! :-) -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [PracticalSecurity] Anonymity - great technology but hardly used
The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. Fine, I want it to be about crypto and anonymity. You can bash Microsoft anywhere on the net. Where else are you going to talk about this shit? CP
Re: [PracticalSecurity] Anonymity - great technology but hardly used
From: Eugen Leitl [EMAIL PROTECTED] Sent: Oct 27, 2005 3:22 AM To: Shawn K. Quinn [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PracticalSecurity] Anonymity - great technology but hardly used .. It's never about merit, and not even money, but about predeployed base and interoperability. In today's world, you minimize the surprise on the opposite party's end if you stick with Redmondware. (Businessfolk hate surprises, especially complicated, technical, boring surprises). Not only that, but this is often sensible. Have you noticed the bizarre misfit between our allegedly phonetic alphabet and how things are spelled? Why don't we get everyone to change that? Or the silly insistence of sticking with a base 60 time standard? Or the whole atrocity of English measurements that the US still is stuck with? Oh yeah, because there's an enormous installed base, and people are able to do their jobs with them, bad though these tools are. .. OpenOffice Co usually supports a subset of Word and Excel formats. If you want to randomly annoy your coworkers, use OpenOffice to process the documents in MS Office formats before passing them on, without telling what you're doing. Much hilarity will ensue. I'll note that you can do the same thing by simply using slightly different versions of Word. MS takes a bad rap for a lot of their software (Excel and Powerpoint are pretty nice, for example), but Word is a disaster. Eugen* Leitl a href=http://leitl.org;leitl/a --John Kelsey
Re: [PracticalSecurity] Anonymity - great technology but hardly used
At 8:41 PM -0700 10/27/05, cyphrpunk wrote: Where else are you going to talk about this shit? Talk about it here, of course. Just don't expect anyone to listen to you when you play list-mommie. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/25/05, Travis H. [EMAIL PROTECTED] wrote: More on topic, I recently heard about a scam involving differential reversibility between two remote payment systems. The fraudster sends you an email asking you to make a Western Union payment to a third party, and deposits the requested amount plus a bonus for you using paypal. The victim makes the irreversible payment using Western Union, and later finds out the credit card used to make the paypal payment was stolen when paypal reverses the transaction, leaving the victim short. This is why you can't buy ecash with your credit card. Too easy to reverse the transaction, and by then the ecash has been blinded away. If paypal can be reversed just as easily that won't work either. This illustrates a general problem with these irreversible payment schemes, it is very hard to simply acquire the currency. Any time you go from a reversible payment system (as all the popular ones are) to an irreversible one you have an impedence mismatch and the transfer reflects rather than going through (so to speak). CP
Re: [EMAIL PROTECTED]: Skype security evaluation]
Wasn't there a rumor last year that Skype didn't do any encryption padding, it just did a straight exponentiation of the plaintext? Would that be safe, if as the report suggests, the data being encrypted is 128 random bits (and assuming the encryption exponent is considerably bigger than 3)? Seems like it's probably OK. A bit risky perhaps to ride bareback like that but I don't see anything inherently fatal. CP
Re: On Digital Cash-like Payment Systems
On 10/26/05, James A. Donald [EMAIL PROTECTED] wrote: How does one inflate a key? Just make it bigger by adding redundancy and padding, before you encrypt it and store it on your disk. That way the attacker who wants to steal your keyring sees a 4 GB encrypted file which actually holds about a kilobyte of meaningful data. Current trojans can steal files and log passwords, but they're not smart enough to decrypt and decompress before uploading. They'll take hours to snatch the keyfile through the net, and maybe they'll get caught in the act. CP
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Thu, 2005-10-27 at 20:18 -0700, cyphrpunk wrote: This is off-topic. Let's not degenerate into random Microsoft bashing. Keep the focus on anonymity. That's what the cypherpunks list is about. Sorry, but I have to disagree. I highly doubt that Microsoft is interested in helping users of their software preserve anonymity, in fact, evidence has surfaced to indicate quite the opposite. (GUID in Office? The obnoxious product activation requirement? I'm sure there are others.) I would say that helping others get rid of dependencies on Microsoft products is thus advancing the cause of anonymity in cyberspace. -- Shawn K. Quinn [EMAIL PROTECTED]
Re: Any comments on BlueGem's LocalSSL?
-- R.A. Hettinga [EMAIL PROTECTED] Intel doing their current crypto/DRM stuff, [...] You know they're going to do evil, but at least the *other* malware goes away. I am a reluctant convert to DRM. At least with DRM, we face a smaller number of threats. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ctySJF5hgF1q9fil61pohBVLfj/aT4jWZ/KUf29x 4GuXiNXRF+nY3+3LFo8YpvV4w1S5dwf+LcuAsZWWe
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Wed, Oct 26, 2005 at 08:41:48PM -0500, Shawn K. Quinn wrote: 1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? Telling is useless. Are you in a sufficient position of power to make them stop using it? I doubt it, because that person will be backed both by your and her boss. Almost always. It's never about merit, and not even money, but about predeployed base and interoperability. In today's world, you minimize the surprise on the opposite party's end if you stick with Redmondware. (Businessfolk hate surprises, especially complicated, technical, boring surprises). 2) OpenOffice can read Excel spreadsheets, and I would assume it can save the changes back to them as well. OpenOffice Co usually supports a subset of Word and Excel formats. If you want to randomly annoy your coworkers, use OpenOffice to process the documents in MS Office formats before passing them on, without telling what you're doing. Much hilarity will ensue. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
- Forwarded message from Kerry Bonin [EMAIL PROTECTED] - From: Kerry Bonin [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for 100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, 30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... Kerry [EMAIL PROTECTED] wrote: And if they do, then why reinvent the wheel? Traditional public key signing works well for these cases. ... Traditional public key signing doesn't work well if you want to eliminate the central authority / trusted third party. If you like keeping those around, then yes, absolutely, traditional PKI works swimmingly. Where is the evidence of this bit about traditional PKI working? As far as I've observed, traditional PKI works barely for small, highly centralized, hierarchical organizations and not at all for anything else. Am I missing some case studies of PKI actually working as intended? Regards, Zooko ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ___ p2p-hackers mailing list [EMAIL PROTECTED] 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 message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [PracticalSecurity] Anonymity - great technology but hardly used
At 08:41 PM 10/26/05 -0500, Shawn K. Quinn wrote: On Tue, 2005-10-25 at 23:40 -0500, Travis H. wrote: Many of the anonymity protocols require multiple participants, and thus are subject to what economists call network externalities. The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format. 1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? 2) OpenOffice can read Excel spreadsheets, and I would assume it can save the changes back to them as well. Why don't you send her comma-delimited text, Excel can import it?
Re: [PracticalSecurity] Anonymity - great technology but hardly used
At 12:23 PM -0700 10/27/05, Major Variola (ret) wrote: Why don't you send her comma-delimited text, Excel can import it? But, but... You can't put Visual *BASIC* in comma delimited text... ;-) Cheers, RAH Yet another virus vector. Bah! :-) -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On 10/26/05, Shawn K. Quinn [EMAIL PROTECTED] wrote: On Tue, 2005-10-25 at 23:40 -0500, Travis H. wrote: Many of the anonymity protocols require multiple participants, and thus are subject to what economists call network externalities. The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format. 1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? This is off-topic. Let's not degenerate into random Microsoft bashing. Keep the focus on anonymity. That's what the cypherpunks list is about. CP
Re: [PracticalSecurity] Anonymity - great technology but hardly used
At 8:18 PM -0700 10/27/05, cyphrpunk wrote: Keep the focus on anonymity. That's what the cypherpunks list is about. Please. The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. Cheers, RAH Who thinks anything Microsoft makes these days is, by definition, a security risk. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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'
Re: [PracticalSecurity] Anonymity - great technology but hardly used
The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. Fine, I want it to be about crypto and anonymity. You can bash Microsoft anywhere on the net. Where else are you going to talk about this shit? CP
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Thu, 2005-10-27 at 20:18 -0700, cyphrpunk wrote: This is off-topic. Let's not degenerate into random Microsoft bashing. Keep the focus on anonymity. That's what the cypherpunks list is about. Sorry, but I have to disagree. I highly doubt that Microsoft is interested in helping users of their software preserve anonymity, in fact, evidence has surfaced to indicate quite the opposite. (GUID in Office? The obnoxious product activation requirement? I'm sure there are others.) I would say that helping others get rid of dependencies on Microsoft products is thus advancing the cause of anonymity in cyberspace. -- Shawn K. Quinn [EMAIL PROTECTED]
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
On 10/25/05, Travis H. [EMAIL PROTECTED] wrote: More on topic, I recently heard about a scam involving differential reversibility between two remote payment systems. The fraudster sends you an email asking you to make a Western Union payment to a third party, and deposits the requested amount plus a bonus for you using paypal. The victim makes the irreversible payment using Western Union, and later finds out the credit card used to make the paypal payment was stolen when paypal reverses the transaction, leaving the victim short. This is why you can't buy ecash with your credit card. Too easy to reverse the transaction, and by then the ecash has been blinded away. If paypal can be reversed just as easily that won't work either. This illustrates a general problem with these irreversible payment schemes, it is very hard to simply acquire the currency. Any time you go from a reversible payment system (as all the popular ones are) to an irreversible one you have an impedence mismatch and the transfer reflects rather than going through (so to speak). CP
