July 2018 - cypherpunks-legacy

Nov. 26: Barry Hurewitz, HIIP Seminar on Privacy; Nov. 29: Jerry
by HIIP＠Harvard.edu 06 Jul '18

06 Jul '18

Hausman, New Directions in Regulation Seminar on Broadband Access To: HIIP(a)Harvard.edu Date: Wed, 21 Nov 2001 17:07:35 -0500 HIIP Seminar "Current Developments in U.S. Data Privacy Regulation" Barry J. Hurewitz Government and Regulatory Affairs, Hale and Dorr LLP Monday, November 26, 2001 noon-1:30 p.m. BCSIA Library, Littauer Room 369, 3rd Floor John F. Kennedy School of Government Regulatory protection of personal privacy in the U.S. has risen from obscurity in the past few years. Sector by sector, privacy regulations have transformed e-commerce and invigorated advocates of personal information privacy. Privacy protections have been extended to driver's license information, children's online information, financial data, wireless communications, and health records. A combination of industry self- regulation and government enforcement has shaped emerging practices in consumer online privacy. Now, the change in administrations, the war on terrorism, emerging technologies and economic trouble in the online industry are changing the privacy debate in Washington. The FTC has abandoned its call for new privacy laws, and Congress has expanded law enforcement surveillance powers. What is the U.S. regulatory structure for privacy protection? What is happening to e-privacy? Does better information need to compromise privacy? How will the current trend affect e-business? Barry Hurewitz, a partner in Hale and Dorr's Government & Regulatory Affairs Department, has a multidisciplinary practice focusing on federal legislative and regulatory matters affecting technology companies, including federal technology policy, regulatory compliance, government procurement, and technology transfer. As data privacy and security issues have expanded across the high- technology sector, Mr. Hurewitz has advised clients on U.S. and international data privacy developments, including Internet privacy, health data privacy, financial privacy, the U.S.-EU Safe Harbor program for protecting personal data about EU persons, federal surveillance techniques, and privacy in telecommunications. Hurewitz' practice includes regulatory counseling, developing internal corporate data protection procedures, responding to enforcement actions and private claims, participating in the development of new regulations, and tracking emerging state and federal privacy legislation. HIIP Seminar - Schedule for Remaining Sessions, Autumn 2001 December 3 Tim Berners-Lee, Director, World Wide Web Consortium (W3C), and Senior Research Scientist, Laboratory for Computer Science, MIT Seminars to be held on Mondays, 12-1:30pm, BCSIA Library, Room Littauer 369, John F. Kennedy School of Government This is a brown bag style seminar with limited seating available. The schedule is posted at <http://www.ksg.harvard.edu/iip/HIIP-Seminar.html >. The 2001-2002 HIIP Seminar Series is dedicated to the memory of Michael L. Dertouzos (1936-2001). Thursday, November 29, 2001 12:00 - 1:30 p.m. Bell Hall John F. Kennedy School of Government The Regulatory Policy Program and The Harvard Information Infrastructure Project, Center for Business and Government, John F. Kennedy School of Government invite you to attend a New Directions in Regulation Lunch Seminar with Jerry Hausman on "Broadband Internet Access: The Effect of Asymmetric Regulation" The growing market for current digital cellular service (2G) is beginning to decrease the usage of wireline (traditional) telephone service. Although long distance usage is decreasing, as is local usage in countries where consumers pay to make local calls, wireline telephone service offers broadband (high speed) Internet service which current mobile 2G technology cannot offer. Professor Hausman will explore whether the next generation mobile technology, 3G, will provide an adequate data substitute for wireline service. If it does, the need for regulation for wireline service is likely to disappear along with the numerous distortions in the economy that traditional forms of regulation create. Jerry A. Hausman is the John and Jennie S. MacDonald Professor of Economics at the Massachusetts Institute of Technology. He has taught at MIT for 28 years. He is Director of the MIT Telecommunications Economics Research Program. Professor Hausman teaches a course, "Competition in Telecommunications," to graduate students in economics and business. He is also a Special Consultant to Lexecon, Inc. Professor Hausman received the John Bates Clark Award from the American Economics Association in 1985 for the most outstanding contributions to economics by an economist under 40 years of age. He also received the Frisch Medal from the Econometric Society. Professor Hausman has published numerous papers in econometrics and applied microeconomics. His recent applied research has been in differentiated products and in telecommunications. --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Lucrative update
by Patrick 06 Jul '18

