July 2018 - cypherpunks-legacy

None
by Declan McCullagh 06 Jul '18

06 Jul '18

---

1 0

[IP] Are terrorists using encryption to cloak their secrets?
by Dave Farber 06 Jul '18

06 Jul '18

1 0

Re: [IP] RFID Clonable
by Ross Stapleton-Gray 06 Jul '18

06 Jul '18

At 07:48 AM 7/25/2006, David Farber wrote: >In case anyone needed more proof that we're all living in a Philip K. >Dick novel, a pair of hackers have recently demonstrated how human- >implantable >RFID chips from VeriChip can be easily cloned, effectively stealing >the >person's identity. >... >For its part, VeriChip has only said they haven't yet had a chance >to review the evidence but still >insist that "it's very difficult to steal a VeriChip." Certainly literally true, if by "steal" one means, "get one's hands on the original, e.g., pry one out of Annalee Newitz's arm." But we should recongize that the vast majority of RFID applications [BUT NOT ALL djf] don't depend on inability to clone them. RFID tags in most commerce will be as unclonable as license plates, which anyone with a little tin, paint and shop skills could zap out copies of, but which nonetheless serve as a cheap means for reasonably reliable identification. Think of most RFID applications as just like print bar codes; there have been various cases of fraud committed against systems employing the latter, most notably where thieves use bar codes for inferior goods to purchase expensive ones ("Bar code says that's a drill bit, and it looks like a drill bit...") then return the goods to pocket the difference in price. The new wrinkle that RFID offers for commerce here is uniqueness: the local Home Depot currently knows that it has 500 units of carbide drill bit, all bearing identical bar codes... in an item-level RFID tagged world, it would know 500 unique serials, so spoofing the checkout clerk with a false tag becomes a little harder. And, with unique tags, it becomes easier to compile and retain longitudinal dossiers on "where has this thing been?" (if the various parties in supply chain actually read the tags): this is the aspect that will be used for pharmaceutical knockoff detection, where the overarching RFID tracking and management system will be able to provide some provenance information ("This very bottle was allegedly seen in Singapore 3 hours ago... something's not right"). This is also one of the more privacy-invasive aspects. I've seen one research effort (an NSF SBIR) looking at creating unclonable RFID thus far, which basically works, I believe, by extracting a physical signature of the item to be tagged (in the awarded research, it was magnetic signatures), and using that as part of the unique key, or perhaps registering that signature in an off- chip database that would need to be additionally queried. In the VeriChip hack, you might address the problem that that little chip merely spits out a unique ID that anyone who can read can rewrite into a new chip by having the implanted chip also encode some (relatively) unclonable aspect of the person the chip is embedded in, e.g., you can still "steal" the unique ID, but could only then use it in a chip in another (1) female; with (2) brown eyes; (3) blood type AB-; etc.; etc. But so far as I know the VeriChip used in human implants is just that little unique number... its value as a unique ID for security authentication depends a lot on it being hidden from 3rd party readers. Of course, we have this problem in spades all over the place... your SSN, or credit card number, can be fairly easily abused by anyone who knows it, despite the fact that you have to expose it to a lot of parties, many, many times over the course of a year. Ross ---- Ross Stapleton-Gray, Ph.D. Stapleton-Gray & Associates, Inc. http://www.stapleton-gray.com http://www.sortingdoor.com ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] more on RFID Clonable
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

None
by Declan McCullagh 06 Jul '18

06 Jul '18

---

1 0

[IP] Are terrorists using encryption to cloak their secrets?
by Dave Farber 06 Jul '18

06 Jul '18

1 0

Re: [IP] RFID Clonable
by Ross Stapleton-Gray 06 Jul '18

06 Jul '18

