- cypherpunks - lists.cpunks.org

Re: [cryptography] The Compromised Internet
by grarpamp 27 Sep '13

27 Sep '13

On 9/27/13, Eugen Leitl <eugen(a)leitl.org> wrote: > On Fri, Sep 27, 2013 at 01:12:19PM -0400, grarpamp wrote: >> >> The mentioned tech has nothing to do with traditional 'ham'. >> And without the crypto key they can't see it and can't disrupt > > HamNet/AMPRNet ... > Of course they can see it, it's a TCP/IP network routed Again, I'm not talking about encrypting packets and stuffing them over some simple carrier centered at n-MHz. That's old tech, and possibly dangerous to the well being of users noted in the OP before me.

1 0

Re: [tt] How a Crypto ‘Backdoor’ Pitted the Tech World Against the NSA
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from Christian Weisgerber <naddy(a)mips.inka.de> ----- Date: Fri, 27 Sep 2013 16:11:47 +0000 (UTC) From: Christian Weisgerber <naddy(a)mips.inka.de> To: tt(a)postbiota.org Subject: Re: [tt] How a Crypto ‘Backdoor’ Pitted the Tech World Against the NSA Eugen Leitl <eugen(a)leitl.org> wrote: > http://www.wired.com/threatlevel/2013/09/nsa-backdoor/all/ These articles from Matthew Green's Blog offer a better understanding instead of cutesy writing and soundbites: The Many Flaws of Dual_EC_DRBG http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrb… RSA warns developers not to use RSA products http://blog.cryptographyengineering.com/2013/09/rsa-warns-developers-agains… -- Christian "naddy" Weisgerber naddy(a)mips.inka.de _______________________________________________ tt mailing list tt(a)postbiota.org http://postbiota.org/mailman/listinfo/tt ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1

Re: [cryptography] The Compromised Internet
by grarpamp 27 Sep '13

27 Sep '13

On 9/27/13, Eugen Leitl <eugen(a)leitl.org> wrote: > I don't see how a ham running a repeater backbone can > prevent end to end encryption other than sniffing for > traffic and actively disrupting it. I'm not sure tampering > with transport is within ham ethics, though they definitely > don't understand the actual uses for encryption, at > least the old hands (are there even new hands?). The mentioned tech has nothing to do with traditional 'ham'. And without the crypto key they can't see it and can't disrupt it, it's background/spectrum noise/power to them. Traditionally, presumably hams might discover non-in-the-clear on a specific channel, perhaps triangulate, and report it to some regulatory body (or DoS it). That's not applicable, by design.

1 0