06 Jul '18

Lucrative release 4 is out. I know many people are used to seeing releases numbered like "0.000001", "0.000002", "2.0.3.0.14.657" etc. but release numbering systems are essentially arbitrary in nature so don't get excited as Lucrative goes toward version 50+. This release is a fairly minor one, but included some changes such as the client name that I wanted to get out as soon as possible. There is also a new development weblog at http://lucrative.thirdhost.com/weblog/. I went through an install with someone over IRC last night and made a blog entry summarizing the install notes. I recommend reading the notes before attempting an install. I am glad to help with an install, drop me a note at patrick(a)lfcgate.com if you have trouble. Some documentation on the various entities in the Lucrative system is now available on the website, http://lucrative.thirdhost.com/documentation.php but more is needed and coming. If Lucrative is interesting to you, please consider helping in any way you can: Feedback Installation reports Suggestions Comments Criticism Feature requests Source code patches Donations Are all very much welcomed. And criticism is more useful to me than praise. My sincere thanks to everyone who has participated so far by installing, testing, providing feedback, spreading the word, and donating. And finally I just received word from SourceForge that the project registration for Lucrative has been approved. Regards, Patrick -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBD5ECKcRBADUvjXHwLtxIyS4AyjBs/dFtN6rdeP18Fhzh1hD5fJwkFevqY9Z I1ASROTh6eXYF7pU5sEvbcPshHyTB41ZtTqZvQvpwWN0fUzOuutuI0mtC5UPp9Rz j47SdWLdEXNHjwnHDCYSyqtqZu8GujGRQybR0eP3NIh/NwbSDUKdgz7IjwCg//Jo UtjP3zUFobm/0UYA+CJ5krED/091x9Js0gwNwvjbzM8DqO+r8qNz0kXI13FkrPRk QNd37lxt6m2m8HZD1WYM2wKwtMzHSwJcWzaDZ/tNc+ppYjzpw0EQCh9FqjGs8Vau guF6PA1M8lJTCcLKaL4e7ynic+PAw5Xa/tdOYgFCG+eLMU5RLvzRCYoOLIjgMJLJ yG98BACAMlDmFVYgC/UKvzZmHfZ5CtCKd8sPfCXrYLu5NeFRE0LR6D6zjzmhi1xX okfreR5o3T/y78VBM98js+m2/+7Z0AElqydeW/RnV1zqwDGjDr9z2MgARf3yLAbs n3BU8Fz61RwvHy6cRkT+2dR2f69QQUSpkupvLwZIGX/iwm4uKLQdUGF0cmljayA8 cGF0cmlja0BsZmNnYXRlLmNvbT6JAE4EEBECAA4FAj5ECKcECwMCAQIZAQAKCRBb mvb9yuOVfaA2AKDAu5tDj9F2KI8cJMrKKkQRAcUyxACg6/bei7lUJH+E5igJqGRx SjKrRA65BA0EPkQIpxAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICD/wKwtF7Y4NKBe8PQ6jDbjWziiTv9Ac/EnRTJDQEoqgLa2LyE+6Ahw/VPGvp mfxkD2MKxC9E7kYVmasn6sHnSpvAv3e7O1Bqbo/qLzzCcJQ5VCurZ+elRM1GZ4Oc fM19FPKutb0/JFEv0nrqS4BGkF7WFBbu5dKYl/GIO7Co1mAerFIb719dOwMPVEIz OT08u8uB9jyR8gEElf+CVuNfOUkrUGg4HS4SbmTTrCSz3/8n5PkquSuAyjCB/dwM ZsZwA0/TTR8sDYlmlf9xPj5PGpGnV9OUwfig6eE0eWtRFeasmz0uiX+yp45ABtNh 6EXP/PFaBgXi9omXXjeeFYfpDvmfA6izvTIQfXTV6V9ZWrBfXarM+GQ+6guXWVbd 9fXvmCr982LkzuKQrK1OpRXBMUapXL+tOy/LYzz91InqKKhgPNGa12fvotZ4LzlM iqoM+Hpz5L9B5We1Ph0lD6RBVXDCqd+P8extnY/7AaDy7tC0UghaAaUuEZXJQPIc oQ3QGbpjM0nGe/VZN5EZhljau0NNENFaU56cOpvOhcO04gLGNNc2NS+rIpTMsaHh o1CG90c5zZZJuUbyx0mIHriNQXDgEwunSZPQorKK9KSppyyjeuOyi5F/mBBPXeyT weLhLqLvAr9se/+Z3aQvMADJi8zUZtGggLTw+N9R5XSwtSh2R4kARgQYEQIABgUC PkQIpwAKCRBbmvb9yuOVfWayAKC+mBhHdn1XZ5uH0RocAyJ32hx2kgCePyhB+IqM TjWLDLarQxcPYhbkFi4= =nx1M -----END PGP PUBLIC KEY BLOCK----- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