At 07:48 AM 7/25/2006, David Farber wrote: >In case anyone needed more proof that we're all living in a Philip K. >Dick novel, a pair of hackers have recently demonstrated how human- >implantable >RFID chips from VeriChip can be easily cloned, effectively stealing >the >person's identity. >... >For its part, VeriChip has only said they haven't yet had a chance >to review the evidence but still >insist that "it's very difficult to steal a VeriChip." Certainly literally true, if by "steal" one means, "get one's hands on the original, e.g., pry one out of Annalee Newitz's arm." But we should recongize that the vast majority of RFID applications [BUT NOT ALL djf] don't depend on inability to clone them. RFID tags in most commerce will be as unclonable as license plates, which anyone with a little tin, paint and shop skills could zap out copies of, but which nonetheless serve as a cheap means for reasonably reliable identification. Think of most RFID applications as just like print bar codes; there have been various cases of fraud committed against systems employing the latter, most notably where thieves use bar codes for inferior goods to purchase expensive ones ("Bar code says that's a drill bit, and it looks like a drill bit...") then return the goods to pocket the difference in price. The new wrinkle that RFID offers for commerce here is uniqueness: the local Home Depot currently knows that it has 500 units of carbide drill bit, all bearing identical bar codes... in an item-level RFID tagged world, it would know 500 unique serials, so spoofing the checkout clerk with a false tag becomes a little harder. And, with unique tags, it becomes easier to compile and retain longitudinal dossiers on "where has this thing been?" (if the various parties in supply chain actually read the tags): this is the aspect that will be used for pharmaceutical knockoff detection, where the overarching RFID tracking and management system will be able to provide some provenance information ("This very bottle was allegedly seen in Singapore 3 hours ago... something's not right"). This is also one of the more privacy-invasive aspects. I've seen one research effort (an NSF SBIR) looking at creating unclonable RFID thus far, which basically works, I believe, by extracting a physical signature of the item to be tagged (in the awarded research, it was magnetic signatures), and using that as part of the unique key, or perhaps registering that signature in an off- chip database that would need to be additionally queried. In the VeriChip hack, you might address the problem that that little chip merely spits out a unique ID that anyone who can read can rewrite into a new chip by having the implanted chip also encode some (relatively) unclonable aspect of the person the chip is embedded in, e.g., you can still "steal" the unique ID, but could only then use it in a chip in another (1) female; with (2) brown eyes; (3) blood type AB-; etc.; etc. But so far as I know the VeriChip used in human implants is just that little unique number... its value as a unique ID for security authentication depends a lot on it being hidden from 3rd party readers. Of course, we have this problem in spades all over the place... your SSN, or credit card number, can be fairly easily abused by anyone who knows it, despite the fact that you have to expose it to a lot of parties, many, many times over the course of a year. Ross ---- Ross Stapleton-Gray, Ph.D. Stapleton-Gray & Associates, Inc. http://www.stapleton-gray.com http://www.sortingdoor.com ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] more on RFID Clonable
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: Hello directly from Jimbo at Wikipedia
by Paul Syverson 06 Jul '18

06 Jul '18