[liberationtech] FW: What the IETF is thinking about Prism these days..
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from michael gurstein <gurstein(a)gmail.com> ----- Date: Fri, 27 Sep 2013 08:55:16 -0700 From: michael gurstein <gurstein(a)gmail.com> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] FW: What the IETF is thinking about Prism these days.. X-Mailer: Microsoft Outlook 14.0 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> Title : Prismatic Reflections Author(s) : Brian Carpenter Filename : draft-carpenter-prismatic-reflections-00.txt Pages : 9 Date : 2013-09-19 Abstract: Recent public disclosure of allegedly pervasive surveillance of Internet traffic has led to calls for action by the IETF. This draft exists solely to collect together a number of possible actions that were mentioned in a vigorous discussion on the IETF mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00 -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] RSA recommends against use of its own products.
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from Jerry Leichter <leichter(a)lrw.com> ----- Date: Wed, 25 Sep 2013 14:12:25 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: ianG <iang(a)iang.org> Cc: cryptography(a)metzdowd.com Subject: Re: [Cryptography] RSA recommends against use of its own products. X-Mailer: Apple Mail (2.1510) On Sep 25, 2013, at 12:31 PM, ianG <iang(a)iang.org> wrote: > Hi Jerry, > > I appreciate the devil's advocate approach here, it has helped to get my thoughts in order! Thanks! :-) > My conclusion is: avoid all USA, Inc, providers of cryptographic products. In favor off ... who? We already know that GCHQ is at least as heavily into this monitoring business as NSA, so British providers are out. The French have been playing the "oh, we're shocked, shocked that there's spying going on" game - but they have a long history of their own. It's been reported for many years that all Air France seats are bugged by the French security services and the information recorded has been used to help French economic interests. And even if you don't think a particular security service has been going after in-country suppliers, recall decades of US spiking of the Swiss Crypto AG machines. It's a really, really difficult problem. For deterministic algorithms, in principle, you can sandbox the implementation (both physically and in software) and compare inputs and outputs to a specification. That leaves you to worry about (a) holes in the specification itself; (b) physical leakage of extra information (Tempest-like). Both of these can be dealt with and you can gain any degree of assurance you consider necessary, at least in principle. Sure, someone can spike your hardware - but if it only does what the spec says it's supposed to do, what does that gain them? (Storing some of your secrets within the sandboxed system does them no good if they can't get the information out. Of course, physical security is essential, or your attacker will just walk the system, with all its contained information, out the door!) For probabilistic algorithms - choosing a random number is, of course, the simplest example - it's much, much harder. You're pretty much forced to rely on some mathematics and other analysis - testing can't help you much. There are really no absolutes; you really have to think about who you want to protect yourself from and how much you are willing to spend, because there's no limit on how much you *could* do. Build your own foundry? Create your own circuit synthesis code? You very quickly get yourself into a domain where only a handful of companies or countries can even begin to go. My take on this: I don't much worry about attacks against general-purpose hardware. The difficulty of modifying a processor so that you can tell when it's implementing a cipher and then do something useful about it seems insurmountable. The exception is when the hardware actually gets into the crypto game - e.g., the Intel AES extensions and the random number generator. If you're going to use these, you need to do so in a way that's secure even if those features are spiked - e.g., use the random number generator only as one of a couple of sources. Still, *much* more worrisome are the badly implemented, insecure extensions to allow remote control of the hardware, which are being discussed in a separate thread here. These are really scary - there's no protection against an attacker who can send a magic packet to your network interface and execute code with full privileges. Code, at least for symmetric cryptography primitives and modes, is simple enough that you can find it all over the place. Realistically, the worst attacks against implementations these days are timing attacks. Bernstein's ciphers have the advantage of being inherently secure against these, showing that this is possible (even if you don't necessarily trust his particular constructions). Denker's ideas about how to get random numbers whose safety is based on physical principles are great. You do have to be careful of the hardware and software you use, but since the hardware is designed for entirely different purposes (A/D sound converters) it's unlikely anyone has, or really could, spike them all. It's the asymmetric algorithms and implementations that seem to be the most vulnerable. They are complex and difficult to get right, much less to get both efficient *and* right, and protocols that use them generally need to be probabilistic - so "black box testing" isn't feasible. At the same time, they have rich mathematical structures in which we know things can be hidden. (In the symmetric case, the algorithms are generally have little mathematical structure, and we *assume* nothing can be hidden in there - but who can really say with absolute confidence.) I had a long debate here earlier on this subject, and my own conclusions remain: Use symmetric crypto as little as you possibly can. (What would be really, really nice is something like DH key exchange without all the mathematical structure.) -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 2

Re: [p2p-hackers] BitWeav: open P2P micropublishing
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from CodesInChaos <codesinchaos(a)gmail.com> ----- Date: Fri, 27 Sep 2013 16:49:52 +0200 From: CodesInChaos <codesinchaos(a)gmail.com> To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> Subject: Re: [p2p-hackers] BitWeav: open P2P micropublishing Reply-To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> Bitcoin only uses RIPEMD160(SHA256(x)) only in places where the relevant attack is a second pre-image, not a collision. If neither hashfunction is pathological, the pre-image resistance of this construction can't be broken without breaking both hashes. So this construction isn't that silly. > As for length extension attacks, I don't believe I should be concerned, should I? The transfer of messages within the network is dependent on a defined protocol, so any extra bytes would just be interpreted as a malformed message. If you use it in a broken construction, you should be concerned. If you're not, then there is little reason to worry. Length extensions are only a problem with a few specific constructions. In particular using SHA256(k||m) as MAC is broken. If you want a hash based MAC with SHA-2, use HMAC instead. _______________________________________________ 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

What the heck is going on with NIST’s cryptographic standard, SHA-3?
by Eugen Leitl 27 Sep '13

27 Sep '13

https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3 What the heck is going on with NIST’s cryptographic standard, SHA-3? by Joseph Lorenzo Hall [1] September 24, 2013 (Warning: this is a fairly technical post about cryptographic standards setting.) The cryptographic community has been deeply shaken since revelations earlier this month [2] that the National Security Agency (NSA) has been using a number of underhanded methods – stealing encryption keys, subverting standards setting processes, planting backdoors in products – to undermine much of the encryption used online. This includes crucial pieces of e-commerce like HTTPS (SSL/TLS) and Virtual Private Networks (VPN) that we use each day to purchase things online, to socialize in private, and that businesses use to communicate confidential and proprietary information. While the reporting has been vague and hasn’t pointed to specific software versions or protocols that have been compromised, last week RSA Security – a major supplier of cryptographic software and hardware – initiated a product recall [3] of sorts, warning users that one of its popular software encryption products contained a likely NSA-planted backdoor. The practical implication of the RSA recall is that much of the encryption that used this product since 2007 isn’t nearly as secure as it was supposed to be. Those of us who follow developments in the cryptographic community have noticed another troubling development: there are a number of cryptographers upset with how the National Institute of Standards and Technology (NIST) is standardizing a new set of encryption algorithms called SHA-3 (which stands for the third version of the Secure Hashing Algorithm). The remainder of this post explains what is going on with SHA-3 and how NIST could diffuse this particular controversy while it still has the chance. (Warning: In this post, I’m assuming the reader is familiar with the concepts underlying basic encryption tools, called “cryptographic primitives,” such as hash functions [4], digital signatures [5], and message authentication codes [6].) What is SHA-3? SHA-3 is the “next generation” hash algorithm being standardized by NIST. In 2005, researchers developed an attack [7] that called into question the security guarantees of an earlier secure hash algorithm, SHA-1. The characteristics of this 2005 attack seemed to hint that it could be refined to attack many of the secure hash functions at the time, including SHA-0, MD4, MD5 and even SHA-2. At the time, for many cryptographers, the message was clear: a new hash algorithm is needed and it should be based on completely different underlying mathematics that are not susceptible to the attacks threatening known hash functions. To be clear: SHA-1 is thought to be on its way out, as people expect the earlier attacks to be improved considerably in the coming years and there hasn’t been any result that calls into question the soundness of SHA-2 at all. Attacks always improve, so it’s imperative that there is an alternative hash function ready to go when and if the floor falls out of the earlier hash functions. NIST’s cryptographic technology group [8] is world-renowned for cryptographic algorithm standardization. In 2007, NIST began the process to develop and standardize a new secure hash algorithm that would be called SHA-3. The process for choosing a new algorithm was designed as a competition: new candidate algorithms were submitted by more than 60 research teams and over five years the entrants were whittled down to a set of finalists, from which a winner was chosen. In October of last year, NIST announced [9] that a team of Italian and Belgian cryptographers had won the competition with their submission named, “Keccak” (pronounced “KECH-ack”). What has NIST done with SHA-3? Since the announcement of Keccak as the winner, NIST has been working hard to turn Keccak into a standard. That is, NIST can’t just point to the academic paper and materials submitted by the Keccak team and call that a standard. NIST has to write the algorithm up in a standards-compliant format and include it in other NIST cryptographic standards documents, such as a successor to the Secure Hash Standard document (FIPS Publication 180-4) [10]. Here’s where the controversy starts. One of the most accomplished civilian cryptographers, NIST’s John Kelsey, gave an invited talk at a conference in August, the Workshop on Cryptographic Hardware and Embedded Systems 2013 (CHES’13) [11], where he described some of the changes NIST has made to Keccak in turning it into a standard. The changes were detailed in five slides (slides 44-48) of Kelsey’s slide deck for his talk [12]. Two major changes puzzled some in attendance: In the name of increased performance (running faster in software and hardware), the security levels of Keccak were drastically reduced. The four versions of the winning Keccak algorithm had security levels of 224-bits, 256-bits, 384-bits, and 512-bits. However, from Kelsey’s slides, NIST intends to standardize only two versions, a 128-bit and a 256-bit version. Some of the internals of the algorithm had been tweaked by NIST – some in cooperation with the team that submitted Keccak – to improve performance and allow for new types of applications. Essentially, NIST had changed Keccak to something very different from what won the 5-year competition. Since this talk, cryptographers have been abuzz with this news and generally very critical of the changes (e.g., folks like Marsh Ray on Twitter [13]). What are the issues with SHA-3 standardization? So, what’s the big deal? Well, the problems here cluster in five areas: Process: From a simple due process perspective, after a five-year hard-fought competition, to make large changes to the winning algorithm is simply problematic. The algorithm being standardized is very different from the winning Keccak, which beat 62 other high-powered cryptography research groups in a 5-year competition. (To be fair, it’s not like these changes came out of the blue. However, given the new political environment reality itself has changed.) No security improvement: The SHA-3 version of Keccak being proposed appears to provide essentially the same level of security guarantees as SHA-2, its predecessor. If we are going to develop a next generation hash, there certainly should be standardized versions that provide a higher security level than the older hash functions! NIST, in the original call for submissions, specifically asked for four versions in each submission, with at least two that would be stronger than what was currently available, so it’s hard to understand this post-competition weakening. Unclear implications of internal changes: The changes made to Keccak to get to SHA-3 may be so substantial as to render the cryptanalysis that was performed during the competition moot. That is, all the intense number crunching cryptographers performed during the competition to try and break the submitted ciphers to prove their strength/weakness simply doesn’t apply to the modified form of Keccak that NIST is working on. No real need for high-performance hashes: NIST said it weakened the security levels of the winning Keccak submission to boost performance. (Weaker versions of hash functions run faster.) However, there is not clearly a need for another fast hash algorithm. For example, to get exceedingly technical for a moment: in communications security, hashes are used for a few purposes and most are computed on small inputs – where performance isn’t a concern – and in cases where performance is a concern due to large inputs (e.g., with “message authentication codes” or MACs), many applications are moving away from hash-based MACs (HMAC) to other types of MACs like GMAC [14] that are not based on hash functions. NIST’s reputation is undermined: Kelsey’s CHES’13 talk was given in mid-August, two weeks before the NSA encryption revelations. Those revelations [2] suggest that NSA, through an intelligence program called BULLRUN actively worked to undermine NIST’s effort to standardize strong cryptography. NIST could not have known how the changes it made might appear once that reporting had cast a pall over NIST cryptographic standards setting. The changes made to Keccak undoubtedly weaken the algorithm, calling NIST’s motives into question in light of the NSA revelations (regardless of their actual intentions). None of this is irreversible. What could NIST do to diffuse this controversy? Kelsey’s slides indicate that NIST is on track to standardize the NIST-modified version of Keccak as SHA-3 and issue a draft standard in late October for public comment. If the issues above are not addressed in that draft standard, there will be considerable hue and cry from the cryptographic community and it will only serve to reinforce the more general concerns about NIST’s cooperation with the NSA. It’s in no one’s interest to feed the flames of NIST scaremongering and we all have an interest in NIST as a trusted place for science and standardization. In that spirit, there are a number of things NIST can do to calm this storm (and please consider joining NIST’s Hash Forum [15] to discuss this further): Add back high-security modes: NIST must ensure that SHA-3 has strong modes of operation. NIST should at least add back in a 512-bit security level version of Keccak so those users who want exceedingly high security and don’t worry as much about performance have a standardized mode that they can use. In fact, if NIST is worried about performance, it probably makes sense to standardize the as-submitted versions of Keccak (224, 256, 384, 512-bit security levels) and add in a much weaker but high-performance 128-bit version for those users who want to make that trade-off. This would be the “Kumbaya” solution, as it would have five security levels with both the NIST-modified versions and the as-submitted Keccak versions. Justify optimizations and internal changes: NIST has obviously made significant internal changes to the Keccak algorithm. This means that the NIST-modified Keccak and the winner of the SHA-3 competition are likely to be very different. To be sure, there are probably some very good reasons for the changes, but we don’t know what they are, and it would be unfortunate to learn them simply in the draft standard as published in October. Extensive changes should technically be subject to the cryptanalysis that was brought to bear during the actual competition. Unfortunately, it will be impossible to muster the cryptographic scrutiny necessary to examine the NIST-modified Keccak as the resources and teams that worked on this during the competition are no longer available. Here, it makes sense for NIST to standardize both the winning version of Keccak and NIST’s optimized version (“SHA-3-Opt” maybe?), so that implementers can have their pick of whether they want the Keccak that was subject to the grueling competition or an improved version that hasn’t been subject to as much scrutiny. Improve the standardization process: No one doubts that NIST runs high-quality cryptographic competitions. The many-year competitions that resulted in AES (the Advanced Encryption Standard) and SHA-3 marshaled the most gifted cryptographic thinkers in the world to shake down very exotic forms of mathematics to result in very strong, clever and useful practical outcomes. The resulting algorithms look indistinguishable from magic to many of us who are not steeped in the fine art of cryptography. However, the process of getting from the algorithm that won the competition to a standard is a dark and mysterious process, and it need not be. While the relationship between NSA and NIST has always made many of us uneasy, in light of recent revelations, it’s especially important that this standardization step be open and transparent with a formal process that works to ensure that all decisions are made in a well-documented manner and that conditions that ensured an algorithm withstood withering scrutiny during a competition do not subsequently change dramatically during the standardization process. At CDT, we work hard to make sure that standards processes serve the public interest in an open, free and innovative Internet. We’ll be advocating for changes in standards processes at NIST so that it remains an unbiased, trusted, and scientific venue for developing cybersecurity and cryptographic standards. UPDATE [2013-09-24T17:41:24]: Changed title to better reflect that SHA-3 is not an encryption standard but a hash function standard (without using "hash function" in the title). Better qualified that SHA-1 is likely weak in the face of government-level adversaries. Further update [2013-09-25T06:09:38]: clarified that SHA-1 is essentially on its way out. NIST Copyright © 2013 by Center for Democracy & Technology. The content throughout this website that originates with CDT can be freely copied and used as long as you make no substantive changes and clearly give us credit. Details. Source URL: https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3 Links: [1] https://www.cdt.org/personnel/joseph-lorenzo-hall [2] http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.htm… [3] http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/ [4] http://en.wikipedia.org/wiki/One-way_hash_function [5] http://en.wikipedia.org/wiki/Digital_signatures [6] http://en.wikipedia.org/wiki/Message_authentication_code [7] https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html [8] http://www.nist.gov/itl/csd/ct/ [9] http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html [10] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf [11] http://www.chesworkshop.org/ches2013/start.php [12] https://docs.google.com/file/d/0BzRYQSHuuMYOQXdHWkRiZXlURVE/ [13] https://twitter.com/marshray/status/380800393367674880 [14] http://en.wikipedia.org/wiki/Galois/Counter_Mode [15] http://csrc.nist.gov/groups/ST/hash/email_list.html

1 0

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from The Doctor <drwho(a)virtadpt.net> ----- Date: Wed, 25 Sep 2013 12:12:45 -0400 From: The Doctor <drwho(a)virtadpt.net> To: bitcoin-development(a)lists.sourceforge.net Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 Organization: Virtual Adept Networks, Unlimited User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 Reply-To: drwho(a)virtadpt.net -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/25/2013 07:35 AM, Melvin Carvalho wrote: > It depends on the attacker. I think a large entity such as a govt > or big to medium size corporation *may* be able to MITM https, of > course the incentive to do so is probably not there ... DLP (data loss prevention) products usually have MITM capability, to make sure that proprietary information isn't being exfiltrated. Also, some companies have full packet capture policies. The technology is out there and people buy and use it. Whether or not they're going to care about Bitcoin URIs in the short term, I don't know. Some of the companies documented here have such products: http://bluecabinet.info/wiki/Blue_cabinet#List_of_companies You are correct in that the incentive to carry out MITM attacks in this use case may not be there. However, detecting transactions may be more useful to an attacker than meddling with them. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Shiloh? Is your name Shiloh? Can I talk to you?" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJDC30ACgkQO9j/K4B7F8FungCgyQtkyiQIekhlv1/Nqdd/JAIV 3EgAoKW8wTOI11lEq0ieOsRiQmnkM9w6 =W50W -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[tahoe-dev] the GNU 30th Birthday party!
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from Zooko O'Whielacronx <zookog(a)gmail.com> ----- Date: Fri, 27 Sep 2013 05:00:04 +0000 From: Zooko O'Whielacronx <zookog(a)gmail.com> To: tahoe-dev <tahoe-dev(a)tahoe-lafs.org> Subject: [tahoe-dev] the GNU 30th Birthday party! Folks: Tahoe-LAFS is one of the featured projects at the GNU 30th Birthday Party Hackathon! https://www.gnu.org/gnu30/celebration I'm going to be there in person in Cambridge. What I want to do during the Hackathon is make Tahoe-LAFS work better with Tor and/or I2P. I know that at least a couple of Tor developers and at least one I2P developer will be there in person, so this is a good opportunity to collaborate face-to-face or side-by-side. One thing I could spend Hackathon time on is just to contribute some patch review service to the Tor project, if it seems like they want that. Issue tickets relevant to this: Go to https://Tahoe-LAFS.org, click on "View Tickets" → https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ViewTickets , click on "anonymity" → https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~anony… Eyeballing those, I recognize the following as especially ripe, because the I2P folks have been working on them and flagging them as blockers for I2P: #68, #1010. https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement distributed introduction, remove Introducer as a single point of failure https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010# use only 127.0.0.1 as local address See also a couple of patches that the I2P people are trying to contribute to foolscap, and which are also needed for full Tahoe-LAFS+I2P integration: http://foolscap.lothar.com/trac/query?status=!closed&keywords=~i2p You can join in! Just connect to us on IRC -- irc.freenode.net channel #tahoe-lafs -- or physically show up in Cambridge. Or, I suppose, at one of the other GNU 30th Birthday celebrations around the world: https://www.gnu.org/gnu30/ (scroll down to "Satellite Events"). ☺ Regards, Zooko _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: The Unbreakable Cipher (2)
by brian carroll 27 Sep '13

27 Sep '13

coderman wrote: > you're wrong. perfect. thank you (though assumption was more like MMORPG as distributed parallel network keying same space from many unique vantages, where environment* is of different structures and conceptualizations and parts do not necessarily align into a clear 'whole' view, including if many-many exchanges function beyond limits of model or framework) i think i grasp a fundamental concept of crypto that relates size of message (message length) with design of algorithmic structure needed to successfully embed or hide the message else hidden order may be easily visible/discovered i still contend this is different for set theory and models of noise - yet assume equations in that space could function differently and could have other design requirements or crypto principles perhaps more shallow if hiding in massive noise or equations to nest data in higher-dimensional matrices or at various levels, presumably unlike what appears a more static, confined construct of linear equationspace and its requirements in that 'keys' could function differently in bit set approach though perhaps rekeying is universal as a security principle yet potentially flawed if it could reveal a particular structure leading to its compromise whereas reusing an 'infinity key' (regenerating keys or using same key in new instantiations, accessing different arbitrary structure as keychain multitool) may function in a different context than existing approaches, in some way- which relates to the dataspace; such that perhaps the key itself is noisy or indeterminate as to what exactly the key is though this speculation could all be false. *(though of cipher environment presumed 'outside' the capacity of computers to process, rationalize accurately, thus not contained in electronic boxes; thus beyond modeled computer space, infinitely so)

3 2