[i2p] Tunnel cryptography for I2P 0.5 (corrected typo)
by barnesc＠engr.orst.edu 06 Jul '18

06 Jul '18

Citizens of I2P, The following is a discussion of tunnel cryptography plans for I2P 0.5. There are two options; one will be chosen. [1] and [2] offer more complete discussion of these plans. Note that the cryptographic methods discussed in [2] are incomplete. They are complete in this message. - Connelly ---------------------------------------------------------------------- Tunnel cryptography for I2P 0.5 ---------------------------------------------------------------------- Currently when I2P 0.4.x passes an (end-to-end encrypted) message M down a tunnel, it is easy for two attackers in different locations of the tunnel to observe the same message M. This makes I2P highly vulnerable to the predecessor attack. Can this situation be improved? The best implementations we currently know of fit in two categories, and use symmetric cryptography. The categories are: 1. The inbound tunnel gateway knows all symmetric private keys used by other hops in the tunnel. The outbound tunnel endpoint knows only its own symmetric private key. Messages are checksummed to prevent modification. Pros: Tagging attacks are defeated. Cons: Attacking an N-length inbound tunnel won't be much harder than attacking a 2-length inbound tunnel. If the gateway is malicious, then the gateway can collude with a malicious hop at any other position in the tunnel; thus the two can identify that they are in the same tunnel. => Predecessor attack. This was one plan by jrandom. A proposed implementation is given [1]. This implementation could be subject to tagging attacks in certain cases. I have a revised scheme in mind that may be safe from these attacks. 2. The inbound tunnel gateway has only its own symmetric private key. Likewise for the outbound tunnel endpoint. No messages are checksummed in the tunnel. All messages have the same size in the tunnel to prevent tagging. Synchronized PRNGs may be used as described at [2] to help prevent tunnel loops (where an attacker DoSes several peers by placing them a "looped" tunnel). Pros: Attacking an N-length inbound tunnel is not easy (one must do timing or message counting analysis). Cons: Tagging (this can be done, but not detected), tunnel loops can be created, extra packets can be generated within the tunnel. This plan was originally drafted in [2] based on a discussion by jrandom and ???. However, this document has pending modifications because it is not a complete cryptosystem. A full implementation plan is appended to the end of this document, based on a discussion by jrandom and Connelly. One of these options will (presumably) be used in I2P 0.5. If you discover a flaw or improvement for either implementation, let us know. If you have other useful input, drop by IRC or post a message to this maillist. We have not found a complete cryptographic analysis for either option. We are using standard cryptographic primitives and methods when possible. Option 2 is known as a "non-checksummed tunnel." ---------------------------------------------------------------------- Proposed Implementation (non-checksummed tunnels) ---------------------------------------------------------------------- Leaving out the PRNGs. As part of a tunnel, we receive and send messages which contain {preIV, payload}. Here preIV is a single block from which the initialization vector (IV) is derived, and payload is a sequence of blocks containing the message which is being delivered down the tunnel. Here 'block' is any string which the symmetric block cipher can operate on. The preIV and the payload are successively wrapped in layers of encryption as a message travels down an inbound tunnel, and messages are successively unwrapped for outbound tunnels. Encryption at hop i: 1. Drop packet (with warning) if we've seen preIV before for a previous message in this tunnel [3]. 2. IV := hash(preIV + hop i's secret key 1) 3. preIV := ecb_encrypt(preIV, hop i's secret key2) 4. payload := cbc_encrypt(payload, hop i's secret key3, IV) 5. Return {preIV, payload}. Decryption at hop i: 1. preIV := ecb_decrypt(preIV, hop i's secret key2) 2. IV := hash(preIV + hop i's secret key1) 3. payload := cbc_decrypt(payload, hop i's secret key3, IV) 4. Return {preIV, payload}. Inbound tunnel: * Message M arrives at the inbound gateway, aka hop 1. * Hops 1, 2, ..., N successively encrypt. * We are the tunnel endpoint, and we have everyone's secret keys, so we can use decrypt(N), decrypt(N-1), ...decrypt(1) to unwrap the encryption made by others. We recover message M. Outbound tunnel: * We have a message M we want to send. * We are the tunnel creator, so we have everyone's secret keys. We build M* by doing encrypt(N), encrypt(N-1), ..., encrypt(1). * We send M* to hop 1. Hops 1, 2, ..., N successively decrypt. * The outbound tunnel endpoint recovers M. [1]. http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel.html?rev=HEAD [2]. http://dev.i2p.net/~jrandom/tunnel-alt.html [3]. A hash table or alternatively a bloom filter can be used to detect whether we have previously seen a preIV. This document has been placed in the public domain by Connelly Barnes, 2005-01-17. _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [liberationtech] Silent Circle Dangerous to Cryptography Software Development
by Nadim Kobeissi 06 Jul '18