Some points of clarification that I hope will help: (1) On anonymity and authentication/pseudonymity/etc. All versions of Onion Routing, including Tor, were designed to separate identification from routing. The slogan way that I have put this for the last five or six years is: Onion Routing is about anonymizing the communication pipe, not what goes through it. The devil's always in the details, but as one-line summaries go, I think that sums it up pretty well.{1} (2) On various pseudonym authentication or anonym authentication{2}, etc. approaches to solving the problem at hand. Some of this is ultimately necessary for various applications, especially once the Internet looks as Geoff described it. (In fact I think it's one precondition to realizing anything like that vision.) But I'm dubious about any of those proposed to date here providing enough friction to identifier acquisition to deter abusers but not honest users in this context. They may be worth trying. Roger's suggestion about the temporary IP blocks and Steven's about the separate puzzle servers come to mind, probably some others I'm forgetting just now. But as Roger says, somebody's gotta code them up---and probably much more work---deploy them, maintain them, and evaluate their effectiveness, all on the Tor-Wikipedia frontier. I suspect that the abuser who goes postal as Jimmy described is willing to waste lots of time acquiring IDs, but perhaps stereotypes about attention span are close enough to true for some of the proposals to be effective. I had my own proposal that doesn't rely on any of this, and that could be implemented and deployed in a few days (OK after spending at least a few months or so thinking about the design, the engineering, and the implications.) In the spirit of mutt: All these ideas suck; I just think that one sucks a little less. ------------------------------------------------------------- {1} Some further specifics for (1) Anonymity and identification/authentication can be entirely compatible. By this I mean that one can be anonymous (to everyone) as far as one identifier goes but authenticated (to a specific protocol principal) wrt another as part of the same communication. This has been an intentional part of the design of every Onion Routing system including Tor. It contrasts with systems like Crowds, which was directed at distinct but related security properties, thus they made anonymity of the circuit inherently depend on the anonymity of the data passing over it. As a specific example of using Tor for authenticated communication over anonymous circuits, when travelling I often need to log back into NRL to check mail and do other things. I do this via ssh over Tor. That way the local hotel staff, ISP staff, any other network observers don't see me logging in to NRL. But I can assure you that I want to make sure I am going to NRL and no place else and that I want to make sure only I, and no one else, succeeds in accessing my account. (And Jimbo, in my experience, it has been realtime enough to be editing in vi or emacs with no noticeable trouble over this line. I can't say that someone who expects permanent T1 rate downloading is going to be happy with Tor, but you should check it out and see the performance for yourself over a few days, rather than relying on the reports you've heard.) I also discussed this in my testimony to the National Academy of Engineering panel that did a study of authentication and privacy several years ago. (Cf. _Who Goes There? Authentication Through the Lens of Privacy_ from the National Academies Press.) As many have noted, Tor has enough of a job trying to do one thing well. Trying to do more things will just mean it does that thing less well or later. But that does not preclude designing to be compatible with other things, e.g., privoxy to somewhat sanitize, i.e., anonymize web traffic over Tor, or connect to enable authenticated communication via ssh over Tor. (There's a program named `connect' in case you had trouble parsing that.) The discussion now is how to make Tor and Wikipedia compatible, the interface as Nick put it. {2} Yes you can authenticate someone who is anonymous from you. Besides various group signature approaches, cf., e.g., my papers on UST (Unlinkable Serial Transactions), or look at the proposal for common terminology (new version recently out) at http://dud.inf.tu-dresden.de/Anon_Terminology.shtml What we called an `anonym' in the UST work and elsewhere they call a `transaction pseudonym'. ------------------------------------------------------------- ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://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]

1 0

Re: [Freedombox-discuss] Tahoe-LAFS is like a Bittorrent with which you can upload as well as download
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

On Thu, Jun 7, 2012 at 7:29 AM, Nick Daly <nick.m.daly(a)gmail.com> wrote: > > What's Tahoe's required overhead? Is it static (5KB, regardless of > partition size), or does it grow with the reserved space (2% from 0 - > 5 GB, 3% for > 5GB)? Hm, I'm not exactly sure. In general, people tend to allocate large amounts of disk space to one Tahoe-LAFS storage server, like at least 0.5 TB, and then not worry about the few KB or MB of overhead that Tahoe-LAFS adds. The storage server process is the one that stores ciphertext on disk and sends and receives ciphertext over TCP on behalf of a storage client. It stores each piece of ciphertext in a separate file in its local filesystem, and it organizes those files into 2-level hierarchy of directories. That's a source of overhead, since it takes a little more than X bytes of disk space to store an X byte file in your file system. That overhead is proportional to the number of files stored and the exact amount is determined by the filesystem, but I would estimate 2 KiB per file. Another source of overhead is that the storage server maintains a couple of small files of metadata about which files it has processed. That is a small fixed amount that doesn't grow with the number or size of files. It's probably around 10 KB. Another source of overhead is per-file metadata -- leases (markings showing that someone said "I'm interested in this file -- please don't garbage-collect it for at least 30 more days!"), and integrity-checking hashes. The integrity checks are proportional to the size of each file, but small. It's about 64 bytes of hashes for each 40 KB of file. > My biggest concern with this is space, as the 2GB microSD card the DreamPlug comes with is tough to manage. If we can use the SD card slot when it's available, this'll be less of a problem, but I haven't really thought about that problem yet. My instinct would be not to try to make use of such scarce storage resources, but instead say "Want to contribute to the great FreedomBox Cloud Storage grid? Then plug in a 1 TB hard drive to the USB port!". That would actually make the resulting storage much more reliable, because only people who felt a certain level of willingness to contribute would run a Tahoe-LAFS storage server at all. By excluding all the people who turned it on at some point and then got bored a few hours later and turned it off again, we would greatly reduce the churn and unreliability. Regards, Zooko _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0