[Cryptography] funding Tor development
Guys, in order to minimize Tor Project's dependance on federal funding and/or increase what they can do it would be great to have some additional funding ~10 kUSD/month. If anyone is aware of anyone who can provide funding at that level or higher, please contact exec...@torproject.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, Oct 10, 2013 at 03:54:26PM -0400, John Kelsey wrote: Having a public bulletin board of posted emails, plus a protocol for anonymously finding the ones your key can decrypt, seems like a pretty decent architecture for prism-proof email. The tricky bit of crypto is in making access to the bulletin board both efficient and private. This is what Bitmessage attempts to achieve, but it has issues. Assuming these can be solved (a rather large if), and glue like https://bitmessage.ch/ is available to be run by end users it could be quite useful. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
On Thu, Oct 10, 2013 at 04:24:19PM -0700, Glenn Willen wrote: I am going to be interested to hear what the rest of the list says about this, because this definitely contradicts what has been presented to me as 'standard practice' for PGP use -- verifying identity using government issued ID, and completely ignoring personal knowledge. This obviously ignores the threat model of official fake IDs. This is not just academic for some users. Plus, if you're e.g. linking up with known friends in RetroShare (which implements identities via PGP keys, and degrees of trust (none/marginal/full) by signatures, and allows you to tune your co-operative variables (Anonymous routing/discovery/ forums/channels/use a direct source, if available) depending on the degree of trust. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] Asynchronous forward secrecy encryption
- Forwarded message from zooko zo...@zooko.com - Date: Fri, 27 Sep 2013 00:08:32 +0400 From: zooko zo...@zooko.com To: Michael Rogers mich...@briarproject.org Cc: Randombit List cryptogra...@randombit.net Subject: Re: [cryptography] Asynchronous forward secrecy encryption User-Agent: Mutt/1.5.21 (2010-09-15) Let me just mention that this conversation is AWESOME. I only wish the folks over at Perry's Crypto List (http://www.metzdowd.com/pipermail/cryptography/) knew that we were having such a great conversation over here. On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote: The key reuse issue isn't related to the choice between time-based and message-based updates. It's caused by keys and IVs in the current design being derived deterministically from the shared secret and the sequence number. If an endpoint crashes and restarts, it may reuse a key and IV with new plaintext. Not good. Another defense against this is to generate the IV from the plaintext, possibly from the plaintext in addition to other stuff. There are three things that you might want to throw into your IV generator: 1. the plaintext, 2. a persistent secret key used only for this purpose and known only to this client, 3. a random nonce read from the operating system. I would suggest including 1 and 2 but not 3. This *could* be seen as an alternative to the defense you described: In the new design, the temporary keys are still derived deterministically from the shared secret, but the IVs and ephemeral keys are random. Or it could be used as an added, redundant defense. I guess if it is an added, redundant defense then this is the same as including the random nonce -- number 3 from the list above. Regards, Zooko ___ cryptography mailing list cryptogra...@randombit.net http://lists.randombit.net/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 signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Gilmore response to NSA mathematician's make rules for NSA appeal
On Tue, Sep 24, 2013 at 12:30:40PM -0400, Kelly John Rose wrote: If Google, or other similar businesses want to convince people to store data in the cloud, they need to set up methods where the data is encrypted or secured before it is even provided to them using keys which That would completely undermine their free (selling their customers as a service) model. For privacy-minded, the centralist cloud model seems to be irreversibly dead. P2P clouds are currently too unreliable unfortunately. What we need is end to end reachability (IPv6) and sufficient upstream for residential connections, all running on low-power no-movable-part systems (embedded/SoCs). Most of that is still in our future. are not related or signed by a central authority key. This way, even if Google's entire system was proven to be insecure and riddled with leaks, the data would still be secure. You cannot share data that you can never have access to. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Stealthy Dopant-Level Hardware Trojans
http://people.umass.edu/gbecker/BeckerChes13.pdf Stealthy Dopant-Level Hardware Trojans ? Georg T. Becker1 , Francesco Regazzoni2 , Christof Paar1,3 , and Wayne P. Burleson1 1University of Massachusetts Amherst, USA 2TU Delft, The Netherlands and ALaRI - University of Lugano, Switzerland 3Horst ortz Institut for IT-Security, Ruhr-Universiat Bochum, Germany Abstract. In recent years, hardware Trojans have drawn the attention of governments and industry as well as the scientific community. One of the main concerns is that integrated circuits, e.g., for military or critical infrastructure applications, could be maliciously manipulated during the manufacturing process, which often takes place abroad. However, since there have been no reported hardware Trojans in practice yet, little is known about how such a Trojan would look like, and how dicult it would be in practice to implement one. In this paper we propose an extremely stealthy approach for implementing hardware Trojans below the gate level, and we evaluate their impact on the security of the target device. Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against golden chips. We demonstrate the ectiveness of our approach by inserting Trojans into two designs | a digital post-processing derived from Intel's cryptographically secure RNG design used in the Ivy Bridge processors and a side-channel resistant SBox implementation and by exploring their detectability and their ects on security. Keywords: Hardware Trojans, malicious hardware, layout modifications, Trojan side-channel signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On Thu, Sep 12, 2013 at 08:47:16AM +1000, Dave Horsfall wrote: Another whacky idea... Given that there is One True Source of randomness to wit radioactive What makes you think that e.g. breakdown oin a reverse biased Zener diode is any less true random? Or thermal noise in a crappy CMOS circuit? In fact, http://en.wikipedia.org/wiki/Hardware_random_number_generator#Physical_phenomena_with_quantum-random_properties listens a lot of potential sources, some with a higher rate and more private than others. emission, has anyone considered playing with old smoke detectors? The ionising types are being phased out in favour of optical (at least in Australia) so there must be heaps of them lying around. I know - legislative requirements, HAZMAT etc, but it ought to make for a good thought experiment. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Perfection versus Forward Secrecy
On Thu, Sep 12, 2013 at 09:33:34AM -0700, Tony Arcieri wrote: What's really bothered me about the phrase perfect forward secrecy is it's being applied to public key algorithms we know will be broken as soon as a large quantum computer has been built (in e.g. a decade or two). I do not think that the spooks are too far away from open research in QC hardware. It does not seem likely that we'll be getting real QC any time soon, if ever. The paranoid nuclear option remains: one time pads. There is obviously a continuum for XORing with output very large state PRNGs and XORing with one time pads. It should be possible to build families of such which resist reverse-engineering the state. While juggling around several MByte or GByte keys is inconvenient, some applications are well worth it. Why e.g. SWIFT is not running on one time pads is beyond me. Meanwhile people seem to think that it's some sort of technique that will render messages unbreakable forever. signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Introducing strangers. Was: Thoughts about keys
On Wed, Sep 11, 2013 at 07:32:04PM +0200, Guido Witmond wrote: With a FOAF routing scheme with just 3 degrees of separation there are not that many strangers left. How do you meet people outside your circle of friends? You don't. The message is routed through the social network, until it reaches your destination. How do you stay anonymous? With FOAF, you have a single identity for it By running onion routers like Tor on top of that routed network. With FOAF I don't mean a specific system, but a generic small-world social network, where each member is reachable in a small number of hops. to work. I offer people many different identities. But all of them are protected, and all communication encrypted. That's what my protocol addresses. To introduce new people to one another, securely. You might not know the person but you are sure that your private message is encrypted and can only be read by that person. Of course, as it's a stranger, you don't trust them with your secrets. For example, to let people from this mailing list send encrypted mail to each other, without worrying about the keys. The protocol has already taken care of that. No fingerprint checking. No web of trust validation. If you add opportunistic encryption at a low transport layer, plus additional layers on top of you've protected the bulk of traffic. I don't just want to encrypt the bulk, I want to encrypt everything, all With multilayer transport protection, you'll get multiple layers of encryption for your typical connection. the time. It makes Tor traffic much more hidden. There is more The local CA (one for each website) signs both the server and client certificates. The client only identifies itself to the server after it has recognized the server certificate. This blocks phishing attempts to web sites (only a small TOFU risk remains). And that can be mitigated with a proper dose of Certificate Transparency. Kind regards, Guido Witmond, Please see the site for more details: http://eccentric-authentication.org/ signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Tue, Sep 10, 2013 at 09:01:49PM +0200, Guido Witmond wrote: My scheme does the opposite. It allows *total strangers* to exchange keys securely over the internet. With a FOAF routing scheme with just 3 degrees of separation there are not that many strangers left. If you add opportunistic encryption at a low transport layer, plus additional layers on top of you've protected the bulk of traffic. signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] SPDZ, a practical protocol for Multi-Party Computation
http://www.mathbulletin.com/research/Breakthrough_in_cryptography_could_result_in_more_secure_computing.asp Breakthrough in cryptography could result in more secure computing (9/10/2013) Tags: computer science, research, security, cryptography Nigel Smart, Professor of Cryptology New research to be presented at the 18th European Symposium on Research in Computer Security (ESORICS 2013) this week could result in a sea change in how to secure computations. The collaborative work between the University of Bristol and Aarhus University (Denmark) will be presented by Bristol PhD student Peter Scholl from the Department of Computer Science. The paper, entitled 'Practical covertly secure MPC for dishonest majority - or: Breaking the SPDZ limits', builds upon earlier joint work between Bristol and Aarhus and fills in the missing pieces of the jigsaw from the groups prior work that was presented at the CRYPTO conference in Santa Barbara last year. The SPDZ protocol (pronounced Speedz) is a co-development between Bristol and Aarhus and provides the fastest protocol known to implement a theoretical idea called Multi-Party Computation. The idea behind Multi-Party Computation is that it should enable two or more people to compute any function of their choosing on their secret inputs, without revealing their inputs to either party. One example is an election, voters want their vote to be counted but they do not want their vote made public. The protocol developed by the universities turns Multi-Party Computation from a theoretical tool into a practical reality. Using the SPDZ protocol the team can now compute complex functions in a secure manner, enabling possible applications in the finance, drugs and chemical industries where computation often needs to be performed on secret data. Nigel Smart, Professor of Cryptology in the University of Bristol's Department of Computer Science and leader on the project, said: We have demonstrated our protocol to various groups and organisations across the world, and everyone is impressed by how fast we can actually perform secure computations. Only a few years ago such a theoretical idea becoming reality was considered Alice in Wonderland style over ambitious hope. However, we in Bristol realised around five years ago that a number of advances in different areas would enable the pipe dream to be achieved. It is great that we have been able to demonstrate our foresight was correct. The University of Bristol is now starting to consider commercialising the protocol via a company Dyadic Security Limited, co-founded by Professor Smart and Professor Yehuda Lindell from Bar-Ilan University in Israel. Note: This story has been adapted from a news release issued by the University of Bristol signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] NIST reopens RNG public comment period
http://csrc.nist.gov/publications/PubsDrafts.html Sep. 9, 2013 SP 800-90 A Rev 1 B and C DRAFT Draft SP 800-90 Series: Random Bit Generators 800-90 A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators 800-90 B: Recommendation for the Entropy Sources Used for Random Bit Generation 800-90 C: Recommendation for Random Bit Generator (RBG) Constructions In light of recent reports, NIST is reopening the public comment period for Special Publication 800-90A and draft Special Publications 800-90B and 800-90C. NIST is interested in public review and comment to ensure that the recommendations are accurate and provide the strongest cryptographic recommendations possible. The public comments will close on November 6, 2013. Comments should be sent to rbg_comme...@nist.gov. In addition, the Computer Security Division has released a supplemental ITL Security Bulletin titled NIST Opens Draft Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, For Review and Comment (Supplemental ITL Bulletin for September 2013) to support the draft revision effort. Draft SP 800-90 A Rev. 1 (721 KB) Draft SP 800-90 B (800 KB) Draft SP 800-90 C (1.1 MB) signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] very little is missing for working BTNS in Openswan
Just got word from an Openswan developer: To my knowledge, we never finished implementing the BTNS mode. It wouldn't be hard to do --- it's mostly just conditionally commenting out code. There's obviously a large potential deployment base for BTNS for home users, just think of Openswan/OpenWRT. signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] IETF: Security and Pervasive Monitoring
http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ Security and Pervasive Monitoring The Internet community and the IETF care deeply about how much we can trust commonly used Internet services and the protocols that these services use. So the reports about large-scale monitoring of Internet traffic and users disturbs us greatly. We knew of interception of targeted individuals and other monitoring activities, but the scale of recently reported monitoring is surprising. Such scale was not envisaged during the design of many Internet protocols, but we are considering the consequence of these kinds of attacks. Of course, it is hard to know for sure from current reports what attack techniques may be in use. As such, it is not so easy to comment on the specifics from an IETF perspective. Still, the IETF has some long standing general principles that we can talk about, and we can also talk about some of the actions we are taking. In 1996, RFC 1984 articulated the view that encryption is an important tool to protect privacy of communications, and that as such it should be encouraged and available to all. In 2002, we decided that IETF standard protocols must include appropriate strong security mechanisms, and established this doctrine as a best current practice, documented in RFC 3365. Earlier, in 2000 the IETF decided not to consider requirements for wiretapping when creating and maintaining IETF standards, for reasons stated in RFC 2804. Note that IETF participants exist with positions at all points of the privacy/surveillance continuum, as seen in the discussions that lead to RFC 2804. As privacy has become increasingly important, the Internet Architecture Board (IAB) developed guidance for handling privacy considerations in protocol specifications, and documented that in RFC 6973. And there are ongoing developments in security and privacy happening within the IETF all the time, for example work has just started on version 1.3 of the Transport Layer Security (TLS, RFC 5246) protocol which aims to provide better confidentiality during the early phases of the cryptographic handshake that underlies much secure Internet traffic. Recent days have also seen an extended and welcome discussion triggered by calls for the IETF to build better protections against wide-spread monitoring. As that discussion makes clear, IETF participants want to build secure and deployable systems for all Internet users. Indeed, addressing security and new vulnerabilities has been a topic in the IETF for as long as the organisation has existed. Technology alone is, however, not the only factor. Operational practices, laws, and other similar factors also matter. First of all, existing IETF security technologies, if used more widely, can definitely help. But technical issues outside the IETF’s control, for example endpoint security, or the properties of specific products or implementations also affect the end result in major ways. So at the end of the day, no amount of communication security helps you if you do not trust the party you are communicating with or the devices you are using. Nonetheless, we’re confident the IETF can and will do more to make our protocols work more securely and offer better privacy features that can be used by implementations of all kinds. So with the understanding of limitations of technology-only solutions, the IETF is continuing its mission to improve security in the Internet. The recent revelations provide additional motivation for doing this, as well as highlighting the need to consider new threat models. We should seize this opportunity to take a hard look at what we can do better. Again, it is important to understand the limitations of technology alone. But here are some examples of things that are already ongoing: We’re having a discussion as part of the development of HTTP/2.0 as to how to make more and better use of TLS, for example to perhaps enable clients to require the use of security and not just have to react to the HTTP or HTTPS URLs chosen by servers. We’re having discussions as to how to handle the potentially new threat model demonstrated by the recent revelations so that future protocol designs can take into account potential pervasive monitoring as a known threat model. We’re considering ways in which better use can be made of existing protocol features, for example, better guidance as to how to deploy TLS with Perfect Forward Secrecy, which makes applications running over TLS more robust if server private keys later leak out. We’re constantly updating specifications to deprecate older, weaker cryptographic algorithms and allocate code points for currently strong algorithm choices so those can be used with Internet protocols. And we are confident that discussions on this topic will motivate IETF participants to do more work on these and further related topics. But don’t think about all this just in terms of the recent revelations. The security and
[Cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
Forwarded without permission, hence anonymized: Hey, I had a look at SEC2 and the TLS/SSH RFCs. SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG! TLS specifies you can use those two curves as well... Surely that's not coincidence.. signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Scott Aaaronson: NSA: Possibly breaking US laws, but still bound by laws of computational complexity
http://www.scottaaronson.com/blog/?p=1517 NSA: Possibly breaking US laws, but still bound by laws of computational complexity Last week, I got an email from a journalist with the following inquiry. The recent Snowden revelations, which made public for the first time the US government’s “black budget,” contained the following enigmatic line from the Director of National Intelligence: “We are investing in groundbreaking cryptanalytic capabilities to defeat adversarial cryptography and exploit internet traffic.” So, the journalist wanted to know, what could these “groundbreaking” capabilities be? And in particular, was it possible that the NSA was buying quantum computers from D-Wave, and using them to run Shor’s algorithm to break the RSA cryptosystem? I replied that, yes, that’s “possible,” but only in the same sense that it’s “possible” that the NSA is using the Easter Bunny for the same purpose. (For one thing, D-Wave themselves have said repeatedly that they have no interest in Shor’s algorithm or factoring. Admittedly, I guess that’s what D-Wave would say, were they making deals with NSA on the sly! But it’s also what the Easter Bunny would say.) More generally, I said that if the open scientific world’s understanding is anywhere close to correct, then quantum computing might someday become a practical threat to cryptographic security, but it isn’t one yet. That, of course, raised the extremely interesting question of what “groundbreaking capabilities” the Director of National Intelligence was referring to. I said my personal guess was that, with ~99% probability, he meant various implementation vulnerabilities and side-channel attacks—the sort of thing that we know has compromised deployed cryptosystems many times in the past, but where it’s very easy to believe that the NSA is ahead of the open world. With ~1% probability, I guessed, the NSA made some sort of big improvement in classical algorithms for factoring, discrete log, or other number-theoretic problems. (I would’ve guessed even less than 1% probability for the latter, before the recent breakthrough by Joux solving discrete log in fields of small characteristic in quasipolynomial time.) Then, on Thursday, a big New York Times article appeared, based on 50,000 or so documents that Snowden leaked to the Guardian and that still aren’t public. (See also an important Guardian piece by security expert Bruce Schneier, and accompanying QA.) While a lot remains vague, there might be more public information right now about current NSA cryptanalytic capabilities than there’s ever been. So, how did my uninformed, armchair guesses fare? It’s only halfway into the NYT article that we start getting some hints: The files show that the agency is still stymied by some encryption, as Mr. Snowden suggested in a question-and-answer session on The Guardian’s Web site in June. “Properly implemented strong crypto systems are one of the few things that you can rely on,” he said, though cautioning that the N.S.A. often bypasses the encryption altogether by targeting the computers at one end or the other and grabbing text before it is encrypted or after it is decrypted… Because strong encryption can be so effective, classified N.S.A. documents make clear, the agency’s success depends on working with Internet companies — by getting their voluntary collaboration, forcing their cooperation with court orders or surreptitiously stealing their encryption keys or altering their software or hardware… Simultaneously, the N.S.A. has been deliberately weakening the international encryption standards adopted by developers. One goal in the agency’s 2013 budget request was to “influence policies, standards and specifications for commercial public key technologies,” the most common encryption method. Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” So, in pointing to implementation vulnerabilities as the most likely possibility for an NSA “breakthrough,” I might have actually erred a bit too far on the side of technological interestingness. It seems that a large part of what the NSA has been doing has simply been strong-arming Internet companies and standards bodies into giving it backdoors. To put it bluntly: sure, if it wants to, the NSA can probably read your email. But that isn’t mathematical cryptography’s fault—any more than it would be mathematical crypto’s fault if goons broke into your house and carted away your laptop. On the contrary,
Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG
- Forwarded message from James A. Donald jam...@echeque.com - Date: Sun, 08 Sep 2013 08:34:53 +1000 From: James A. Donald jam...@echeque.com To: cryptogra...@randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: jam...@echeque.com On 2013-09-08 3:48 AM, David Johnston wrote: Claiming the NSA colluded with intel to backdoor RdRand is also to accuse me personally of having colluded with the NSA in producing a subverted design. I did not. Well, since you personally did this, would you care to explain the very strange design decision to whiten the numbers on chip, and not provide direct access to the raw unwhitened output. A decision that even assuming the utmost virtue on the part of the designers, leaves open the possibility of malfunctions going undetected. That is a question a great many people have asked, and we have not received any answers. Access to the raw output would have made it possible to determine that the random numbers were in fact generated by the physical process described, since it is hard and would cost a lot of silicon to simulate the various subtle offwhite characteristics of a well described actual physical process. ___ cryptography mailing list cryptogra...@randombit.net http://lists.randombit.net/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 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [tor-talk] NIST approved crypto in Tor?
- Forwarded message from Gregory Maxwell gmaxw...@gmail.com - Date: Sun, 8 Sep 2013 06:44:57 -0700 From: Gregory Maxwell gmaxw...@gmail.com To: This mailing list is for all discussion about theory, design, and development of Onion Routing. tor-t...@lists.torproject.org Subject: Re: [tor-talk] NIST approved crypto in Tor? Reply-To: tor-t...@lists.torproject.org On Sat, Sep 7, 2013 at 8:09 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sat, Sep 7, 2013 at 4:08 PM, anonymous coward anonymous.cow...@posteo.de wrote: Bruce Schneier recommends *not* to use ECC. It is safe to assume he knows what he says. I believe Schneier was being careless there. The ECC parameter sets commonly used on the internet (the NIST P-xxxr ones) were chosen using a published deterministically randomized procedure. I think the notion that these parameters could have been maliciously selected is a remarkable claim which demands remarkable evidence. Okay, I need to eat my words here. I went to review the deterministic procedure because I wanted to see if I could repoduce the SECP256k1 curve we use in Bitcoin. They don't give a procedure for the Koblitz curves, but they have far less design freedom than the non-koblitz so I thought perhaps I'd stumble into it with the most obvious procedure. The deterministic procedure basically computes SHA1 on some seed and uses it to assign the parameters then checks the curve order, etc.. wash rinse repeat. Then I looked at the random seed values for the P-xxxr curves. For example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90. _No_ justification is given for that value. The stated purpose of the veritably random procedure ensures that the parameters cannot be predetermined. The parameters are therefore extremely unlikely to be susceptible to future special-purpose attacks, and no trapdoors can have been placed in the parameters during their generation. Considering the stated purpose I would have expected the seed to be some small value like ... 6F and for all smaller values to fail the test. Anything else would have suggested that they tested a large number of values, and thus the parameters could embody any undisclosed mathematical characteristic whos rareness is only bounded by how many times they could run sha1 and test. I now personally consider this to be smoking evidence that the parameters are cooked. Maybe they were only cooked in ways that make them stronger? Maybe SECG also makes a somewhat curious remark: The elliptic curve domain parameters over (primes) supplied at each security level typically consist of examples of two different types of parameters — one type being parameters associated with a Koblitz curve and the other type being parameters chosen verifiably at random — although only verifiably random parameters are supplied at export strength and at extremely high strength. The fact that only verifiably random are given for export strength would seem to make more sense if you cynically read verifiably random as backdoored to all heck. (though it could be more innocently explained that the performance improvements of Koblitz wasn't so important there, and/or they considered those curves weak enough to not bother with the extra effort required to produce the Koblitz curves). -- tor-talk mailing list - tor-t...@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk - 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 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Sat, Sep 07, 2013 at 07:42:33PM -1000, Tim Newsham wrote: Jumping in to this a little late, but: Q: Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions? A: (Schneier) Yes, I believe so. perhaps, but they would risk being noticed. Some people check file hashes when downloading code. FreeBSD's port system even does it for you and I'm sure other package systems do, too. If this was going on en masse, There is a specific unit within NSA that attempts to obtain keys not in the key cache. Obviously, package-signing secrets are extremely valuable, since they're likely to work for hardened (or so they think) targets. For convenience reasons the signing secrets are typically not secured. If something is online you don't even need physical access to obtain it. The workaround for this is to build packages from source, especially if there's deterministic build available so that you can check whether the published binary for public consumption is kosher, and verify signatures with information obtained out of band. Checking key fingeprints on dead tree given in person is inconvenient, and does not give you complete trust, but it is much better than just blindly install something from online depositories. it would get picked up pretty quickly... If targeted, on the other hand, it would work well enough... signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Opening Discussion: Speculation on BULLRUN
Forwarded with permission. So there *is* a BTNS implementation, after all. Albeit only for OpenBSD -- but this means FreeBSD is next, and Linux to follow. - Forwarded message from Andreas Davour ko...@yahoo.com - Date: Sun, 8 Sep 2013 09:10:44 -0700 (PDT) From: Andreas Davour ko...@yahoo.com To: Eugen Leitl eu...@leitl.org Subject: [Cryptography] Opening Discussion: Speculation on BULLRUN X-Mailer: YahooMailWebService/0.8.156.576 Reply-To: Andreas Davour ko...@yahoo.com Apropos IPsec, I've tried searching for any BTNS (opportunistic encryption mode for IPsec) implementations, and even the authors of the RFC are not aware of any. Obviously, having a working OE BTNS implementation in Linux/*BSD would be a very valuable thing, as an added, transparent protection layer against passive attacks. There are many IPsec old hands here, it is probably just a few man-days worth of work. It should be even possible to raise some funding for such a project. Any takers? Hi. I saw this message in the archive, and have not figured out how to reply to that one. But I felt this knowledge needed to be spread. Maybe you can post it to the list? My friend MC have in fact implemented BTNS! Check this out: http://hack.org/mc/projects/btns/ I think I can speak for him and say that he would love to have that implementation be known to the others on the list, and would love others to add to his work, so we can get real network security without those spooks spoiling things. /andreas -- My son has spoken the truth, and he has sacrificed more than either the president of the United States or Peter King have ever in their political careers or their American lives. So how they choose to characterize him really doesn't carry that much weight with me. -- Edward Snowden's Father - 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 signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, Sep 06, 2013 at 09:19:07PM -0400, Derrell Piper wrote: ...and to add to all that, how about the fact that IPsec was dropped as a 'must implement' from IPv6 sometime after 2002? Apropos IPsec, I've tried searching for any BTNS (opportunistic encryption mode for IPsec) implementations, and even the authors of the RFC are not aware of any. Obviously, having a working OE BTNS implementation in Linux/*BSD would be a very valuable thing, as an added, transparent protection layer against passive attacks. There are many IPsec old hands here, it is probably just a few man-days worth of work. It should be even possible to raise some funding for such a project. Any takers? signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [liberationtech] Random number generation being influenced - rumors
- Forwarded message from Andy Isaacson a...@hexapodia.org - Date: Fri, 6 Sep 2013 22:24:00 -0700 From: Andy Isaacson a...@hexapodia.org To: liberationtech liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Random number generation being influenced - rumors User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech liberationt...@lists.stanford.edu On Sat, Sep 07, 2013 at 12:51:19AM +0300, Maxim Kammerer wrote: On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson a...@hexapodia.org wrote: This is not to say that RdRand is completely unusable. Putting RdRand entropy into a software pool implementation like /dev/urandom (or preferably, a higher-assurance multipool design like Fortuna) is a cheap way to prevent a putative backdoor from compromising your system state. Nearly nothing from what you wrote is relevant to RDRAND, which is not a pure HWRNG, but implements CTR_DRBG with AES (unclear whether 128/192/256) from NIST SP 800-90A [1,2]. That's the claimed design, yes. I see no particular reason to believe that the hardware in my server implements the design. I can't even test that the AES whitening does what it is documented to do, because Intel refused to provide access to the prewhitened input. Providing accessible test points (software interfaces to the innards of the implementation, with documentation of expected behavior between the components) would be the absolute minimum to provide believable assurance of the absence of a backdoor. Better would be documents from Intel of how the chip is designed at the mask level, and a third party mill-and-microphotograph of a retail chip showing that the shipped implementation matches the design. Intel will never go for that, of course, since their chip masks are their jealously guarded IP. Since they can't provide evidence of a lack of a backdoor, any reasonably cautious user should avoid depending on Intel's implementation. -andy -- Liberationtech is a public list whose 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 compa...@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 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [tor-talk] NIST approved crypto in Tor?
targeted ECRYPT III some time. As I said on another mail, I've got a mind to move a lot of our crypto for other reasons, as well. The elephant in the room here is TLS itself. Frankly, I'm starting to think we should cut the Gordian Knot here and start a little independent protocol group of our own if the TLS working group can't get its act together and have one really good ciphersuite some time soon. The NSA likes playing around. [2][3] (found while searching) Oh and I'm not trying fear-mongering here or try to conspire whenever or not the NSA has subverted cryptographic functions (in one way or another). Yeah, I know how it is. I'm seeing conspiracies under every protocol and in every patch these days. Gotta stay focused, write the best protocols and designs and software I can, and maintain. (And with that in mind I should really start on my weekend soon.) peace, -- Nick -- tor-talk mailing list - tor-t...@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk - 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 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG
- Forwarded message from Thor Lancelot Simon t...@panix.com - Date: Sat, 7 Sep 2013 15:36:33 -0400 From: Thor Lancelot Simon t...@panix.com To: Eugen Leitl eu...@leitl.org Cc: cryptogra...@randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mutt/1.5.20 (2009-06-14) On Sat, Sep 07, 2013 at 09:05:33PM +0200, Eugen Leitl wrote: This pretty much rules out CPU-integral RNGs. It has to be a third-party add-on (USB or PCIe), and it has to be open hardware. I think you take this more than a little too far. I see CPU-integral RNGs as very valuable source to be mixed with other sources in a software pool of entropy. Why should we reject them, unless we think the mixing functions themselves are useless? The lesson here seems to me to be that we should be far more assiduous in seeking out additional sources of entropy and in always ensuring software RNGs mix input from multiple such sources into all output. We should abandon sacred cows like the notion of information-theoretic randomness (that we don't actually know how to measure, but in pursuit of which we hamstring our software RNGs by arranging that they refuse to produce any output unless, by some questionable criterion, there is enough of it) and pursue engineering goals we can actually achieve, like mixing enough other-source input, of whatever quality, with the output of fast generators we can no longer trust that the adversary must actually attack the mixing function, rather than iteratively guessing the few state bits he does not already know. Secondarily -- and sadly! -- we must now be very suspicious of devices that integrate random number generation and encryption. Can we even trust raw hardware RNG output for the generation of IVs? I would argue not, because the same device's AES engine could be leaking key bits into our explicit IVs, etc, and we couldn't ever know. Devices that offload packet processing in its entirety (SSL accellerators, IPsec accellerators, etc.) have even more opportunity to do this sort of thing. Hardware crypto offload may still be very useful -- random number generation perhaps in particular -- but we will have to apply it with extreme care, and with a deliberate eye towards eliminating covert channels put in place by people at least as smart as we are, and with far more time and experience thinking about the problem from the offensive point of view. Finally, we have to accept that the game might just be over, period. So you use a pure software RNG, mixing in RdRand output or not as you may prefer. How hard do you think it is to identify the datastructures used by that RNG if you can execute code on a coprocessor with access to host RAM? Almost every modern server has such a coprocessor built in (its management processor) and you won't find the source code to its firmware floating around. Intel even puts this functionality directly on its CPUs (Intel AMT). Rather than beating up on the guy who put a lovely RNG instruction into every processor we're likely to use any time soon, it seems to me we ought to be beating up on ourselves for ignoring far simpler and more obvious risks like this one for well over a decade. Seriously, show of hands, who here has ever really put his or her foot down and insisted that a product they were purchasing _omit_ such functionality? Not chosen not to pay for it, refused to buy server X or mainboard Y simply on the basis that management processor functionality was onboard? Now, compare to the number of people complaining about backdoored RNGs here and elsewhere on the Internet. Go figure. To me the interesting question, but one to which I don't expect to ever know the answer, is whether the adversary -- having, we can assume, identified high value devices to systematically compromise, and lower value devices to defer for later or simply ignore entirely -- went at those devices sniper-style, or shotgun-style. Were a few key opportunities for tampering identified, and one or two attempted against each targeted device? Or were a wide variety of avenues explored, and every single one that seemed relevant attempted everywhere, or at least against certain particularly high value devices? If we knew that, in a way we might know, when we did finally see concrete evidence of a particular kind of tampering, how long to keep looking for more. But we aren't going to know that, no matter how much we might want to. Attacks on crypto hardware, attacks on management processors, attacks on supervisory or trusted execution modes seldom exercised in normal system operation, attacks on flash modules holding boot code, so that under the right circumstances they replace page P with evil page P', attacks on elements of IC vendors' standard cell libraries (DMA engines would seem promising); assume the adversaries are smart, and good at their jobs, and the sky would seem to be the limit. The sky will fall, of course, when various nation
Re: [Cryptography] Washington Post: Google racing to encrypt links between data centers
On Sat, Sep 07, 2013 at 01:53:13PM -0700, Tony Arcieri wrote: On Fri, Sep 6, 2013 at 4:53 PM, Marcus D. Leech mle...@ripnet.com wrote: One wonders why they weren't already using link encryption systems? Probably line rate and the cost of encrypting every single fiber link. There are few vendors who sell line rate encryption for 10Gbps+ Nanog and denog had a discussion about this, and in general nobody believes the products you can buy, especially the export version, have no backdoor. Doing it in software is only feasible at network edge, not core. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Washington Post: Google racing to encrypt links between data centers
On Sat, Sep 07, 2013 at 04:41:04PM -0400, Richard Outerbridge wrote: Surely not Canada? After all, we're one of the five eyes! ;) Six. Sweden (FRA) is part of it. http://www.heise.de/tp/blogs/8/154917 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, Sep 05, 2013 at 04:11:57PM -0400, Phillip Hallam-Baker wrote: If a person at Snowden's level in the NSA had any access to information Snowden didn't have clearance for that information. He's being described as 'brilliant' and purportedly was able to access documents far beyond his level by impersonating (using stolen/falsified secrets) higher level officials. Culling admins and adding the two-eyes rule will cripple the TLAs more than it will accomplish anything. We're still missing the information which cyphers are now legacy, and which are still considered useful. I keep seeing PFS being touted, but there is no evidence yet we can trust PFS to be yet unbroken though it appears plausible. Others are suggesting that public key encryption methods are suspect, while symmetric encryption has a better story. I'm personally becoming quite interested in a reliable way to produce secure one-time pads, using physical entropy sources which have been validated. It would be interesting to physically/securely exchanging large one-time pads in one's social network, and reaching farther recipients in a Retroshare-like (turtle router) model. It might be useful to combine one-time pads with symmetric encryption, automatically rekeying every large block of data for high-volume transfers (e.g. mesh routers) to stretch a one-time pad without completely losing its properties. The question is how large a block can be before it leaks enough information about the key. that indicated the existence of any program which involved the successful cryptanalysis of any cipher regarded as 'strong' by this community then the Director of National Intelligence, the Director of the NSA and everyone involved in those decisions should be fired immediately and lose their pensions. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Bruce Schneier has gotten seriously spooked
On Fri, Sep 06, 2013 at 04:25:12PM -0400, Jerry Leichter wrote: A response he wrote as part of a discussion at http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html: Q: Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions? A: (Schneier) Yes, I believe so. This is why I've been verifying Tor downloads using out of band fingerprints of signing key. Just because active attacks are more expensive than passive attacks and are fundamentally detectable, don't assume they're not being used in highly targeted cases. If you have ever been under telco surveillance, that's enough effort already spent to warrant slipping you some custom malware with no added bill of materials. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On Thu, Aug 29, 2013 at 01:30:35PM -0400, Perry E. Metzger wrote: On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com wrote: One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? So, as has been discussed, I envision people having small cheap machines at home that act as their cloud, and the system prompting them to pick a friend to share encrypted backups with. This is precisely the use case for Freedombox running Tahoe LAFS. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Mon, Aug 26, 2013 at 02:44:32PM -0400, Perry E. Metzger wrote: My main issue with this proposal is that somebody identifiable is going to manufacture these boxes. Maybe several somebodies, but IMO, that's an identifiable central point of control/failure. Recently there's a trend for at least somewhat open hardware (Raspberry Pi, other ARM systems, Parallella Epiphany) some of which contain enough FPGA real estate (sure, we know there are FPGA backdoors, but) so that you could boot up an open core soft CPU, and even bootstrap your own toolchain from scratch. One can use a commercial PC if one wants to install on one's own, or any one of many manufacturers of small boxes. It is certainly the case In principle an FPGA die is regular, and hence more easily inspectable, but even SoCs can be sampled by reverse-engineering them from the metal layers. that the hardware layer can be attacked, all is lost. On the other hand, if we presume supply chain attacks, all is lost anyway -- once you control the computer, the protocols it is running don't matter. Even keyboards can be suborned -- see Gaurav Shah's work on that, for example. We need open, fully inspectable systems. If proving code, or at least, auto-generating code from state machines catches on in open source the number of exploitable vulnerabilities can be greatly diminished. I would prefer not to try to solve that problem right now -- it is too broad and too general. If others can solve it, that's of course a great thing. :) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] crypto breakage in SALT
Comments? https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] [cryptography] OT: RSA's Pwnie Award
- Forwarded message from Jeffrey Walton noloa...@gmail.com - From: Jeffrey Walton noloa...@gmail.com Date: Mon, 8 Aug 2011 20:00:56 -0400 To: Randombit List cryptogra...@randombit.net Subject: [cryptography] OT: RSA's Pwnie Award Reply-To: noloa...@gmail.com, Crypto discussion list cryptogra...@randombit.net In case anyone is interested, RSA won a Pwnie for lamest vendor response for its RSA SecurID token compromise: http://pwnies.com/winners/ ___ cryptography mailing list cryptogra...@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography - 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 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
FY;) Stick Figure Guide to AES
Not new, but some probably have missed it. http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
[tt] Random numbers created out of nothing
Right from the snake-oil-security-dept. - Forwarded message from Arlind Boshnjaku arlindboshnj...@yahoo.com - From: Arlind Boshnjaku arlindboshnj...@yahoo.com Date: Thu, 30 Sep 2010 14:48:44 +0200 To: transhumanist news t...@postbiota.org Subject: [tt] Random numbers created out of nothing http://www.newscientist.com/article/dn19520-random-numbers-created-out-of-nothing.html Random numbers created out of nothing 12:36 30 September 2010 by Kate McAlpine It's something from nothing. A random number generator that harnesses the quantum fluctuations in empty space could soon sit inside your computer. A device that creates truly random numbers is vital for a number of applications, including cryptography. Algorithms can generate numbers that pass statistical tests for randomness, but they're useless for secure cryptography if the algorithm falls into the wrong hands. Other methods using entangled ions to generate random numbers are more reliable, but tend to be slower and more expensive. Now Christian Gabriel's team at the Max Planck Institute for the Science of Light in Erlangen, Germany, has built a prototype that draws on a vacuum's random quantum fluctuations. These impart random noise to laser beams in the device, which converts it into numbers. It's an easy method, and it's good value, says Gabriel. The team sent a laser into a beam splitter, sheltered from external light sources. Without influence from the vacuum, the two emerging beams would have been identical. However, the lowest energy state of the electromagnetic field carries just enough energy to interact with the laser as it passes through the beam splitter. The beams carry this quantum noise, says Gabriel. The exiting beams were captured in two detectors which turned the light into electronic signals, and the signals were subtracted from one another, leaving only the noise from the vacuum and electronics. The team used a mathematical function to tease out the truly random signal of the vacuum. Because they could calculate the total disorder in the system and the portion which comes from the vacuum, they were able to reduce the set of numbers so that the electronic contribution was eliminated and only a fully random string remained. Though reduced, the stream of bits comes at speedy 6.5 million per second. This is already in line with the speed of commercially available quantum random number generators, say the researchers, but they hope to achieve rates more than 30 times higher. Collaborator Christoph Marquardt says the generator's optimised speed will be faster than anything you could buy or that is available in other comparable systems nowadays. The lab set-up costs about €1000, and the researchers estimate that the cost could fall to about €100. As the device functions at room temperature and could be made to fit in the palm of your hand, it may one day be integrated into a desktop computer. Antonio Acín of the Institute for Photonic Sciences in Barcelona, Spain, points out that although the quantum noise of the vacuum is tamper-proof, most users won't be able to verify the workings of their random number generators – meaning they'll find it impossible to tell whether they are receiving a unique random stream from the generator or a pre-programmed, statistically random set from elsewhere. Journal source: Nature Photonics, DOI: 10.1038/nphoton.2010.197 ___ tt mailing list t...@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://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Former Stasi Cryptographers Now Develop Technology for NATO
http://www.spiegel.de/international/germany/0,1518,druck-719726,00.html 09/27/2010 11:23 AM Recruited by West Germany Former Stasi Cryptographers Now Develop Technology for NATO By Marcel Rosenbach and Holger Stark After the fall of the Berlin Wall, the West Germans were desperate to prevent the Stasi's top codebreakers from falling into the wrong hands. from falling into the wrong hands and set up a company to hire the East German cryptographers. Now the former Stasi scientists develop technology used by Angela Merkel and NATO. Every morning, while going to his office in Berlin's Adlershof district, Ralph W. passes a reminder of his own past, a small museum that occupies a room on the ground floor of the building. The museum could easily double as a command center run by the class enemy in an old James Bond film. A display of coding devices from various decades includes the T-310, a green metal machine roughly the size of a huge refrigerator, which East German officials used to encode their telex messages. The device was the pride of the Stasi, the feared East German secret police, which was W.'s former employer. Today he works as a cryptologist with Rohde Schwarz SIT GmbH (SIT), a subsidiary of Rohde Schwarz, a Munich-based company specializing in testing equipment, broadcasting and secure communications. W. and his colleagues encode sensitive information to ensure that it can only be read or heard by authorized individuals. Their most important customers are NATO and the German government. Rohde Schwarz is something of an unofficial supplier of choice to the German government. Among other things, the company develops bugproof mobile phones for official use. Since 2004, its Berlin-based subsidiary SIT, which specializes in encryption solutions, has been classified as a security partner to the German Interior Ministry, which recently ordered a few thousand encoding devices for mobile phones, at about €1,250 ($1,675) apiece. Even German Chancellor Angela Merkel has used phones equipped with SIT's encryption technology. In other words, the Stasi's former cryptographers are now Merkel's cryptographers. Secret Operation The transfer of Ralph W. and other cryptologists from the East German Ministry for State Security, as the Stasi was officially known, to West Germany was handled both seamlessly and discreetly. West German officials were determined to make sure that no one would find out about the integration of East Germany's top cryptologists into the west. The operation was so secret, in fact, that it has remained unknown to this day. Only a handful of officials were involved in the operation, which was planned at the West German Interior Ministry in Bonn. In January 1991, Rohde Schwarz SIT GmbH was founded. The company was established primarily to provide employment for particularly talented Stasi cryptologists that the Bonn government wanted to keep in key positions. Ralph W. is one of those specialists. W., who holds a doctorate in mathematics, signed a declaration of commitment to the Stasi on Sept. 1, 1982. By the end of his time with the Stasi, he was making 22,550 East German marks a year -- an excellent salary by East German standards. And when he was promoted to the rank of captain in June 1987, his superior characterized W. as one of the most capable comrades in the collective. While with the Stasi, W. worked in Department XI, which also boasted the name Central Cryptology Agency (ZCO). Looking for the Top Performers The story begins during the heady days of the East German revolution in 1990. Officially, the East German government, under its last communist premier, Hans Modrow, had established a government committee to dissolve the Ministry for State Security which reported to the new East German interior minister, Peter-Michael Diestel. In reality, the West German government was already playing a key role in particularly sensitive matters. Then-West German Interior Minister Wolfgang Schäuble (who is the current German finance minister) had instructed two senior Interior Ministry officials, Hans Neusel and Eckart Werthebach, to take care of the most politically sensitive remnants of the 40-year intelligence war between the two Germanys. The government of then-Chancellor Helmut Kohl was interested in more than just the politically explosive material contained in some of the Stasi's files. It also had its eye on the top performers in the former East German spy agency. The cryptologists were of particular interest to the Kohl government, which recognized that experts capable of developing good codes would also be adept at breaking them. The Stasi cryptologists were proven experts in both fields. Documents from the Stasi records department indicate that the one of the Stasi cryptologists' achievements was to break Vericrypt and Cryptophon standards that had been used until the 1980s. This meant that they were capable of decoding encrypted radio transmissions by the two main
Re: GSM eavesdropping
On Mon, Aug 02, 2010 at 03:46:24PM -0500, Nicolas Williams wrote: The default mode for any internet communication is encrypted That's... extreme. There are many things that will not be encrypted, Extreme? I don't see why my ISP should be able to inspect and monetize my data stream. starting with the DNS itself, and also most public contents (because Encryption is cheap enough (especially if you cache keys from previous sessions). Why not encrypt everything? their purveyors won't want to pay for the crypto; sad but true). -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Intel to also add RNG
http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. By Tom Simonite It might sound like the last thing you need in a precise piece of hardware, but engineers at Intel are pretty pleased to have found a way to build a circuit capable of random behavior into computer processors. Generating randomness--an unpredictable stream of numbers--is much harder than you might think. It's also crucial to creating the secure cryptographic keys needed to keep data safe. Building a random-number-generating ability into the Central Processing Unit (CPU) at a computer's heart is ideal, says Ram Krishnamurthy, an engineer at Intel's Microprocessor Technology Labs, in Hillsboro, OR. It should speed up any process that requires the generation of an encrypted key, for example securing sensitive data on a hard drive, and make it harder for an attacker to compromise that encryption. Building circuitry capable of producing random numbers into a CPU has proved difficult. Today random numbers are either generated in software, or in the chip set outside the microprocessor, explains Krishnamurthy, one of the Intel researchers on the project. Neither solution is ideal. Software produces only pseudo random numbers (given enough computing power, patterns can be found within that randomness). If the random numbers are not truly random, for example, if they are biased in some way, then an adversary has a better chance of guessing/determining the value, explains mathematician Elaine Barker, at the National Institute for Standards and Technology (NIST), in Gaithersburg, MD. In the case of cryptographic keys, if the adversary can determine the key without an excessive amount of computing power, then he can breach the confidentiality of that data. Installing a source of random numbers outside of a computer's core microprocessor provides another avenue of opportunity to attackers, says Krishnamurthy. You are vulnerable to side channel attacks, he explains, there are many ways by which the key can be directly read off of the bus, or attacks that look at how the power supply varies and look for signatures that indicate what the key looks like. Building the circuit into the main processor shuts off that possibility, says Krishnamurthy, although the barrier to doing that has been practicality. The best-established methods of generating random numbers use analog circuits that rely on thermal noise as a source of randomness, and those circuits are not easily fabricated with the techniques used to make the digital circuits of a microprocessor. Nor are they easily scaled down to the size of components on modern chips. Intel's new circuit has a fully-digital design, making it possible to incorporate it into the microprocessor die. At the heart of the new design is a cross-coupled inverter, a combination of two basic circuit components that is essentially a memory capable of storing a single 1 or 0. This memory, though, is designed to be unreliable; it can be tipped between its two possible outputs by the influence of thermal noise from the surrounding silicon. Since that thermal noise is random, the circuit's output should be, too. In reality, though, the influence of fluctuations in voltage and temperature normal inside a chip could bias that output to be less-than-random, requiring Krishnamurthy and colleagues to develop additional measures to counteract their influence. Benchmarks for true randomness maintained by NIST were used to confirm they had been successful. We exceeded all of those thresholds, he says. The speed at which the new circuit cranks out numbers--2.4 billion a second or 2.4Gbps--is also around 200 times faster than anything before, Krishnamurthy adds. Having built the circuit with a smallest feature size of 45 nanometers, he and colleagues are now working toward proving it can be built using 32 and 22 nanometer manufacturing processes with minimal design tweaks. Passing existing benchmarks of randomness, though, does not mean the new circuit is perfect. Current techniques do not make it possible to be certain that any source of randomness is truly random, says Barker. We just don't know enough to design tests that catch all the problems, and tests may not always catch the point at which a noise source starts to go bad if the change is subtle. Research by groups like that at NIST will generate smarter tests that help industry engineers raise the bar further. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Quantum Key Distribution: the bad idea that won't die...
On Thu, Apr 22, 2010 at 09:46:18AM -0400, John Lowry wrote: My own speculation is that the security community and its interests are perhaps a bit broader than than some members wish it were. If you want to see some interesting physics that represents unexpected results relevant to communications (and comes from entangled QKD research) then take a look at: http://pra.aps.org/abstract/PRA/v81/i2/e023835 This is interesting. However, even if you can use LoS up to LEO, the question is of what the added value of a (supposedly, trend in QC state cloning attacks is there) tamperproof exchange is over traditional cryptography. I agree with Perry that it solves a non-problem. There is a human-readable summary at: http://focus.aps.org/story/v25/st7 -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [vserver] Bought an entropykey - very happy
From: coderman coder...@gmail.com Date: Wed, 24 Mar 2010 10:50:33 -0700 To: Morlock Elloi morlockel...@yahoo.com Cc: cypherpu...@al-qaeda.net Subject: Re: [vserver] Bought an entropykey - very happy On Wed, Mar 24, 2010 at 8:43 AM, Morlock Elloi morlockel...@yahoo.com wrote: While avalanche noise (hoping it doesn't start to tunnel - that current must be actively controlled as each junction is different) is a good source of randomness (up to megabits / sec / junction), encrypting it just means masking possible low entropy. I'd prefer to see raw conditoned stream than encrypted one (even web content looks high-entropy to Diehard when encrypted). ... i have loved the padlock engines on via cores since they hit the market in C5XL form with a single hw generator available via XSTORE. unlike many designs this free wheeling resource can provide a torrent of entropy sufficient to sate even the most gregarious consumption. as mentioned above, you need a fast user space entropy daemon sanity checking the raw, (probably) biased stream coming from hardware but it is still good practice to digest this entropy to obscure any potential generator state/bias heading into the host entropy pool. that is to say, of the two common modes for utilizing hw entropy: a. conservatively sample from a whitened, string filtered entropy source for a low rate of high quality output (see xstore config words) b. ramp un-whitened, un-filtered source(s) to maximum rate and AES/SHA mix for high throughput, high quality output while irreversibly masking generator bias/state present in the raw source stream. the latter is more effective in practice and capable of generation rates 20Mbps with full FIPS sanity checks. the former tops out around 1Mbps or less with more transient latency spikes on read (when successive attempts to read fail to pass whiten+strfilter). note that padlock engine supports SHA and AES on die as well making these easy and fast to apply to generator output. if you are still concerned a more conservative configuration would estimate entropy density while feeding from raw input stream and add encrypted/digested product to the host entropy pool with the specified entropy density estimate adjusted downward to your requirements. (most OS'es support this) -- -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Fault-Based Attack of RSA Authentication
From: basile bas...@opensource.dyc.edu Date: Thu, 04 Mar 2010 19:20:36 -0500 To: or-t...@freehaven.net Subject: Fault-Based Attack of RSA Authentication User-Agent: Thunderbird 2.0.0.23 (X11/20090817) Reply-To: or-t...@freehaven.net Hi everyone, I thought this might be of interest to the list. Pellegrini, Bertacco and Austin at U of Michigan have found an interesting way to deduce the secret key by fluctuating a device's power supply. Its a minimal threat against servers, but against hand held devices its more practical. The openssl people say there's an easy fix by salting. Here's some referneces: http://www.theregister.co.uk/2010/03/04/severe_openssl_vulnerability/ http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf -- Anthony G. Basile, Ph.D. Chair of Information Technology D'Youville College Buffalo, NY 14201 USA (716) 829-8197 -- -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: AES-CBC + Elephant diffuser
On Thu, Oct 29, 2009 at 07:15:53AM -0700, Paul Hoffman wrote: At 2:24 PM +0100 10/29/09, Eugen Leitl wrote: We discuss why no existing cipher satisfies the requirements of this application. Uh-oh. Yeah, we all know what a light-weight and careless person Neils Ferguson is. Who would listen to him? Ah, should have spent a few seconds looking him up http://en.wikipedia.org/wiki/Niels_Ferguson http://www.macfergus.com/ -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
AES-CBC + Elephant diffuser
We discuss why no existing cipher satisfies the requirements of this application. Uh-oh. http://www.microsoft.com/downloads/details.aspx?FamilyID=131dae03-39ae-48be-a8d6-8b0034c92555DisplayLang=en AES-CBC + Elephant diffuser Brief Description A Disk Encryption Algorithm for Windows Vista The specifications of the AES-CBC + diffuser algorithm used in BitLocker Drive Encryption Overview The Bitlocker Drive Encryption feature of Windows Vista poses an interesting set of security and performance requirements on the encryption algorithm used for the disk data. We discuss why no existing cipher satisfies the requirements of this application and document our solution which consists of using AES in CBC mode with a dedicated diffuser to improve the security against manipulation attacks. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Old Trick Threatens the Newest Weapons
http://www.nytimes.com/2009/10/27/science/27trojan.html?8dpc=pagewanted=all Old Trick Threatens the Newest Weapons By JOHN MARKOFF Published: October 26, 2009 Despite a six-year effort to build trusted computer chips for military systems, the Pentagon now manufactures in secure facilities run by American companies only about 2 percent of the more than $3.5 billion of integrated circuits bought annually for use in military gear. That shortfall is viewed with concern by current and former United States military and intelligence agency executives who argue that the menace of so-called Trojan horses hidden in equipment circuitry is among the most severe threats the nation faces in the event of a war in which communications and weaponry rely on computer technology. As advanced systems like aircraft, missiles and radars have become dependent on their computing capabilities, the specter of subversion causing weapons to fail in times of crisis, or secretly corrupting crucial data, has come to haunt military planners. The problem has grown more severe as most American semiconductor manufacturing plants have moved offshore. Only one-fifth of all computer chips are now made in the United States, and just one-quarter of the chips based on the most advanced technologies are built here, I.B.M. executives say. That has led the Pentagon and the National Security Agency to expand significantly the number of American plants authorized to manufacture chips for the Pentagon s Trusted Foundry program. Despite the increases, semiconductor industry executives and Pentagon officials say, the United States lacks the ability to fulfill the capacity requirements needed to manufacture computer chips for classified systems. The department is aware that there are risks to using commercial technology in general and that there are greater risks to using globally sourced technology, said Robert Lentz, who before his retirement last month was in charge of the Trusted Foundry program as the deputy assistant defense secretary for cyber, identity and information assurance. Counterfeit computer hardware, largely manufactured in Asian factories, is viewed as a significant problem by private corporations and military planners. A recent White House review noted that there had been several unambiguous, deliberate subversions of computer hardware. These are not hypothetical threats, the report s author, Melissa Hathaway, said in an e-mail message. We have witnessed countless intrusions that have allowed criminals to steal hundreds of millions of dollars and allowed nation-states and others to steal intellectual property and sensitive military information. Ms. Hathaway declined to offer specifics. Cyberwarfare analysts argue that while most computer security efforts have until now been focused on software, tampering with hardware circuitry may ultimately be an equally dangerous threat. That is because modern computer chips routinely comprise hundreds of millions, or even billions, of transistors. The increasing complexity means that subtle modifications in manufacturing or in the design of chips will be virtually impossible to detect. Compromised hardware is, almost literally, a time bomb, because the corruption occurs well before the attack, Wesley K. Clark, a retired Army general, wrote in an article in Foreign Affairs magazine that warns of the risks the nation faces from insecure computer hardware. Maliciously tampered integrated circuits cannot be patched, General Clark wrote. They are the ultimate sleeper cell. Indeed, in cyberwarfare, the most ancient strategy is also the most modern. Internet software programs known as Trojan horses have become a tool of choice for computer criminals who sneak malicious software into computers by putting it in seemingly innocuous programs. They then pilfer information and transform Internet-connected PCs into slave machines. With hardware, the strategy is an even more subtle form of sabotage, building a chip with a hidden flaw or a means for adversaries to make it crash when wanted. Pentagon executives defend the manufacturing strategy, which is largely based on a 10-year contract with a secure I.B.M. chipmaking plant in Burlington, Vt., reported to be valued as high as $600 million, and a certification process that has been extended to 28 American chipmakers and related technology firms. The department has a comprehensive risk-management strategy that addresses a variety of risks in different ways, said Mitchell Komaroff, the director of a Pentagon program intended to develop a strategy to minimize national security risks in the face of the computer industry s globalization. Mr. Komaroff pointed to advanced chip technologies that made it possible to buy standard hardware components that could be securely programmed after they were acquired. But as military planners have come to view cyberspace as an impending battlefield, American intelligence agency experts said, all
Serpent close to AES speed thanks to SSE2
http://www.randombit.net/bitbashing/programming/serpent_in_simd.html Wed, 09 Sep 2009 Speeding up Serpent: SIMD Edition The Serpent block cipher was one of the 5 finalists in the AES competition, and is widely thought to be the most secure of them due to its conservative design. It was also considered the slowest candidate, which is one major reason it did not win the AES contest. However, it turns out that on modern machines one can use SIMD operations to implement Serpent at speeds quite close to AES. Serpent uses an interesting bitsliced design with eight 4 bit sboxes which are computed in parallel using boolean operations on registers. Rather than splitting up the 32 bit words into nibbles and passing them through table lookups, a special instruction sequence is used which performs the same operation using only instructions like AND, OR, XOR, and NOT. Typically these are done using 32 bit register operations, but it was recently suggested that SIMD operations such as those available in SSE2 or AltiVec could be used to encrypt 4 blocks in parallel. Most cipher modes, such as CBC and OFB, are iterative; after splitting the plaintext into blocks, the input to the second block depends on the previously computed ciphertexts. This data dependency means it is impossible to use a block-parallel implementation in these modes. However some other modes, including CTR, EAX, and XTS, do not exhibit this data dependency, and allow for many blocks to be encrypted in parallel. So being able to compute many encryptions in parallel is only useful for these modes. Fortunately, CTR, EAX, and XTS are very useful, unpatented, and (in the case of CTR and XTS) widely standardized modes. Recently I implemented Serpent using SSE2 intrinsics in the botan cryptography library. While not quite as fast as AES, it easily boosts Serpents performance by a factor of over 2.5 on an Intel Core2 processor. Up until now, botan has used a rather conventional block cipher interface where only a single block of data (typically 64 or 128 bits) would be encrypted at a time; processing multiple blocks required calling the function multiple times, one for each block. However this completely hides any parallelism from the block cipher implementation. So in the upcoming development release (1.9.0), botan offers two new interfaces for block ciphers: void encrypt_n(const byte in[], byte out[], u32bit blocks) const; void decrypt_n(const byte in[], byte out[], u32bit blocks) const; which will process many blocks in a single call. In addition some mode implementations (at this time, ECB and CTR) will batch their inputs into larger groups. This will not only allow for parallel encryption using SIMD techniques, it also improves instruction and data cache utilization for all ciphers. Right now, the modes will batch 8 blocks of data together; it is unclear if this is sufficient for the best performance, but in any case is easy to modify by changing a macro value in build.h. On a 2.4 GHz Intel Core2 with GNU C++ 4.3.3, I got these results: Algorithm 1.8.6 (MiB/s) 1.9.0 (MiB/s) Speedup Serpent/ECB 42.1113.5 2.7 Serpent/CTR 39.7100.8 2.5 AES-128/ECB 112.7 134.4 1.2 AES-128/CTR 99.1114.1 1.15 The AES speedups nicely demonstrate that even without any explicit SIMD operations, the improved cache utilization can make a pretty big difference. I also experimented with performing 8 Serpent block operations in parallel, by interleaving two 4-wide SIMD encryptions. This reduced the number of key variable loads, as well as offering the processor much more in the way of independent computations for hot hot superscalar action. On my Core2, this pushed Serpent's performance north of 160 MiB/s in CTR mode, which is pretty impressive considering that is right about the speed of OpenSSL's AES-128 implementation on the same platform. However this variant seems slower on anything but a Core2; tests on an Opteron showed it to be somewhat slower than 4-way SIMD, and it is highly likely that it would also be much slower on 32-bit x86 processors due to excessive register pressure. AltiVec looks to be an even more promising platform for multiblock Serpent encryption, as it includes native rotation instructions, which in SSE2 must be emulated using two shifts and an OR. It is very likely the Cell processors SIMD units could also implement Serpent in a SIMD mode. Considering the Cell SPE contains 128 SIMD registers, it might even be feasible to implement a variant suggested by Wei Dai of encrypting 128 blocks in parallel without suffering an excessive number of register spills. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [btns] IETF75
I can has contributions, please? From: Michael Richardson m...@sandelman.ottawa.on.ca Subject: Re: [btns] IETF75 To: Eugen Leitl eu...@leitl.org cc: b...@ietf.org Date: Wed, 24 Jun 2009 15:03:33 -0400 Eugen == Eugen Leitl eu...@leitl.org writes: Eugen On Wed, Jun 24, 2009 at 03:15:59PM +0200, Julien Laganier Eugen wrote: We're currently progressing connexion latching thru IESG. What remains to be done for the WG is to complete the API work item. Since those haven't been discussed much on the mailing list we felt that a meeting wouldn't be productive. Eugen How far is the proposed standard from being able to hit the Eugen road? I realize it's done when it's done but are we Eugen looking at months, years, half a decade until there's a first Eugen implementation available to beta testers? Read the document and comment. The API documents are stuck for lack of contributions. -- ] Y'avait une poule de jammé dans l'muffler!| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ]h(Just another Debian GNU/Linux using, kernel hacking,ruby guy); [ -- -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Tellitec Tellinet Sat Spy manual leaked
http://wikileaks.org/wiki/Tellitec_Tellinet_Sat_Spy_manual%2C_6_Mar_2006 Tellitec Tellinet Sat Spy manual, 6 Mar 2006 May 24, 2009 Summary Tellinet is an accelerator for satellite communications made by Tellitec GmbH of Berlin. It supports encrypted TCP (ETCP), but as this confidential manual shows, it also supports covert remote interception of communications data. DOWNLOAD/VIEW FULL FILE FROM fast site, current site, Sweden, US, Latvia, Slovakia, UK, Finland, Netherlands, Poland, Tonga, Europe, SSL, Tor Context Germany Primary language English File size in bytes 2170498 File type information PDF document, version 1.3 Cryptographic identity SHA256 c1ac645e16624815e9ef75dd3d959b1b681e82b68a5261a4cea3c7a6f251370b - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
[tahoe-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)
attacks? Sure -- a Merkle Tree has collision-resistance if the underlying hash has collision-resistance, and a Merkle Tree has second-preimage- resistance if the underlying hash has second-preimage resistance. So if the underlying has doesn't have collision-resistance but does have second-preimage-resistance (as we currently suspect that SHA-1 might), then your Merkle Tree would stil have second-preimage- resistance. Also a Merkle Tree might be stronger than its underlying hash function in a few ways, even if the underlying hash is somewhat weak. d. For an existing grid how feasible is an upgrade to a new hash format which preserves all data? It is certainly possible to preserve all the data. The obvious way is to download your files and re-upload them in the new format. I suspect that will probably end up being the best way, too. I would like to emphasize that it is extremely unlikely that anyone will need to do this due to a weakness in the hashing algorithm in Tahoe in a hurry. The people who are suffering from the collisions in MD5 and SHA-1 are suffering, not because MD5 or SHA-1 were suddenly revealed to be insecure, but because they ignored the warning messages from cryptographers for many years. (I'm a tad irritated about this, since I tried to tell them [5] and They wouldn't listen! [6].) By the time that SHA-256 (plus our tagging and salting) is vulnerable to collisions, which could be anywhere from five years to a hundred years from now, we will have already upgraded Tahoe to use a stronger hash function (SHA-3 or a SHA-3 candidate) and gracefully upgraded pre-existing files. Now the actual details of securely upgrading extant files to new integrity check mechanisms could be interesting. We've thought a bit about how to facilitate future graceful upgrades and this will no doubt prompt us to think about it some more. The stickiest bits are in the capability itself. Let's put it this way: suppose you upload a file to a Tahoe grid today and get an immutable read cap in return. Then suppose a few years from now someone does some unspecified operation which adds stronger hashes to the file as it exists out there on the servers. Now, how do you as the holder of the original immutable read cap know that those new stronger hashes are correct? You don't, because your read-cap wasn't generated from those new stronger hashes. This isn't a weakness in the Tahoe capability-oriented design, it's more of a fundamental problem which is just thrown into sharper light by the cap design. You can, of course, choose to delegate your decision about whether or not the file is correct to someone else (using Tahoe as well as using any other scheme), but if you want to actually have certainty *yourself* that the file is correct using the new hashes, then you're going to have to do some sort of download and computation on the file yourself, using the new hash algorithm. Regards, Zooko [1] http://www.toad.com/gnu [2] http://en.wikipedia.org/wiki/Custom_hardware_attack [3] http://en.wikipedia.org/wiki/List_of_distributed_computing_projects [4] http://en.wikipedia.org/wiki/Bot_nets [5] http://www.gelato.unsw.edu.au/archives/git/0506/5273.html [6] http://www.gelato.unsw.edu.au/archives/git/0506/5299.html ___ tahoe-dev mailing list tahoe-...@allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev -- -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Mission Impossible: The Code Even the CIA Can't Crack
http://www.wired.com/print/science/discoveries/magazine/17-05/ff_kryptos Mission Impossible: The Code Even the CIA Can't Crack By Steven Levy Email 04.20.09 The sculpture named Kryptos at CIA headquarters contains a secret message ? but not even the agency's brightest can crack its code. Photo: Adrian Gaut The most celebrated inscription at the Central Intelligence Agency's headquarters in Langley, Virginia, used to be the biblical phrase chiseled into marble in the main lobby: And ye shall know the truth, and the truth shall make you free. But in recent years, another text has been the subject of intense scrutiny inside the Company and out: 865 characters of seeming gibberish, punched out of half-inch-thick copper in a courtyard. It's part of a sculpture called Kryptos, created by DC artist James Sanborn. He got the commission in 1988, when the CIA was constructing a new building behind its original headquarters. The agency wanted an outdoor installation for the area between the two buildings, so a solicitation went out for a piece of public art that the general public would never see. Sanborn named his proposal after the Greek word for hidden. The work is a meditation on the nature of secrecy and the elusiveness of truth, its message written entirely in code. Almost 20 years after its dedication, the text has yet to be fully deciphered. A bleary-eyed global community of self-styled cryptanalysts?along with some of the agency's own staffers?has seen three of its four sections solved, revealing evocative prose that only makes the puzzle more confusing. Still uncracked are the 97 characters of the fourth part (known as K4 in Kryptos-speak). And the longer the deadlock continues, the crazier people get. Whether or not our top spooks intended it, the persistent opaqueness of Kryptos subversively embodies the nature of the CIA itself?and serves as a reminder of why secrecy and subterfuge so fascinate us. The whole thing is about the power of secrecy, Sanborn tells me when I visit his studio, a barnlike structure on Jimmy Island in Chesapeake Bay (population: 2). He is 6'7, bearded, and looks a bit younger than his 63 years. Looming behind him is his latest work in progress, a 28-foot-high re-creation of the world's first particle accelerator, surrounded by some of the original hardware from the Manhattan Project. The atomic gear fits nicely with the thrust of Sanborn's oeuvre, which centers on what he calls invisible forces. With Kryptos, Sanborn has made his strongest statement about what we don't see and can't know. He designed a piece that would resonate with this workforce in particular, says Toni Hiley, who curates the employees-only CIA museum. Sanborn's ambitious work includes the 9-foot 11-inch-high main sculpture?an S-shaped wave of copper with cut-out letters, anchored by an 11-foot column of petrified wood?and huge pieces of granite abutting a low fountain. And although most of the installation resides in a space near the CIA cafeteria, where analysts and spies can enjoy it when they eat outside, Kryptos extends beyond the courtyard to the other side of the new building. There, copper plates near the entrance bear snippets of Morse code, and a naturally magnetized lodestone sits by a compass rose etched in granite. People call me an agent of Satan, says artist Sanborn, because I won't tell my secret. Photo: Adrian Gaut The heart of the piece, though, is the encrypted text, scrambled, Sanborn says, by a coding system that would unravel itself slowly over a period of time. When he began the work, Sanborn knew very little about cryptography, so he reluctantly accepted the CIA's offer to work with Ed Scheidt, who had just retired as head of Langley's Cryptographic Center. Scheidt himself was serving two masters. I was reminded of my need to preserve the agency's secrets, Scheidt says. You know, don't tell him the current way of doing business. And don't create something that you cannot break?but at the same time, make it something that will last a while. Scheidt schooled Sanborn in cryptographic techniques employed from the late 19th century until World War II, when field agents had to use pencil and paper to encode and decode their messages. (These days, of course, cryptography is all about rugged computer algorithms using long mathematical keys.) After experimenting with a range of techniques, including poly-alphabetic substitution, shifting matrices, and transposition, the two arrived at a form of old-school, artisanal cryptography that they felt would hold off code breakers long enough to generate some suspense. The solutions, however, were Sanborn's alone, and he did not share them with Scheidt. I assumed the first three sections would be deciphered in a matter of weeks, perhaps months, Sanborn says. Scheidt figured the whole puzzle would be solved in less than seven years. During the two years of construction, there were moments of intrigue and paranoia, in keeping with the
Re: [Opensim-dev] Technical assessment of Cable Beach asset server
From: Toni Alatalo ant...@kyperjokki.fi Subject: Re: [Opensim-dev] Technical assessment of Cable Beach asset server To: opensim-...@lists.berlios.de Date: Thu, 15 Jan 2009 18:47:00 +0200 Reply-To: opensim-...@lists.berlios.de Eugen Leitl kirjoitti: On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote: As an aside from the peanut gallery, it would be nice to have asset storage in a distributed cryptographic filestore like Tahoe http://allmydata.org/~warner/pycon-tahoe.html that has been my understanding as well. basically after worked a bit with the guys who pushed it in the Fenfire project (in 2002). i've understood that basically by using URIs as references to assets we get that: URLs for current http stuff and location independent URNs with distributed things like p2p networks. seems that Tahoe also uses short URI-like strings - dunno why 'URI-like' and not just URIs but anyway :) .. also as SL and OpenSim already uses UUIDs i guess some things are basically kind of ready for this. http://www.ht03.org/papers/pdfs/24.pdf is about the work in that area i was interested back long ago, dunno about the current implementations whether Tapestry, that Tahoe or something I haven't heard of is the thing, but i guess the basic idea is the same. in that Fenfire Storm the idea was to use content based hashes as IDs of files (like images), similar to Freenode -- the goal not being anonymous publishing in a secure p2p net, but instead having a nice storage system for both local own files and publishing them on the net. goals included the secure storage via redundancy, that seems to be emphasized in Tahoe and is indeed a great motivation for these things. looking forward to learning more, perhaps by testing Tahoe ~~Toni ___ Opensim-dev mailing list opensim-...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Quantum direct communication: secrecy without key distribution
From: the physics arXiv blog [EMAIL PROTECTED] Subject: the physics arXiv blog To: [EMAIL PROTECTED] Date: Fri, 05 Dec 2008 13:10:50 + [1]the physics arXiv blog [2]Quantum direct communication: secrecy without key distribution Posted: 04 Dec 2008 09:13 PM PST [3]quantum-direct-communication.jpg An interesting development in the world of quantum encryption. In the last couple of years, we've seen a number of quantum key distribution systems being set up that boast close-to-perfect security ([4]although they're not as secure as the marketing might imply). These systems rely on two-part security. The first is the quantum part which reveals whether a message has been intercepted or not. Obviously this is no use when it comes to sending secret message because it can only uncover eavesdroppers after the fact. So Alice sends a one time pad over this quantum channel that she and Bob can later use to encrypt and send a message classically. If this key is compromised, Alice sends another. What guarantees the security is not quantum mechanics but the second part of the system: the one time pad. Today, Seth Lloyd and colleagues at the Massachusetts Institute of Technology in Cambridge, publish a way of guaranteeing security over a quantum channel without having to fall back on a one time pad. Their idea is to send a message over a standard quantum channel without bothering with a one time pad. The security, they say, can be monitored by randomly checking the channel to see whether any of the qubits are being lost (potentially to Eve). The security of the channel then depends on how much loss of information Alice and Bob are willing to accept, but can always be improved by checking more often for eavesdroppers. Quantum direct communication, as the team call it, looks interesting. But it will be demanding to implement, not least because any noise in the channel will look like an eavesdropper. So it looks as if this idea will have to be limited to short range applications where noise can be kept to a minimum. Nevertheless, a cool idea. Ref: [5]arxiv.org/abs/0802.0656: Quantum Direct Communication with Continuous Variables [6][ISMAP:i] [7][arXivblog?d=41] [8][arXivblog?d=43] [9][arXivblog?i=FkCcdrzA] [10][arXivblog?d=50] [11][arXivblog?i=AA6d3u4X] [12][arXivblog?d=54] [13][arXivblog?i=gWxiPcYK] [14][arXivblog?d=52] You are subscribed to email updates from [15]the physics arXiv blog To stop receiving these emails, you may [16]unsubscribe now. Email delivery powered by Google Inbox too full? [17](feed) [18]Subscribe to the feed version of the physics arXiv blog in a feed reader. If you prefer to unsubscribe via postal mail, write to: the physics arXiv blog, c/o Google, 20 W Kinzie, Chicago IL USA 60610 References 1. http://arxivblog.com/ 2. http://feedproxy.google.com/~r/arXivblog/~3/L2dvPUasU7A/ 3. http://arxivblog.com/wp-content/uploads/2008/12/quantum-direct-communication.jpg 4. http://arxivblog.com/?p=637 5. http://arxiv.org/abs/0802.0656 6. https://feedads.googleadservices.com/~a/i7RRFcowUHJnq_spRFzOodIFPIY/a 7. http://feedproxy.google.com/~f/arXivblog?a=HIgKcQ0O 8. http://feedproxy.google.com/~f/arXivblog?a=bO8lGfma 9. http://feedproxy.google.com/~f/arXivblog?a=FkCcdrzA 10. http://feedproxy.google.com/~f/arXivblog?a=ybFs1PaM 11. http://feedproxy.google.com/~f/arXivblog?a=AA6d3u4X 12. http://feedproxy.google.com/~f/arXivblog?a=sdxB9J6P 13. http://feedproxy.google.com/~f/arXivblog?a=gWxiPcYK 14. http://feedproxy.google.com/~f/arXivblog?a=rqQMNiZh 15. http://arxivblog.com/ 16. http://feedburner.google.com/fb/a/mailunsubscribe?k=118r9-S4Z0vJg-AkQPASPmDmlGQ 17. http://feedproxy.google.com/arXivblog 18. http://feedproxy.google.com/arXivblog -- -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
26 historic Enigmas found in Spain
http://www.theregister.co.uk/2008/10/24/spanish_enigmas/ Spanish discover cache of 26 Enigma machines Franco's 'secret weapon' tracked to army HQ By Lester Haines Posted in Science, 24th October 2008 10:03 GMT Spanish newspaper El Pa�s last week tracked down 26 examples of Franco's secret weapon against Republican forces in the country's civil war - a cache of perfectly-preserved Enigma machines hidden for years in a gloomy office in the army's main headquarters in Madrid. Nationalist forces led by Franco acquired their first ten Enigma machines from Germany in 1936. While Hitler had already decided to offer Franco his full support in the Spanish civil war, this didn't actually extend to the full-fat military versions of Enigma, and his Iberian ally had to make do with the vastly inferior commercial D model. The German High Command was apparently concerned that careless Spaniards might let the Republicans get their hands on an Enigma. Indeed, even Germany's Condor Legion - dispatched to Spain to aid the Nationalist cause - also reportedly used commercial Enigmas in the field. Nonetheless, the Republicans were never able to decipher Enigma communications between Franco and his top brass, and the machines' success led to further acquisitions. Commander Antonio Sarmiento, charged with training operators in Franco's Salamanca headquarters, enthusiastically reported in 1936: ?To give some idea of the level of security these machines offer, it's suffice to say that the number of possible combinations is an astounding 1,252,962,387,456.? The total number of machines eventually bought by Spain is unknown, although estimates vary from 30 to 50. They were not withdrawn from service until the early 1950s, which offers the rather agreeable possibility that the British were able to read the Spanish dictatorship's military communications while Franco remained blissfully unaware that his Nazi sponsors' device had been laid bare by Bletchley Park years before. Bootnote El Reg is, of course, supporting Bletchley Park and the National Museum of Computing with our splendid Enigma t-shirt. Get it before Cash'n'Carrion's free shipping offer ends on 31 October. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Wed, Aug 27, 2008 at 12:16:23PM -0400, Steven M. Bellovin wrote: Finally, the transponders may not matter much longer; OCR on license plates is getting that good. As has already been mentioned, the 407 ETR road in Toronto already relies on this to some extent; it won't be too much longer before the human assist is all but unneeded. http://en.wikipedia.org/wiki/Toll_Collect is in operation in entire Germany. It does OCR on all license plates (also used for police purposes in realtime, despite initial vigorous denial) but currently is only used for truck toll. -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Thu, Aug 28, 2008 at 06:03:14PM +0200, Stefan Kelm wrote: We've been helping the German Toll Collect system (as discussed in this thread as well) setting up and implementing their data privacy concept. This concept requires Toll Collect to delete almost any data after a certain (quite short, actually) They (not Toll Collect, though) do a realtime query against a reasonably long list of license plates in some German states, I recall reading. http://www.heise.de/newsticker/Hessische-Polizei-hat-seit-Maerz-eine-Million-Kfz-Kennzeichen-gescannt--/meldung/99197 amount of time. Even with disk prices falling they save lots and lots of money (even compared to what we charged them for telling them... :-) ). Given where things are headed in Germany, I guarantee you Toll Collect will be required by law to do data retention for at least a year or two in less than 5 years. http://www.heise.de/newsticker/Debatte-um-Zugriff-auf-LKW-Mautdaten-fuer-Fahndungen-geht-weiter--/meldung/76321 -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Beowulf] Re: hobbyists
From: Kilian CAVALOTTI [EMAIL PROTECTED] Subject: Re: [Beowulf] Re: hobbyists To: Tim Cutts [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Fri, 20 Jun 2008 10:55:38 -0700 Organization: Bio-X / Clark Center - Stanford University On Friday 20 June 2008 06:51:51 am Tim Cutts wrote: That'll be why we don't allow Skype, except on one network which, from a security perspective, is considered to be outside the Institute, and just as untrusted as the rest of the Internet. I think that's a wise decision. Skype is a giant black box. Fabrice Desclaux published a fair amount of cryptanalysis papers about Skype, each one more frightening than the previous ([1], [2] and [3]) [1]http://www.secdev.org/conf/skype_BHEU06.handout.pdf [2]http://recon.cx/en/f/vskype-part1.pdf [3]http://recon.cx/en/f/vskype-part2.pdf In 2005, an official recommendation has been issued by the French authorities to prohibit usage of Skype in the National Center for Scientific Research (CNRS)'s networks (see [4], and [5] for the machine-translated version) [4]http://www.urec.cnrs.fr/rubrique216.html [5]http://translate.google.com/translate?u=http%3A%2F%2Fwww.urec.cnrs.fr%2Frubrique216.htmlhl=enie=UTF8sl=frtl=en -- Kilian ___ Beowulf mailing list, [EMAIL PROTECTED] To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf -- -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On Thu, Jun 21, 2007 at 06:00:48PM +0100, Richard Clayton wrote: (a) the EU legislation was actually passed well over a year ago http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2006/l_105/l_10520060413en00540063.pdf It is not national law yet. I'm only concerned about when I have to deal with it personally. and applies to service providers so random endpoints will be The pending legislation is stated broadly enough to include anyone with a proxy or a mix cascade, company or private body, for-profit or non-profit. It threatens up to half a megaeuro penalty and up to two years in jail. unlikely to be caught by its requirements. Any random endpoints will be passing through the ISP, and hence subject to retention. An ad hoc IPsec or VPN tunnel setup will make data analysis more difficult, especially if there's traffic background (P2P, etc). So what's the state in ad hoc IPsec/VPN setup for any end points? (b) what the Directive exactly means is anyone's guess (the wording shows a deep failure to understand how the Internet works), and it is entirely clear that it will in practice mean different things in different EU countries. I've been told this legislation will be used by several persons within BKA etc. to harass Tor operators. This is not a guess; I'm not sure how reliable that source is, however. In the UK it's likely to only apply to large public ISPs -- and retention will be restricted to records of who used which IP address, email server records, and possibly web cache logs (possibly not, since web caches may not be economic if the logs have to be retained)... The financial burden is completely on the side of the providers. ... the wikipedia page on the topic http://en.wikipedia.org/wiki/Data_retention ... has information for other countries that looks fairly plausible from what I know about their plans. Unfortunately, I know more about the plans than I ever wished. Note that the Directive also applies to phone calls ... and the It also applies to mobile phone location in the cell. transposition of that into national laws is supposed to be completed by October 2007; most countries have until March 2009 for Internet logs Apparently, Germany will implement Internet connection retention by end of the year/beginning of 2008 latest. -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Thu, Jun 21, 2007 at 01:20:35PM -0400, Victor Duchovni wrote: Quantum Cryptography or Quantum Computing (i.e. cryptanysis)? - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). - Quantum Computing is science fiction. Some science fiction eventually becomes reality. A nice blog to follow here is Shtetl-Optimized: http://www.scottaaronson.com/blog/ -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ad hoc IPsec or similiar
There's a rather ominous EU legislation to be passed soon, which requires any party acting as a provider (you run anonymous proxy, or mix cascade, you are a provider) to log all connection info (when, who, with whom). What's the status of ad hoc IPsec or any other TCP/IP-tunneling VPN for random endpoints? -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
C7, Jetway, performance
Anyone here running a recent Jetway or similiar product with a C7? Care to share your benchmarks, as to IPsec Co throughput? I'm thinking about picking up a J7F2WE1G5D, or similiar, and a triple-GBit Ethernet (Realtek RTL81108, or similiar), and am interested in how that thing performs at 100..1000 MBit/s speed, with IPsec or OpenVPN (FreeBSD 6.2 or pfsense data would be great). -- 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[EMAIL PROTECTED]: Re: FIPS 140-2 Validation Revoked]
- Forwarded message from Richard Salz [EMAIL PROTECTED] - From: Richard Salz [EMAIL PROTECTED] Date: Wed, 19 Jul 2006 01:09:12 -0400 To: openssl-dev@openssl.org Cc: [EMAIL PROTECTED] Subject: Re: FIPS 140-2 Validation Revoked X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Reply-To: openssl-dev@openssl.org I wish to make it very clear that in this message I am speaking solely as an individual, and do not represent my employer or its views in any way at all. We don't know the full story behind this yet, and perhaps never will. As John Weathersby noted in the article, This is not about technology. This is baloney. The boundary around the formerly-validated code was completely wrong -- a simple analysis showed that code within the FIPS container called code outside the container. A sample program showed how this led to trivial breaks in security. I have seen a document that had this analysis, and included a sample program that printed all private keys to the screen and when asked for random numbers always returned the same value. I know this document was given to the module authors and the validation lab. The authors ignored this and also convinced the validation lab to ignore it. The lab (I'm really glad they're not a subsidiary of my employer any more) trusted the vendor; had they performed the most basic due diligence -- compile the program! -- they would have seen that the code should not have passed. Hell, 'nm fipscanister.o | fgrep U' would have shown it! There were other problems as well. For example, the DES/3DES self-test did not test encryption. Even worse, the implementation tested isn't the one used by the public API's. (OpenSSL includes multiple DES/3DES implementations.) Open source is not magic pixie dust that allows you to ignore basic reality. The certified code had serious flaws that were known to the parties involved in certification, yet they went ahead anyway. CMVP did the right thing. Can you imagine the damage that could have been done if either critical systems were built using that code, or if a true enemy of the open source movement published the sample code after it had widespread use? It greatly saddens me to say this, but unless there are significant changes in the process and/or participants, I will continue to advise anyone who wants to rely on a FIPS-ccertified OpenSSL that it is not safe to do so. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: FIPS 140-2 Validation Revoked]
. (OpenSSL includes multiple DES/3DES implementations.) Tim misread the DES self-test implementation look at the fourth argument to the DES_ebb_encrypt() function which is used for both encryption and decryption. FIPS 140-2 does not require that the APIs of the validated module be used directly by all applications. All these allegations were covered in detailed correspondence between myself, the OpenSSL team, and the CMVP. Open source is not magic pixie dust that allows you to ignore basic reality. The certified code had serious flaws that were known to the parties involved in certification, yet they went ahead anyway. CMVP did the right thing. Can you imagine the damage that could have been done if either critical systems were built using that code, or if a true enemy of the open source movement published the sample code after it had widespread use? It greatly saddens me to say this, but unless there are significant changes in the process and/or participants, I will continue to advise anyone who wants to rely on a FIPS-certified OpenSSL that it is not safe to do so. Well, you're waxing poetic here and I think you're being a little harsh. The CMVP is doing the right thing, performing careful analysis and allowing us to correct the one flaw they identified from the many allegations. This validation effort, some four years in the running, has been a learning experience for all of the participants, CMVP included. I give them credit for their commitment and effort in breaking new ground, when a less dedicated bureaucracy would have found excuses to punt. The understanding of the complexities in applying FIPS 140-2 to source based portable code, and the corresponding guidance from the CMVP, has changed and matured considerably since we started. BTW the correct term is validation, not certification. Also, OpenSSL was not validated, the validated product is the OpenSSL FIPS Object Module, a separate software component designed for use with OpenSSL. Both common slips; it took me a year to break that habit :-) -Steve M. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Tor security advisory: hidden services can be located quickly]
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] - From: Roger Dingledine [EMAIL PROTECTED] Date: Thu, 12 Jan 2006 18:03:40 -0500 To: [EMAIL PROTECTED] Subject: Tor security advisory: hidden services can be located quickly User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] Versions affected: all stable versions, and all experimental versions up through 0.1.1.10-alpha. Impact: If you offer a Tor hidden service, an adversary who can run a fast Tor server and who knows some basic statistics can find the location of your hidden service in a matter of minutes to hours. Solution: You have three options: 1) Upgrade to Tor 0.1.1.12-alpha from the Tor download page [1]. You're all set, though be aware that this is an alpha release so there may be other bugs. You may also want to look through the release notes [2]. 2) Turn off your hidden service until the final 0.1.1.x release is out. It may be several months. 3) Stick with Tor 0.1.0.16 and manually configure a half dozen EntryNodes. See the FAQ entry [3] for some hints about how to do this. The details: Tor researchers Lasse ?verlier and Paul Syverson have confirmed that a previously theoretical attack on Tor works very well in practice. Specifically, they found that a malicious Tor server can locate a hidden service more quickly than was previously believed. The attack is simple: access the hidden service repeatedly, and keep track of who builds circuits through you shortly after each access. Because you can induce your victim to build a new circuit on demand, eventually one of his circuits will start at your node. To slow this attack, our latest experimental release implements a new feature called guard nodes: it automatically chooses a handful of entry nodes and sticks with them for all circuits. This idea is adapted from the helper node concept published by Wright et al [4], but with improved reliability: rather than picking a set of entry nodes and refusing to access the Tor network if they all become unreachable, Tor's design dynamically picks new guards as needed, yet switches back to the old ones when they become reachable again. Therefore Tor users still have the same level of robustness as before, but the chance of a successful attack by a limited adversary is greatly reduced. More details will be presented on January 14 at Shmoocon [5] and January 26 at Black Hat Federal [6]. --Roger [1] http://tor.eff.org/download [2] http://archives.seul.org/or/talk/Jan-2006/msg00024.html http://archives.seul.org/or/talk/Jan-2006/msg00026.html [3] http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit [4] http://freehaven.net/anonbib/#wright03 [5] http://www.shmoocon.org/speakers.html#overlier [6] http://www.blackhat.com/html/bh-federal-06/bh-fed-06-speakers.html#Syverson - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin]
- Forwarded message from coderman [EMAIL PROTECTED] - From: coderman [EMAIL PROTECTED] Date: Sun, 1 Jan 2006 18:53:13 -0800 To: J.A. Terranson [EMAIL PROTECTED] Cc: Tyler Durden [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: [IP] more on AP Story Justice Dept. Probing Domestic Spyin On 1/1/06, J.A. Terranson [EMAIL PROTECTED] wrote: (1) We are describing encryptedmessage sent over the public internet - granted, it's in pieces, yet it's still sent into the public cloud; yeah, follow tcp stream in ethereal is a good example of how trivial it is to recreate a session of communication given an archive of its component datagrams. (2) These various pieces are all record communications as far as NSA/Echelon is concerned, and therefore we should expect that they will draw significant attention - and end up in permanent archives; right. hence my fetish for one time pads for key exchange and previous comment about quantum computers / fast GNFS / etc. they are up to 8 qubits, only a few thousand more to go. ;) (3) Since all off the pieces have been stored - including both the encrypted messagetexts and the decryptors, what is to prevent a time-faking attack against this message? After all, if you have all the parts, you can just reinstantiate the network as it was was the messages were originally sent. this is particular to the method TD mentioned i think... i am assuming the following: - the operating system is installed on a loop-aes volume so that integrity of the kernel, libraries and utilities is protected via passphrase. - the one time pads are stored encrypted in a similar manner so that access to them requires external keys (like the gpg encrypted keys used for loop-aes volumes) - the passphrase used to authenticate a user for access to the pads is coupled with external storage (usb) of the keys used to access the pads. to recover the plaintext communication from the encrypted datagrams the attacker would need to obtain the encrypted pad, the keys on external storage (usb), and the passphrase to access the keys. (4) For any form of time-destruction messaging to really work, the keying information would have to be tied to a physical something that cannot be reclaimed, and which decays at a fixed, known, and closely approximatable rate (a radiodecay probably doesn't meet this criteria); Every time-sensitive auto-destructing system Ive seen discussed here fails these weaknesses. this doesn't provide time destruction so i assume this is in reference to Tyler's description. you could couple the user authentication with a physically hardened token of some sort for access to the pads but even this would require manual destruction. do they make physically hardened authentication tokens with timed self destruction built in? - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820http://www.ativel.com 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: Cisco VPN password recovery program
On Wed, Oct 19, 2005 at 09:45:38AM -0500, Alaric Dailey wrote: Cisco seems to be doing these kinds of boneheaded things for quite sometime. Does Juniper have a better security story? -- 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]: Wikipedia proposal]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Fri, 7 Oct 2005 07:57:11 + (UTC) To: [EMAIL PROTECTED] Subject: Wikipedia proposal Reply-To: [EMAIL PROTECTED] I just posted this to wikitech-l: There has been a lot of discussion lately on the or-talk list about how to let tor and other anonymizing proxy users edit wikipedia without allowing vandals free rein. Several straightforward approaches have been proposed, such as holding edits in escrow pending approval by a trusted user, and requiring anonymizing network users to login before posting. The latter idea in particular could easily be abused, since abusers can create a new account for each edit. Roger Dingledine, tor's author, suggested creating a pseudonym service using a cryptographic construction called blind signatures: http://www.rsasecurity.com/rsalabs/node.asp?id=2339 Basically, Alice can generate a token, mathematically blind it (obscuring its value), have it signed, then unblind the signature. Anyone can verify that the signature on the token is valid, but nobody, including the signer, can link the blinded value Alice had signed with her unblinded token. I implemented such a scheme which works as follows: * Alice creates and blinds a token, then submits it to a token server for signing. Optionally, the token server may have a list of IPs banned from wikipedia, and refuse to sign Alice's token if her IP is on the list. * The token server signs the blinded token, then records what IP address Alice used so that she can't obtain multiple tokens per IP address. Later, this will allow us to block Alice's IP address if she misbehaves, just as Wikipedia admins currently do, except that now it'll work even when she connects via tor. Token rationing could also be done based on other (more or less) scarce resources, including email addresses, captchas, CPU-intensive tasks or even money, just as I'm sure has been proposed for the vanilla wikipedia. The advantage of blind signatures is that tokens can be recorded and blocked without revealing the potentially sensitive underlying resource (such as a personal email address or IP address). * Alice can now turn on tor and present her token to wp, without revealing her actual IP address. This token takes the place of the IP address record currently stored along with article edits, and can be blacklisted just the same way that IPs are banned. * However, I implemented an intermediary step which has several advantages. Instead of presenting her token to wp, Alice generates an essentially empty client certificate and presents it via the tor network to a certificate authority (CA) for signing, along with the signed token. The CA records that the token has been spent (preventing her from receiving multiple certs per token), then signs her cert just as Verisign would sign a server SSL certificate. Since she connects via tor, the CA doesn't learn her real IP address. * Alice installs the client certificate in her browser, then connects to a special wp server running an SSL server that demands valid client certificates from our CA. That configuration takes only 4 lines in my apache-ssl server's httpd.conf. Apache automatically sets environment variables which identify the client certificate, and which can be used in place of the REMOTE_ADDR variable currently used to record users' incoming IP addresses when marking page edits. Blocking a client cert would then be just as easy as blocking an IP address. All of Alice's edits will be marked with that identifier unless she obtains a new IP address (or other scarce resource) and repeats the process to obtain another certificate. Later, features can optionally be added which will allow her to have separate identifiers for each edit (protecting her in case, say, her repressive government confiscates her computer in order to find out if she wrote a particular article they disagree with). I have already released code to implement this system, with the exception of the wp-specific code. I sent the proposal to both the or-talk lists and the cryptography list at metzdowd.com on Monday. Next I'd like your comments, before I dive into the mediawiki code (or find someone willing to help with this part). Once the feature is complete, we can set up a live test wiki for people to bang on, before we consider implementation on the live wp servers. -J - 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
[EMAIL PROTECTED]: [IP] more on ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)]]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Mon, 19 Sep 2005 20:30:36 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] more on ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Rod Van Meter [EMAIL PROTECTED] Date: September 19, 2005 7:25:19 PM EDT To: Joe Touch [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], David Wagner [EMAIL PROTECTED] Subject: Re: [Fwd: Re: [IP] ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)] Reply-To: [EMAIL PROTECTED] [Dave, for IP, if you wish...] I generally agree with Dave Wagner's response, but a few thoughts... The physicists are indeed working on quantum repeaters, capable of doing QKD over long distances. The trouble is, you have to trust every one of the repeaters. I wouldn't phrase the fiber security issue quite the same way. As others have said, what you need is access to an authenticated channel, then you're set (but that's a non-trivial problem!). It's important to note that a) QKD does NOT solve what Shor's factoring algorithm broke, and b) key exchange/distribution is not the biggest security problem we have on the net (it might not even make the top ten). The one possibly interesting use of QKD is for the super-paranoid: those who believe their traffic is being snooped today, and don't want it decrypted fifty years from now when theoretical and technological advances render all classical cryptography breakable (!?!). But in order for that to work, you have to use the QKD-generated random bit string as a one-time pad, not just a seed or key for classical encryption. That means you need very high QKD bit-generation rates, and most are still in the kilobits/second. Some experiments have been done in the low megabits/sec., but that's pre-filtering, I believe, which costs you at least one order of magnitude in performance. If you do it right, then, authentication that is good enough TODAY, plus QKD to generate a random one-time pad, can make your data secure FOREVER (modulo breakins/breakdowns at the endpoints). Even if your authentication is broken later, since it's not used in the actual data exchange, the attacker gains no data. This is covered in Paterson et al.'s paper. I arrived at the party a little late to get in on the recent thread at Dave Bacon's Quantum Pontiff blog, but I did throw in my two cents anyway: http://dabacon.org/pontiff/?p=1049#comments Dave's blog is an excellent source for current news and gossip, and is read (and commented on) by many of the best names in the biz. btw, Steve, not sure if you're aware of it or not, but Al Aho's student Krysta Svore is doing quantum stuff for her thesis. She just spent a year in Cambridge working with Ike Chuang, but is back at Columbia, I understand. She's pretty sharp. --Rod - 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 signature.asc Description: Digital signature
Re: European country forbids its citizens from smiling for passport photos
On Sat, Sep 17, 2005 at 10:52:48AM -0400, William Allen Simpson wrote: Do you really need to click on this link to know which one it is? U.K.? http://www.iht.com/articles/2005/09/12/news/travel13.php All of them? US and Canadia as well? http://cbs5.com/watercooler/watercooler_story_258152613.html I guess we should give neutral facial expressions for the photo, then smile (or frown) while in the airport We should violet-wand the smartcard pads. Or sever the antenna for the RFID. Or just use the dead tree one, and not reapply when it expires. Sounds like the technology (still) isn't ready for prime time. Not ready for 1984? One sure would hope so. -- 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: Is there any future for smartcards?
On Mon, Sep 12, 2005 at 09:52:27AM -0700, James A. Donald wrote: Typical worm installation goes like this: : : Receive message via bluetooth from unnamed : : device? Y/N : : : : Installation Security warning: Unable to : : verify supplier. Continue anyway? Y/N It's just a networked computer that happens to look like a mobile phone. Not particularly security-oriented. It also doesn't matter what current malware does on the current platform. FWIW, it's still in primitive shenanigan stage. It's a question what future malware on future mobile platforms will do. It's a machine for young social primates. Not suitable for a payment system, unless equipped with dedicated, hardened cryptographic compartment with dedicated display and PIN/biometrics. http://www.f-secure.com/weblog/archives/archive-052005.html Yesterday we received information on Commwarrior.B sightings on two new countries: Greece and South Africa. So it seems that the rate in which Commwarrior is spotted is quite a lot faster than with Cabir. But then again, high discovery rate might be result of increased public awareness. Also as Commwarrior is in the wild here in Finland, we have had an opportunity to follow how the worm spreads and interviewed people who have been infected with it. And it seems that we have found at least partial answer to the question why people install Symbian worms on their phones. The most common reason why people have installed Commwarrior from MMS message is the trust that they have on the sender. People are wary of messages that they receive from unknown sources, but quite willing to install whatever has been sent from a friends mobile. This is a phenomenon that we have also seen with E-Mail worms, people just are unwilling to mistrust something coming from a friend. Current count of countries with Commwarrior sightings: 1.Ireland 2.India 3.Oman 4.Italy 5.Philippines 6.Finland 7.Greece 8.South Africa Seems to me that the phone designers have done a better job with virus, worm, and malware resistance than Microsoft or Linux. Teenagers are pretty sophisticated. Are we talking even about the same species? About the same teenagers which already own malware-infested PCs, and swap whatever ringtones, logos and games en vogue with their FOAFs? -- 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: Is there any future for smartcards?
On Sun, Sep 11, 2005 at 06:49:58PM -0400, Scott Guthery wrote: 1) GSM/3G handsets are networked card readers that are pretty successful. They are I'd wager about as secure as an ATM or a POS, particularly with respect to social attacks. The smartphones not secure at all, because anything you enter on the keypad and see on the display can be compromised, so the tamper-proof cryptographic goodness locked inside the SIM smartcard will cheerfully approve whatever the code running on the smartphone will tell it to approve, regardless of what is being displayed to the user. Virtually all new phones sold are smartphones, and for every platform there are documented vulnerabilities, exploits, and malware already in the wild. Increased use of mobile phones as means of payment are a strong motivation for malware writers. Most of smartphone users are security-naive teenagers. This indicates that we'll be getting all problems with desktop machines, and more, shortly. 2) ISO is currently writing a standard for a secure home card reader. The starting point is FINREAD. See JTC1/SC17/SG4/TF10. I own a secure home card reader (which happens on run on Windows, Linux and OS X, with open source drivers -- my model has a keyboard but no display, but other models from the same manufacturer do). Standars are good. I'm all for standars, as long as they describe what eventually will be a real world product. Unless financial institutions will be required by law to issue secure smartcards and smartcard readers, or suffer extreme losses through fraud they won't introduce these secure readers and smartcards. -- 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: Is there any future for smartcards?
On Sun, Sep 11, 2005 at 10:53:34PM +1200, Peter Gutmann wrote: The problem with this is that in 99.99% of cases the insecure networked machine *is* the reader, rendering the smart card pretty much pointless. I've Pat Farrel spoke about the infrastructure required for smartcards to have at all a point. Inexpensive USB readers with integrated keypad (and LCD display) exist, and are a basic component of such smartcard infrastructure. Unless it's pure snakeoil, by design. only ever seen a handful of card readers that have keypads and displays, and none that have succeeded commercially. Everyone just gets the cheap reader- only devices. USB smarcard readers with displays are not expensive, especially if purchased in quantities. A financial institution would probably recover the costs quite rapidly, if it gave away smartcards and such readers for free to its customers, given the amount of fraud. It is symptomatic that this is not happening, and that e.g. HBCI support hereabouts is very thin. HBCI+smartcard, especially on a non-Redmond system, is nearly impossible to set up. Zero support. (Support in fact discourages use of smartcard). Default for local online banking is PIN/TAN (TANs distributed on dead tree). -- 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: Is there any future for smartcards?
On Wed, Sep 07, 2005 at 06:08:25PM -0400, Pat Farrell wrote: Something tells me that soon is not gonna happen in what I would call soon. Smartcards (the smart part) were moderately interesting when there was no networking. We've been at ubiquitous networking for many years. We also have ubiquitous networking of systems which are vulnerable and frequently compromised. Smartcard + reader is a hardened cryptographic compartment where you can still trust what you see on the reader display, and that nobody can sniff what is entered on the keypad. Such a system can be safely connected to an insecure, networked machine. Is there a real problem that they uniquely solve, sufficient to drive the building of the needed infrastructure? I don't see it, and I'd love to be made smarter. -- 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: Retailers Experiment With Biometric Payment article
On Thu, Jun 09, 2005 at 12:02:20PM -0400, Adam Shostack wrote: Has anyone ever studied the reversability of these algorithms? It seems to me that you could make some plausible guesses and generate fingerprints from certain representations. I don't know how likely those guesses are to be right. The fingerprint hash (fingerprint's fingerprint) has to be resistant to rotation/translation, area size and subpattern presence, and tolerate some skin lesion noise, so it's the very opposite of a cryptographic hash. Probably quite easy to reverse. -- 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]: [IP] Intel quietly embeds DRM in it's 945 chips firmware]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Tue, 31 May 2005 08:17:59 -0400 To: Ip ip ip@v2.listbox.com Subject: [IP] Intel quietly embeds DRM in it's 945 chips firmware X-Mailer: Apple Mail (2.730) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Date: May 31, 2005 1:15:49 AM EDT To: [EMAIL PROTECTED] Subject: Re: [IP] Intel quietly embeds DRM in it's 945 chips firmware Dave Farber: Please remove my name and identity from this mailing, due to fear of reprisal. (I still work in the entetainment business from time to time.) I do not know all about Intel's DRM, but I do know more, perhaps, than I should. What I do know is that Intel has been working very closely with the entertainment industry on a DRM that, I've been told, seeks to satisfy EVERYONE'S wishes. Of course, such a system would mean, by definition, that it will satisfy either no one, or only the studios. But I do know that the Intel dream DRM system would allow content to be moved from one platform to another on a network, presumably through a check-in/check-out procedure, to make sure only a limited number of (legitimate) copies would be made and in service at any one time. Intel's system also acknowledges, for example, that a high- resolution (e.g. high definition video) copy of a film could be used to create low-res (like Quicktime, Real or Windows Media) versions that could be used in portable video players. Users might even be able to loan time-limited copies or be allowed to make a small number of copies, like Apple's Fair Play DRM permits. You can check out Intel's ideas for such a system, and the participation of an entertainment and consumer electronics industry panel called the Digital Home Working Group, on which Intel sits, which has been addressing such a system in this article from February, 2004: http://www.infoworld.com/article/04/02/24/HNbarrettdrm_1.html (Note: The Japanese system for hard disk and DVD recorders that Barrett alludes to is called CPRM. It is neither new nor flexible, and there has already been some consumer backlash against it in Japan, where it is used for the transmission of digital TV b'casts -- sort of their broadcast flag.) At the root of the problem, of course, is the personal computer that's used as a media player platform. This is also, not coincidentally, Intel's cash cow. Such a DRM system, with the PC playing a pivotal role, would also mean that IBM or other chip vendors would not be allowed to play without building in the same chip-level protection. Without these important security pieces, Apple, for example, would be cut out of the picture for playing content protected by the Intel-endorsed DRM, as would (most likely) Linux-based devices. This is a GRAND PLAN that relies on it being either almost completely transparent to consumers (like Apple's Fair Play) or simple to understand. Unfortunately, almost no DRM is easily understood by consumers. Even most of the customer's for Apple's iTunes Music Store only become familiar with the terms under which they've purchased their music when they bump up against the limitations that have been set. The real nightmare scenario, in my opinion, is a world in which several such DRMs co-exist, creating a chaotic environment in which you never know whether content will play on one plaform but not another. This is a potentially really sticky mess. - 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 signature.asc Description: Digital signature
DTV Content Protection (fwd from cripto@ecn.org)
degree of protection. -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpOymYbwYq6f.pgp Description: PGP signature
ocf-linux-20050315 - Asynchronous Crypto support for linux (fwd from [EMAIL PROTECTED])
From: David McCullough [EMAIL PROTECTED] Subject: ocf-linux-20050315 - Asynchronous Crypto support for linux To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Cc: Andrew Morton [EMAIL PROTECTED], James Morris [EMAIL PROTECTED], Herbert Xu [EMAIL PROTECTED] Date: Tue, 15 Mar 2005 23:36:44 +1000 Hi all, The latest release of ocf-linux (20050315) is available for download from the project page: http://ocf-linux.sourceforge.net/ This release includes the following changes: * Hifn PLL bug fixes * Makefile fixes for 2.6 builds * 2.6.11 and 2.4.29 patches * cleanups for x86 builds OCF-Linux is a Linux port of the OpenBSD/FreeBSD Cryptographic Framework (OCF). This port aims to bring full asynchronous HW/SW crypto acceleration to the Linux kernel and applications running under Linux. Results have shown improvements of up to 7 times that of software crypto for bulk crypto throughput using OpenSSL. At this point in time OCF-Linux provides acceleration for OpenSSL, OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key operations with plans to include Random Number generators and more. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpeb3Res97Sm.pgp Description: PGP signature
Re: Dell to Add Security Chip to PCs
On Wed, Feb 02, 2005 at 05:30:33PM +0100, Erwann ABALEA wrote: Please stop relaying FUD. You have full control over your PC, even if this Please stop relaying pro-DRM pabulum. The only reason for Nagscab is restricting the user's rights to his own files. Of course there are other reasons for having crypto compartments in your machine, but the reason Dell/IBM is rolling them out is not that. one is equiped with a TCPA chip. See the TCPA chip as a hardware security module integrated into your PC. An API exists to use it, and one if the functions of this API is 'take ownership', which has the effect of erasing it and regenerating new internal keys. Really? How interesting. Please tell us more. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpVsHbUYu02H.pgp Description: PGP signature
[i2p] Tunnel cryptography for I2P 0.5 (corrected typo) (fwd from [EMAIL PROTECTED])
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 [EMAIL PROTECTED] http://i2p.dnsalias.net/mailman/listinfo/i2p -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp81rWI38QAG.pgp Description: PGP signature
[PadLock] PadLock patches for linux kernel 2.6.10 (fwd from [EMAIL PROTECTED])
From: Michal Ludvig [EMAIL PROTECTED] Subject: [PadLock] PadLock patches for linux kernel 2.6.10 To: [EMAIL PROTECTED] Date: Fri, 7 Jan 2005 17:24:02 +0100 (CET) From: Michal Ludvig [EMAIL PROTECTED] Date: Fri, 7 Jan 2005 17:24:02 +0100 (CET) To: [EMAIL PROTECTED] Subject: [PadLock] PadLock patches for linux kernel 2.6.10 Hi all, Updated VIA PadLock drivers for linux kernel 2.6.10 are available at http://www.logix.cz/michal/devel/padlock/ The recently reported problem with GCC 3.4.3 is addressed there. Good news - initial PadLock support was accepted into the vanilla kernel in 2.6.10-bk1 (i.e. right after 2.6.10 was released). Official kernel 2.6.11 will have it without patching. Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal ___ PadLock mailing list [EMAIL PROTECTED] http://lists.logix.cz/mailman/listinfo/padlock -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpIVdKKi4vFz.pgp Description: PGP signature
OCF port to linux (fwd from [EMAIL PROTECTED])
-- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpZEaJx0O0JX.pgp Description: PGP signature
Re: VIA PadLock reloaded (fwd from [EMAIL PROTECTED])
From: Michal Ludvig [EMAIL PROTECTED] Subject: Re: VIA PadLock reloaded To: James Morris [EMAIL PROTECTED] Cc: CryptoAPI List [EMAIL PROTECTED] Date: Sun, 24 Oct 2004 01:55:03 +0200 From: Michal Ludvig [EMAIL PROTECTED] Date: Sun, 24 Oct 2004 01:55:03 +0200 To: James Morris [EMAIL PROTECTED] Cc: CryptoAPI List [EMAIL PROTECTED] Subject: Re: VIA PadLock reloaded User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 Michal Ludvig wrote: James Morris wrote: On Sat, 23 Oct 2004, Michal Ludvig wrote: I'm currently updating the driver for VIA PadLock cryptoengine and once I'm on it I'd like to prepare it for kernel inclusion. Have you done any performance measurements with this? It would be interesting to see its effect on IPSec and disk encryption. Yes, some numbers are at http://www.logix.cz/michal/devel/padlock/bench.xp Just in case you have already looked there - few minutes ago I have added a new section with IPsec benchmark. Rough results: Plaintext throughput: 11.21 MB/s IPsec (ESP/transport) without HMAC: - PadLock AES: 11.00 MB/s (keylen independent) - AES-i586: 8.01 to 9.84 MB/s depending on the keylen - Generic C AES: 6.37 to 8.24 MB/s IPsec with HMAC-SHA256: - PadLock AES: 8.06 MB/s - Software AES slower by some 45% than without HMAC. As soon as I get VIA Esther that can do SHA1/SHA256 in hardware I'll update the padlock driver as well. Than I expect almost no slowdown even in HMAC mode (which is almost always used in ESP). Michal Ludvig ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp2BDUwIHk2S.pgp Description: PGP signature
OpenSSL 0.9.7e released (fwd from [EMAIL PROTECTED])
From: Mark J Cox [EMAIL PROTECTED] Subject: OpenSSL 0.9.7e released To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Mon, 25 Oct 2004 14:49:49 +0100 (BST) Reply-To: [EMAIL PROTECTED] From: Mark J Cox [EMAIL PROTECTED] Date: Mon, 25 Oct 2004 14:49:49 +0100 (BST) To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: OpenSSL 0.9.7e released Reply-To: [EMAIL PROTECTED] OpenSSL version 0.9.7e released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.7e of our open source toolkit for SSL/TLS. This new OpenSSL version is a bugfix release and incorporates changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES ). The most significant changes are: o Fix race condition in CRL checking code. o Fixes to PKCS#7 (S/MIME) code. We consider OpenSSL 0.9.7e to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.7e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.7e.tar.gz MD5 checksum: a8777164bca38d84e5eb2b1535223474 The checksums were calculated using the following command: openssl md5 openssl-0.9.7e.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakov Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Lutz JänickeUlf Möller __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpYa6NOSCgEG.pgp Description: PGP signature
pci hardware for secure crypto storage (OpenSSL/OpenBSD)
I'm looking for (cheap, PCI/USB) hardware to store secrets (private key) and support crypto primitives (signing, cert generation). It doesn't have to be fast, but to support loading/copying of secrets in physically secure environments, and not generate nonextractable secret onboard. Environment is OpenBSD/Linux/OpenSSL/gpg. Any suggestions? -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpFez8InSggV.pgp Description: PGP signature
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org) (fwd from touch@ISI.EDU)
From: Joe Touch [EMAIL PROTECTED] Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd frTo: Discussions of anonymous Internet security. [EMAIL PROTECTED] Date: Fri, 10 Sep 2004 09:03:50 -0700 Reply-To: Discussions of anonymous Internet security. [EMAIL PROTECTED] Clarifications below... Eugen Leitl wrote: - Forwarded message from \Hal Finney\ [EMAIL PROTECTED] - From: [EMAIL PROTECTED] (Hal Finney) Date: Thu, 9 Sep 2004 12:57:29 -0700 (PDT) To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: potential new IETF WG on anonymous IPSec The IETF has been discussing setting up a working group for anonymous IPSec. They will have a BOF at the next IETF in DC in November. They're also setting up a mailing list you might be interested in if you haven't heard about it already. ... http://www.postel.org/anonsec To clarify, this is not really anonymous in the usual sense. It does not authenticate the endpoint's identification, other than same place I had been talking to. There's no difference between having no name and having a name you cannot trust. I.e., I could travel under the name anonymous or , or under the name A. Smith. If you don't know whether I am actually A. Smith, the latter is identical to the former. Rather it is a proposal to an extension to IPsec to allow for unauthenticated connections. Correction: it is a proposal to extend Internet security - including Ipsec, but also including TCP-MD5 (sometimes called BGP MD5) and other security mechanisms at various layers. It is not focused only on IPsec. Presently IPsec relies on either pre-shared secrets or a trusted third party CA to authenticate the connection. The new proposal would let connections go forward using a straight Diffie-Hellman type exchange without authentication. This is one option, but not the only one. It also proposes less authentication of IP message packets, covering smaller subsets, as an option. There are two aspects: - smaller portion of the packet is hashed - none of the packet is hashed, but a cookie is used The point has nothing to do with anonymity; The last one, agreed. But the primary assumption is that we can avoid a lot of infrastructure and impediment to deployment by treating an ongoing conversation as a reason to trust an endpoint, rather than a third-party identification. Although anonymous access is not the primary goal, it is a feature of the solution. rather it is an attempt to secure against weaknesses in TCP which have begun to be exploited. Please review the draft; there are a number of reasons this is being considered, not the least of which is to reduce the cumbersome requirement of key infrastructure as well as to avoid performance penalties. Sequence number guessing attacks are more successful today because of increasing bandwidth, and there have been several instances where they have caused disruption on the net. While workarounds are in place, a better solution is desirable. Please be more specific; how would it be better? This new effort is Joe Touch's proposal to weaken IPsec so that it uses less resources and is easier to deploy. He calls the weaker version AnonSec. But it is not anonymous, all the parties know the addresses of their counterparts. Address != identity. Agreed, if what you want to do is hide traffic, this does not provide traffic confidentiality. But it does not tell you whether the packets come from 128.9.x.x (ISI, e.g.) or from someone spoofing 128.9.x.x; all you know is that whoever is using that address is capable of having an ongoing conversation (TCP connection, e.g.) with you. I.e., there are two ways to be anonymous, as noted earlier: 1) don't give out your name (A. Smith, e.g.) 2) give out a name, but it doesn't necessarily mean anything (e.g., Mickey Mouse) Even if you use real names in (2), there's no difference with (1), since you don't know whether the real Mickey Mouse is using it. Rather, it allows for a degree of security on connections between communicators who don't share any secrets or CAs. I don't think anonymous is the right word for this, and I hope the IETF comes up with a better one as they go forward. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - End forwarded message - ___ ___ -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgphSDUxjY0Or.pgp
[wearables] CFP: Workshop on Pervasive Computing and Communication Security (fwd from [EMAIL PROTECTED])
From: Bob Mayo [EMAIL PROTECTED] Subject: [wearables] CFP: Workshop on Pervasive Computing and Communication Security To: [EMAIL PROTECTED] Date: Thu, 2 Sep 2004 16:36:15 -0700 (PDT) Reply-To: [EMAIL PROTECTED] CALL FOR PAPERS PerSec 2005 Second IEEE International Workshop on Pervasive Computing and Communication Security Held in conjunction with IEEE PerCom 2005 8 March 2005, Kauai island, Hawaii, USA http://www.cl.cam.ac.uk/persec-2005/ Research in pervasive computing continues to gain momentum. The importance of security and privacy in a pervasive computing environment cannot be underestimated. PerSec 2005 will bring together the world's experts on this topic and provide an international forum to stimulate and disseminate original research ideas and results in this field. Contributions are solicited in all aspects of security and privacy in pervasive computing, including: Models for access control, authentication and privacy management. Incorporation of contextual information into security and privacy models, and mechanisms. Management of tradeoffs between security, usability, performance, power consumption and other attributes. Architectures and engineering approaches to fit security and privacy features into mobile and wearable devices. Biometric methods for pervasive computing. Descriptions of pilot programs, case studies, applications, and experiments integrating security into pervasive computing. Auditing and forensic information management in pervasive settings. Protocols for trust management in networks for pervasive computing. Incorporation of security into communication protocols, computing architectures and user interface designs for pervasive computing. Impact of security and privacy in relation to the social, legal, educational and economic implications of pervasive computing. INSTRUCTIONS FOR AUTHORS Papers must be sent to persec-2005 at cl.cam.ac.uk as file attachments in Adobe PDF format. Papers must have authors' affiliation and contact information on the first page. Papers must be unpublished and not being considered elsewhere for publication. In particular, papers submitted to PerSec must not be concurrently submitted to PerCom in identical or modified form. Papers must be formatted in strict accordance with the IEEE Computer Society author guidelines published at ftp://pubftp.computer.org/Press/Outgoing/proceedings/INSTRUCT.HTM. For your convenience, templates are available at ftp://pubftp.computer.org/Press/Outgoing/proceedings/. LaTeX is recommended. Papers are limited to 5 pages in IEEE 8.5x11 conference format. Excessively long papers will be returned without review. Papers selected for presentation will be published in the Workshop Proceedings of PerCom 2005 by IEEE Press. IMPORTANT DATES === Paper submission: 13 September 2004 Acceptance Notification: 15 November 2004 Camera-ready manuscripts: 29 November 2004 PerSec Workshop: 8 March 2005 (first day of PerCom, which runs until the 12th) PROGRAM CO-CHAIRS = * Frank Stajano, University of Cambridge, UK * Roshan Thomas, McAfee Research, USA SECRETARY = * Boris Dragovic, University of Cambridge, UK Contact email (goes to co-chairs and secretary): persec-2005 at cl.cam.ac.uk STEERING COMMITTEE CHAIR * Ravi Sandhu, George Mason University, USA PROGRAM COMMITTEE = * Tuomas Aura, Microsoft Research, UK * Mark Corner, UMass, USA * Srini Devadas, MIT, USA * Boris Dragovic, University of Cambridge, UK * Naranker Dulay, Imperial College, UK * Kris Gaj, George Mason University, USA * Robert Grimm, NYU, USA * Dieter Hutter, DFKI, Germany * Ari Juels, RSA Laboratories, USA * Tim Kindberg, HP Labs Bristol, UK * Cetin Kaya Koc, Oregon State University, USA * Marc Langheinrich, ETH Zurich, Switzerland * Mark Lomas, BIICL, UK * Robert N. Mayo, HP Labs Palo Alto, USA * Refik Molva, Eurecom, France * Kai Rannenberg, University of Frankfurt, Germany * Stephen Weis, MIT -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpGBv9c4Gh1h.pgp Description: PGP signature
Re: EZ Pass and the fast lane ....
On Sun, Jul 11, 2004 at 10:39:18AM +0200, Amir Herzberg wrote: So I think this observation about EZ Pass is probably true, but for some time ago; with current technology, reading license plates is possible (which, I guess, has some alarming privacy implications...). While Toll Collect (the german system) isn't yet operational, the license plate realtime OCR part is. It does read license plates in realtime via video from overhead bridges, no slowing down necessary. The police is very interested to keep that part of the infrastructure operational, for obvious reasons. Currently, all non-truck license plates are discarded, but it's clear enough theres demand for realtime tracing of select and movement profiles for the masses, for data mining. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgppD15jCtboO.pgp Description: PGP signature
Interview with Glenn Henry, founder of VIA processor subsidiary Centaur (fwd from [EMAIL PROTECTED])
From: Eugen Leitl [EMAIL PROTECTED] Subject: Interview with Glenn Henry, founder of VIA processor subsidiary CeTo: [EMAIL PROTECTED] Date: Tue, 15 Jun 2004 18:51:21 +0200 http://linuxdevices.com/articles/AT2656883479.html [ker-snip] The third one, is one you haven't asked me about, this is actually my pet hobby, here -- we've added these fully sophisticated and very powerful security instructions into the... Q19: That was my last question! A19: So the classic question is, hey, you built some hardware, who's going to use it? Well, the answer is, six months after we first started shipping our product with encryption in it [story], we have three or four operating systems, including Linux, OpenBSD, and FreeBSD, directly supporting our security features in the kernel. Getting support that quickly can't happen in the Microsoft world. Maybe they'll support it someday, maybe they won't. Quite honestly, if you want to build it, and hope that someone will come, you've got to count on something like the free software world. Free software makes it very easy for people to add functionality. You've got extremely talented, motivated people in the free software world who, if they think it's right to do it, will do it. That was my strategy with security. We didn't have to justify it, because it's my hobby, so we did it. But, it would have been hard to justify these new hardware things without a software plan. My theory was simple: if we do it, and we do it right, it will appeal to the really knowledgeable security guys, most of whom live in the free software world. And those guys, if they like it, and see it's right, then they will support it. And they have the wherewithal to support it, because of the way open software works. So those are my three themes, ignoring the fourth one, that's obvious: that without competition, Windows would cost even more. To summarize, for our business, [Linux is] important because it allows us to build lower-cost PC platforms, it allows people to build new, more sophisticated embedded applications easier, and it allows us, without any software costs, to add new features that we think are important to the world. Our next processor -- I haven't ever told anyone, so I won't say what it is -- but our next processor has even more things in it that I think will be just as quickly adopted by the open source software world, and provide even more value. It's always bothered me that hardware can do so many things relatively easily and fast that aren't done today because there's no software to support it. We just decided to try to break the mold. We were going to do hardware that, literally, had no software support at the start. And now the software is there, in several variations, and people are starting to use it. I actually think that's only going to happen in the open source world. Q20: We'd like a few words from you about your security strategy, how you've been putting security in the chips, and so on. A20: Securing one's information and data is sort of fundamental to the human need -- it's certainly fundamental to business needs. With the current world, in which everyone's attached to the Internet -- with most peoples' machines having back-door holes in them, whether they know it or not -- and with all the wireless stuff going on, people's data, whether they know it or not, is relatively insecure. The people who know that are using secure operating systems, and they're encrypting their data. Encrypting of data's been around for a long time. We believe, though, that this should be a pervasive thing that should appear on all platforms, and should be built into all things. It turns out, though, that security features are all computationally intensive. That's what they do. They take the bits and grind them up using computations, in a way that makes it hard to un-grind them. So, we said, they're a perfect candidate for hardware. They're well-defined, they're not very big, they run much faster in hardware than in software -- 10 to 30 times, in the examples we use. And, they are so fundamental, that we should add the basic primitives to our processor. How did we know what to add? We added government standards. The U.S. government has done extensive work on standardizing the encryption protocols, secure digital signature protocols, secure hash protocols. We used the most modern of government standards, built the basic functions into our chip, and did it in such a way that made it very easy for software to use. Every time you send an email, every time you send a file to someone, that data should be encrypted. It's going out on the Internet, where anyone with half a brain can steal it. Second, if you really care about not letting people have access to certain data that's on your hard drive, it ought to be encrypted, because half the PCs these days have some, I don't know what the right word is, some spy built into it, through a virus or worm, that can steal data and pass it back. You'll
Re: Article on passwords in Wired News
On Thu, Jun 03, 2004 at 08:14:39PM +1200, Peter Gutmann wrote: One-time passwords (TANs) was another thing I covered in the Why isn't the Internet secure yet, dammit! talk I mentioned here a few days ago. From talking to assorted (non-European) banks, I haven't been able to find any that Customers hate PINs/TANs (have to carry then around, PINs typically are not alphanumeric, and fixed-length, print is low-contrast). Which is why power users have a (Windows-only, for some reason couldn't get GNUcash working, despite right crypto libraries and proper port punched through firewall) HBCI software alternatives. Which are not used widely, alas. Banks tried to push smart cards, but very half-heartedly (didn't offer free readers, which could have created critical mass). Now some folks are trying to use existing smartcard-authenticated mobile phone infrastructure for online payments, but it has its own problems (Bluetooth/IrDa, security, fax effect, etc). -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpp37oZjAHGy.pgp Description: PGP signature
Re: The future of security
On Mon, May 31, 2004 at 08:27:49PM -0700, bear wrote: The point of an automated web of trust is that the machine is doing the accounting for you. Does it? If there were meaningful reputation accounting You got fooled by the present tense. If there was such an architecture, I wouldn't have written that message. The distributed tamper-proof cryptographic p2p store should have been a dead giveaway. happening, we'd be getting feedback and value judgements from the system on the people we were corresponding with. Have you ever seen any? No, of course. See above. Has there been *ANY* instance of negative consequences accruing to someone who signed the key of an entity which later defected? Machine-moderated or not, the web of trust fails. The web of trust sure fails, dunno about machine-moderated. There's no such animal yet. Have you seen any web-of-trust implementation that even *considers* the trustworthiness of the key servers? Have you seen any web-of-trust implementation that works to cut out defectors, but couldn't be autospammed to cut out anyone you didn't like? If you don't have their key, you can't pretend to sign the spambots'. If you sign the spambots', you burn whatever little prestige you have happened to start out with, and drained the mana of whatever hapless warm body signed your keys. Sorry; but the fact is no web-of-trust implementation to date works, or even comes close to working. Web of trust is useless, if Johnny User is supposed to do the checking. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpPzt821GHi8.pgp Description: PGP signature
Re: The future of security
On Fri, May 28, 2004 at 09:46:03AM -0700, bear wrote: Spam won't stop until spam costs the spammers money. If I'm a node in a web of trust (FOAF is a human), prestige will percolate through it completely. That way I can color a whole domain with a nonboolean trust hue, while a domain of fakers will have only very few connections (through compromises, or human mistakes), which will rapidly sealed, once actually used to do something to lower their prestige (I signed the key of a spammer, please kill me now). Of course, tracking prestige globally, robustly in a p2p fashion is difficult, and will require agoric load levelling elements (to prevent bad nodes from DoSing the global store) which also requires prestige tracking. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpnR1gxzugWi.pgp Description: PGP signature
Re: Satellite eavesdropping of 802.11b traffic
On Fri, May 28, 2004 at 01:19:15PM -0500, Matt Crawford wrote: Don't dismiss possibilities for wireless data eavesdropping without considering the possibilities of this new chip http://pr.caltech.edu/media/Press_Releases/PR12490.html and its friends http://www.chic.caltech.edu/ If you want to fly a LEO constellation of them, you need a very sparse structure (or a huge density of pongsats, which doesn't agree with observations). -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpjSdYUSaXAn.pgp Description: PGP signature
XML-proof UIDs
Does anyone have robust code to generate globally unique IDs which won't break XML parsing, and work on several platforms? I was thinking of using an entropy pool to seed a cryptographic PRNG, used to generate a sequence of SHA-1 hashes, dumped to an XML-armored representation. Thanks. -- 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 pgp0.pgp Description: PGP signature