06 Jul '18

On 10/11/2012 2:14 PM, Katrin Verclas wrote: > Having sat for the better part of the day with Phil Zimmerman with activists and journalists in a room, here is what I learned: > > On Oct 11, 2012, at 12:15 PM, Nadim Kobeissi wrote: > >> On 10/11/2012 12:04 PM, James Losey wrote: >>> Hi Nadim, >>> >>> I largely agree with your assessment of Silent Circle and I offer these >>> thoughts in an effort to increase my understanding of the issue. The >>> product is a packaged "solution" clearly targeted towards business >>> customers focused on corporate privacy. And while the company offeres >>> regular transparency statements on government requests and strives to >> >> Unless hit by a search warrant and a gag order at the same time, or a >> federal subpoena. > > Zimmerman stated that servers are located in Canada to avoid US subpoenas (not a lawyer, not sure what's that worth in the end). His entire IP block is connected to servers in the United States. I am very skeptical of that claim. Furthermore, this is nonsense; the issue isn't being protected against *one* country's subpoena, it's being protected against *any* subpoena. > > According to the Silent Circle website: > > Websites and products that donbt list the people behind the technology or where their servers are located, how the encryption keys are held or even how you can verify that your data is actually encrypted, are typical of the industry and provide only pseudo-security based on a lot of unverifiable trust. > > Our secure communications products use b Device to Device Encryptionb b putting the keys to your security in the palm of your hand (except for Silent Mail, which is configured for PGP Universal and utilizes server side key encryption). We DO NOT have the ability to decrypt your communications across our network and nor will anyone else - ever. The closed-source nature of the software makes pushing government-mandated backdoors incredibly easy and extremely difficult to detect if done right. This is a tall claim not backed by evidence or the possibility of review. > Silent Phone, Silent Text and Silent Eyes all use peer-to-peer technology and erase the session keys from your device once the call or text is finished. Our servers donbt hold the keysb&you do. Our secure encryption keeps unauthorized people from understanding your transmissions. It keeps criminals, governments, business rivals, neighbors and identity thieves from stealing your data and from destroying your personal or corporate privacy. There are no back doors, nor will there ever be. ...unless they're served a court order, in which case Silent Circle will either implement a backdoor or go to jail, thank you very much. > > > More importantly, Zimmerman noted that Silent Circle code will be made available for audit. > Skype, too, says that its code is available for audit, and then only lets a single academic audit it via an auditing that they themselves fund. This is likely PR; I will not be satisfied unless anyone can audited the code, and the source code is kept updated with every new release. > >> >>> minimize storage of some types of data (and you're right that payment >>> info is problematic) the company is clearly interested in paying for >>> privacy assurances and seems less focused on supporting activists. > > According to Zimmerman (who was keenly interested in use cases for activists) will make licenses available to activists at no cost. They have not figured out the process for this yet, but we'll certainly follow up with them. This is just really scary -- a piece of closed source, unaudited, unverifiable software that costs money for corporations, but is free for activists? > > > Katrin > > -- > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech > NK -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: another seeming attack on my server's DirPort
by Olaf Selke 06 Jul '18

06 Jul '18

Scott Bennett wrote: > I still don't understand the thinking of those people. I have no reason > to believe that the Chinese government is allowing the NSA to control IP > addresses allocated to, and served inside, China. It makes no sense at all, > and leads me to conclude that the whole list is worthless. I do agree. The same here. I don't believe all German major Telcos are NSA affiliated. Olaf ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: thoughts on one time pads
by bear 06 Jul '18

06 Jul '18

On Thu, 26 Jan 2006, Travis H. wrote: > For example, you may have occasional physical meetings with a good > friend, colleague, family member, or former co-worker. Let's say > you see them once every few years, maybe at a conference or a > wedding or a funeral or some other occasion. At such times, you > could easily hand them a CD-ROM or USB flash drive full of key > material. Then, you could use that pad to encrypt messages to them > until the next time you meet. Let's say you send them ten 1kB > messages per year. Then a $1 CD-ROM would hold enough data for > 70000 years of communication! Heck, I could put the software on the > image and make a dozen to keep with me, handing them out to new > acquaintances as a sort of preemptive secure channel. It's far easier and less error-prone to hand them a CD-ROM full of symmetric keys indexed by date. The problem is that most people will not take the care needed to properly use a one-time pad. For text communications like this forum, they're great, and a (relatively) small amount of keying material, as you suggest, will last for many years. But modern applications are concerned with communicating *DATA*, not original text; someone on the system is going to want to send their buddy a 30-minute video of the professor explaining a sticky point to the class, and where is your keying material going then? He wants to be ignorant of the details of the cryptosystem; he just hits "secure send" and waits for magic to happen. Or if not a 30-minute video, then the last six months of account records for the west coast division of the company, or a nicely formatted document in a word processor format that uses up a megabyte or two per page, or ... whatever. The OTP is nice for just plain text, but the more bits a format consumes, the less useful it becomes. And fewer and fewer people even understand how much or how little bandwidth something is; they think in terms of "human bandwidth", the number of seconds or minutes of attention required to read or listen to or watch something. An OTP, as far as I'm concerned, makes a really good system, but you have to respect its limits. One of those limits is a low-bandwidth medium like text-only messages, and in the modern world that qualifies as "specialized." Given a low-bandwidth medium, and indexing keying material into daily chunks to prevent a system failure from resulting in pad reuse, you get 600 MB on a CD-ROM. Say you want a century of secure communications, so you divide it into 8- kilobyte chunks -- each day you can send 8 kilobytes and he can send 8 kilobytes. (Note that DVD-ROMs are better). That gives you a little over 100 years (read, "all you're likely to need, barring catastrophic medical advances,") of a very secure low-bandwidth channel. Of course, the obvious application for this OTP material, other than text messaging itself, is to use it for key distribution. Bear >Bruce acknowleges this by saying "[t]he exceptions to this are >generally in specialized situations where simple key management is a >solvable problem and the security requirement is timeshifting." He >then dismisses it by saying "[o]ne-time pads are useless for all but >very specialized applications, primarily historical and non-computer." > >Excuse me? This would in fact be a _perfect_ way to distribute key >material for _other_ cryptosystems, such as PGP, SSH, IPSec, openvpn, >gaim-encryption etc. etc. You see, he's right in that the key >distribution problem is the hardest problem for most computer >cryptosystems. So the OTP system I described here is the perfect >complement for those systems; it gives them a huge tug on their >bootstraps, gets them running on their own power. > >I'm not sure it is even limited to this use case. For example, before >a ship sets out to sea, you could load it up with enough key material >to last a few millenia. How much key material could a courier carry? >I bet it's a lot. As they say, "never underestimate the bandwidth of >a station wagon full of tapes". And don't embassies have diplomatic >pouches that get taken to them and such? > >So my questions to you are: > >1) Do you agree with my assessment? If so, why has every crypto >expert I've seen poo-pooed the idea? > >2) Assuming my use case, what kind of attacks should I worry about? >For example, he might leave the CD sitting around somewhere before >putting it in his computer. If it sits around on CD, physical access >to it would compromise past and future communications. If he copies >it to flash or magnetic media, then destroys the CD, we can >incrementally destroy the pad as it is used, but we have to worry >about data remanence. > >3) How should one combine OTP with another conventional encryption >method, so that if the pad is copied, we still have conventional >cipher protection? In this manner, one could use the same system for >different use cases; one could, for example, mail the pad, or leave it >with a third party for the recipient to pick up, and you >opportunistically theoretical security if the opponent doesn't get it, >and you get empirical (conventional) security if they do. > >4) For authentication, it is simple to get excellent results from an >OTP. You simply send n bytes of the OTP, which an attacker has a >2^-8n chance in guessing. How do we ensure message integrity? Is it >enough to include a checksum that is encrypted with the pad? Does it >depend on our method of encipherment? Assuming the encipherment is >XOR, is a CRC sufficient, or can one flip bits in the message and CRC >field so as to cancel each other? If so, how should we compute a MIC? > Just SHA-1, and include that right after the plaintext (that is, we >encrypt the MIC so as to not reveal a preimage if SHA-1 is found to be >invertible)? > >5) How should one decouple message lengths from plaintext lengths? > >6) How should one detect and recover from lost, reordered, or partial messages? > >All I've got to say is, I'm on this like stink on doo-doo. Being the >thorough, methodical, paranoid person I am, I will be grateful for any >pointers to prior work and thinking in this area. I recall Jim Choate >from the Austin cypherpunks saying he was working on a OTP system, but >never heard any more about it (let's not discuss him though please, >this thread is about one time pads). >-- >"The generation of random numbers is too important to be left to chance." > -- Robert R. Coveyou -><- http://www.lightconsulting.com/~travis/ >GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B > >--------------------------------------------------------------------- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 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: another seeming attack on my server's DirPort
by Olaf Selke 06 Jul '18

06 Jul '18

Scott Bennett wrote: > I still don't understand the thinking of those people. I have no reason > to believe that the Chinese government is allowing the NSA to control IP > addresses allocated to, and served inside, China. It makes no sense at all, > and leads me to conclude that the whole list is worthless. I do agree. The same here. I don't believe all German major Telcos are NSA affiliated. Olaf ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [silk] Bitcoin
by Alaric Snell-Pym 06 Jul '18

06 Jul '18

On 05/17/11 11:15, Suresh Ramasubramanian wrote: > Alaric Snell-Pym [17/05/11 11:06 +0100]: >> Ah, the limit isn't done like that. 50 bitcoin are generated about every >> 10 minutes, period. The more CPU time you put in, the larger a *share* >> of that you get, but the global rate remains the same. > > the more CPUs you put in? > Well, the more CPU *time*. Technically, to mine bitcoin, you're racing to be the first to find a number that, when combined with the details of a bunch of pending transactions with a complicated function (SHA-256, for the tecchies out there), is less than a target. So you set your CPU trying random numbers, feeding them along with a heap of pending transactions into SHA-256, and seeing if the output is below the target. If it is, you advertise that fact to the network, and you get to spend 50 bitcoin as you see fit. However, it takes something like 2^47 attempts (each attempt is called a "hash") to find an output below the target. My MacBook pro can do about a million - 2^20 - per second, meaning it'd take 2^27 seconds, or about 1500 days, to find one. On average. I might get lucky and find one right away. Or I might not, and take five times that long. So if I put twice as many CPUs in, I could do it in about half the time (on average). Either way, for my kind of CPU, it takes about 1500 days of time to "win a block". If I split that between 1500 CPUs, I can win a block a day! As the system adjusts the difficulty of the target so that, on average, six blocks are won per hour, one per day would give me 1/144 of the entire creation rate of new bitcoins... In practice, the "miners" (people who set out to win blocks) don't use CPUs; they use GPUs (as found on video cards). Certain brands of GPU (ATI ones, it seems) are good at the maths required for SHA-256, so they put loads of graphics cards into their PCs and set them trying out random numbers until they get a 'win'. Even then, it'd still take them weeks... so what most do is to join "pools" and get their systems to cooperate with others. The pool measures how much they're contributing, by them sending the pool evidence of near-misses (results they get that approach the target, but don't make it), by which the pool works out how much CPU time each member is putting in; when somebody in the pool wins the block, the money goes to the pool (and the pool can check that!), so the pool splits it proportionally by how much CPU time was contributed. Really, it's all like a lottery; and the miners get their systems entering the lottery a billion times per second. Currently, the bitcoin network produces about 1.5 trillion hashes per second, total. So somebody managing a billion a second, in a mining pool, earns about a 1500th of the total "income" of new bitcoin - 50 every ten minutes... ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [p2p-hackers] A globally distributed peer-to-peer data archive
by Tony Arcieri 06 Jul '18

06 Jul '18

On Sat, Aug 27, 2011 at 11:39 AM, David Barrett <dbarrett(a)quinthar.com>wrote: > Perhaps I misunderstand Tahoe. Is it intended for groups to share data > (eg, I add a file, you discover and download it), or is it purely for me to > backup my data? > > If the latter -- if it's purely for individual backup -- then I agree > there's no risk from the RIAA: you're not sharing it so there's no problem. > > But if the former -- if there's some way I can join your Tahoe cluster and > access data that's already there -- then would you be willing to let the > RIAA join your cluster with the keys to access the data there? > I think Tahoe fits either use case of a shared file repository or a distributed backup system. There are two levels of credentials you can share: the introducer furls, which grant access to your grid, and the rootcap for a particular directory on the grid, which grants access to a specific set of files. By Tahoe's design you should be able to give the RIAA the introducer furls to your grid. They can then create directories and store data on your grid, and will accept encrypted chunks of files from other peers. However, unless they actually have a rootcap for directories containing infringing content, they have no way of knowing whether or not the chunks they receive from other peers contain this data or not, since it's encrypted. > Because for something like Tahoe to work on a global scale, eventually > you're not going to know with certainty all the other members -- and any one > of those could in fact be the RIAA trolling for people to sue. > I'm envisioning a system where there wouldn't be an encrypted introducer URL to gain access to the grid, instead additional methods to provide a web of trust and collaborative filtering of particular peers would be used to prevent abuse. However, I think Tahoe's rootcap system is still essential. Cryptographic credentials would be required to access any data on the grid. For example, is it possible to determine who (username or IP) added the > content in the first place? To my knowledge Tahoe doesn't log which nodes are responsible for the creation of content on the grid. Instead there are rootcaps which control read and write access to directories on the grid, and anyone with the "writecap" can add content to a particular directory. I may be mistaken as I have just started using Tahoe. In the system I'm envisioning, the anonymity of who created a particular file would definitely be preserved. > Is there some way to differentiate between when a node is requesting a > specific piece of content from you, versus when it's just rebalancing some > tree? > > If so, then it's limited to groups of trusting friends -- still a great > tool, but not a vast treasure of human knowledge as it sounds like you want > to build. > > But if not, if it's truly impossible to know whether a node is downloading > and storing something because the user actually wants it or because the > system forced them to get it unaware, then that could be a pretty good > defense against overzealous copyright enforcement. > > Though I wonder if a simpler model is to just start with something like > BitTorrent, except every time you download anything, you also download > something else randomly. So half of the content you download/seed is what > you actually picked, and the other half is random. Then there's no way from > the outside to tell which was for you, versus which is caching random > content to increase the uptime and performance of the whole system. I'd certainly agree BitTorrent could be the underlying technology underlying this system, layering the discovery and crypto on top of a BitTorrent-based system underneath, although I'd prefer it has more filesystem-like semantics like Tahoe. Perhaps BitTorrent with an "earliest-first" instead of "rarest-first" chunk selection mechanism would work. -- Tony Arcieri _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [silk] Bitcoin
by Alaric Snell-Pym 06 Jul '18

06 Jul '18

On 05/17/11 11:15, Suresh Ramasubramanian wrote: > Alaric Snell-Pym [17/05/11 11:06 +0100]: >> Ah, the limit isn't done like that. 50 bitcoin are generated about every >> 10 minutes, period. The more CPU time you put in, the larger a *share* >> of that you get, but the global rate remains the same. > > the more CPUs you put in? > Well, the more CPU *time*. Technically, to mine bitcoin, you're racing to be the first to find a number that, when combined with the details of a bunch of pending transactions with a complicated function (SHA-256, for the tecchies out there), is less than a target. So you set your CPU trying random numbers, feeding them along with a heap of pending transactions into SHA-256, and seeing if the output is below the target. If it is, you advertise that fact to the network, and you get to spend 50 bitcoin as you see fit. However, it takes something like 2^47 attempts (each attempt is called a "hash") to find an output below the target. My MacBook pro can do about a million - 2^20 - per second, meaning it'd take 2^27 seconds, or about 1500 days, to find one. On average. I might get lucky and find one right away. Or I might not, and take five times that long. So if I put twice as many CPUs in, I could do it in about half the time (on average). Either way, for my kind of CPU, it takes about 1500 days of time to "win a block". If I split that between 1500 CPUs, I can win a block a day! As the system adjusts the difficulty of the target so that, on average, six blocks are won per hour, one per day would give me 1/144 of the entire creation rate of new bitcoins... In practice, the "miners" (people who set out to win blocks) don't use CPUs; they use GPUs (as found on video cards). Certain brands of GPU (ATI ones, it seems) are good at the maths required for SHA-256, so they put loads of graphics cards into their PCs and set them trying out random numbers until they get a 'win'. Even then, it'd still take them weeks... so what most do is to join "pools" and get their systems to cooperate with others. The pool measures how much they're contributing, by them sending the pool evidence of near-misses (results they get that approach the target, but don't make it), by which the pool works out how much CPU time each member is putting in; when somebody in the pool wins the block, the money goes to the pool (and the pool can check that!), so the pool splits it proportionally by how much CPU time was contributed. Really, it's all like a lottery; and the miners get their systems entering the lottery a billion times per second. Currently, the bitcoin network produces about 1.5 trillion hashes per second, total. So somebody managing a billion a second, in a mining pool, earns about a 1500th of the total "income" of new bitcoin - 50 every ten minutes... ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ----- 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