[cryptography] [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
- Forwarded message from Andrew Miller amil...@cs.umd.edu - Date: Mon, 2 Mar 2015 11:48:24 -0500 From: Andrew Miller amil...@cs.umd.edu To: bitcoin-developm...@lists.sourceforge.net Subject: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies Message-ID: CAF7tpEyHyg7cB8DQiwb-gGg5v5Hn1Kurw2GaVtid=lyjrb1...@mail.gmail.com We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have written a “systemization” paper about Bitcoin-related research. It’s going to appear in the Oakland security conference later this year (IEEE Security and Privacy) but we wanted to announce a draft to this community ahead of time. http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf One of the main goals of our work is to build a bridge between the computer science research community and the cryptocurrency community. Many of the most interesting ideas and proposals for Bitcoin come from this mailing list and forums/wikis/irc channels, where many academic researchers simply don’t know to look! In fact, we started out by scraping all the interesting posts/articles we could find and trying to figure out how we could organize them. We hope our paper helps some of the best ideas and research questions from the Bitcoin community bubble up and inspires researchers to build on them. We didn’t limit our scope to Bitcoin, but we also decided not to provide a complete survey of altcoins and other next-generation cryptocurrency designs. Instead, we tried to explain all the dimensions along which these designs differ from Bitcoin. This effort has roughly been in progress over two years, though it stopped and restarted several times along the way. If anyone has comments or suggestions, we still have a week before the final version is due, and regardless we plan to continue updating our online version for the forseeable future. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list bitcoin-developm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development - End forwarded message - ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] hashes based on lots of concatenated LUT lookups
It's hard to make a cryptocurrency hash that's ASICproof. Cheap/multisource serve/PC COTS hardware has large memory size, and intrinsic random access latencies that can't be much improved upon for physical reasons (embedded memory is limited in size due to die yield reasons, so large LUTs are always much slower than embedded memory). As such any hash that needs lots of serial/concatenated lookups on large (several GByte), random (same preparation as one-time pads) memory-locked LUTs to compute is ASIC/FPGA/GPU-proof since it can't be parallized without replicating the expensive LUT. Dedicated hardware LUT doesn't have price advantages over COTS-based LUT, though at very large scales LUTs requiring no refresh are more energy-efficient. LUT size can be variable to track technology improvements. Distribution of several GByte LUT across participating nodes is not too difficult with P2P protocols (Bittorrent Co) as it only happens once on bootstrap. Memory-bound code, especially if run at low priority does not make end user all-purpose (ASIC is intrinsically special-purpose) hardware unusable for other tasks the way GPU mining is. How would you construct such a hash? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Lawyer: Are you familiar with public key encryption? -- Whitfield Diffie: Yes, I am
http://arstechnica.com/tech-policy/2013/11/newegg-trial-crypto-legend-diffie-takes-the-stand-to-knock-out-patent/ Newegg trial: Crypto legend takes the stand, goes for knockout patent punch Taking a bet on Whit Diffie, as the trial against patent troll TQP wraps up Monday. by Joe Mullin - Nov 25 2013, 6:58am WEST Whitfield Diffie and Newegg lawyer Alan Albright, outside the federal courthouse is Marshall, Texas. Joe Mullin Newegg’s chief counsel testifies: 30 infringement claims in last 8 years alone Newegg on trial: Mystery company TQP rewrites the history of encryption Newegg on trial, day one: Picking a patent jury Newegg hurtles toward Texas showdown with famed “patent troll” MARSHALL, TX—Newegg's courtroom face-off with patent-licensing giant TQP Development is nearing its end. TQP has sued hundreds of companies saying it has patented the common Web encryption scheme of combining SSL with the RC4 cipher. Almost 140 companies have paid TQP a total of more than $45 million. But online retailer Newegg, which has sworn not to settle with patent trolls like TQP, took the case to a jury. On Thursday, Newegg's top lawyer Lee Cheng took the stand. He was followed by a non-infringement expert and three well-known computer scientists who emphasized the importance of Newegg's prior art. Ron Rivest testified, via videotaped deposition, about how he invented the RC4 cipher while at RSA Security in 1987, two years before the TQP patent application was filed. Former Microsoft CTO Ray Ozzie described demonstrating Lotus Notes to Bill Gates in 1988. Alan Eldridge, who worked on the Notes product, flew down to Marshall in person to describe how he put RC4 in the software. Eldridge wasn't paid, as expert witnesses were—he came down to testify against the Jones patent out of a feeling of civic responsibility, he said. He didn't know who the defendants in this case were until he was told. I hadn't even heard of New Age until Saturday, said Eldridge at one point, as laughs were stifled in the courtroom. On Friday Newegg's star witness, cryptographer Whitfield Diffie, took the stand. Diffie's goal is to knock out the Jones patent with clear and convincing evidence (which is the standard for invalidating a patent). Diffie looked the part of the eccentric genius, resplendent with his long white hair and beard. He spoke with a booming voice but carefully articulated manner; he was professorial but not overbearing. He could have been the amiable professor you wish you'd had in college. TQP's patent, invented alongside Michael Jones' failed modem business, wasn't much of an invention at all according to Diffie's telling. It was a pre-Internet patent, describing an old method of encoding data. Internet security needed public key cryptography. We've heard a good bit in this courtroom about public key encryption, said Albright. Are you familiar with that? Yes, I am, said Diffie, in what surely qualified as the biggest understatement of the trial. And how is it that you're familiar with public key encryption? I invented it. A brief history of public-key crypto In 1973, Diffie left his work at Stanford's Artificial Intelligence Lab to travel the country and learn more about cryptography. It was kind of a secret field at the time, and the literature was hard to find, said Diffie. I was traveling around academic libraries digging up whatever I could. The following year, he returned to Stanford and started his work with a professor there, Martin Hellman. I want you to put it in perspective for the court and for the jury, said Albright. What is the problem that you two gentlemen saw, that you were so worried about? The problem was vast, Diffie explained—nothing less than how to keep things private in a networked world. He recalled a conversation with his wife in 1973, sitting on a New Jersey park bench. I told her that we were headed into a world where people would have important, intimate, long-term relationships with people they had never met face to face, he said. I was worried about privacy in that world, and that's why I was working on cryptography. At that time, the only encryption happened within closed systems. IBM could encrypt information within its own company's networks, and Texas Instruments could encrypt on theirs. But some kind of courier would have to carry encryption keys to both companies before they could do so. That was the key distribution problem Diffie strove to solve. It's arranging to provide keys to two people who have never met before, who suddenly find themselves with a need to communicate, he explained. This is much the way we visit websites these days. There was one other big need: proving authenticity. The receiver of the document can come into court with the signed document and prove to a judge that the document is legitimate, he said. That person can recognize the signature but could not have created the signature. In spring of 1975, Diffie was playing house husband near
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
- Forwarded message from Pawel Jakub Dawidek p...@freebsd.org - Date: Sat, 19 Oct 2013 13:26:08 +0200 From: Pawel Jakub Dawidek p...@freebsd.org To: z...@lists.illumos.org Subject: Re: [zfs] [Review] 4185 New hash algorithm support Message-ID: 20131019112608.gf1...@garage.freebsd.pl User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: z...@lists.illumos.org On Mon, Oct 07, 2013 at 11:18:21PM +0100, Saso Kiselkov wrote: On 10/7/13 10:17 PM, Zooko Wilcox-OHearn wrote: So, before I go on with my pitch for why you should consider BLAKE2, first please clarify for me whether ZFS really needs a collision-resistant hash function, or whether it needs only a MAC. I had thought until now that ZFS doesn't need a collision-resistant hash unless dedup is turned on, and that if dedup is turned on it needs a collision-resistant hash. The reason is purely for dedup and pretty much nothing else. As such, we only need a hash with a good pseudo-random output distribution and collision resistance. We don't specifically need it to be super-secure. The salted hashing support I added was simply to silence the endless stream of wild hypotheticals on security. Just FYI, Richard Yao just proposed providing VM images with existing ZFS pool also for production use. This is great idea, but also a nice proof why making assumptions on how exactly a general purpose software will be used is bad. In this case your salted hashing is pointless as everyone knows about the salt in those images. And we are back to square one. Saso, there are countless examples where so called hypothetical security bugs turned out to be exploitable in practise. Which is especially true for general purpose software that we have no control over how it is being used. As Zooko mentioned cryptoanalysis of the Edon-R algorithm stopped at the point where we know it is not cryptographically secure and this is unlikely we will see any further work in the subject, which in my eyes is even worse, as we don't know how bad is it. To sum up. Even if the OpenZFS community will agree to integrate Edon-R, I'll strongly oppose having it in FreeBSD. In my opinion it is just asking for trouble. I still like your change very much and would love to see new, cryptographically secure hash algorithms for dedup in ZFS. Currently there is no alternative, which is bad for security too. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Cryptographer Adi Shamir Prevented from Attending NSA History Conference
http://blogs.fas.org/secrecy/2013/10/shamir/ Cryptographer Adi Shamir Prevented from Attending NSA History Conference Categories: Science, Secrecy In this email message to colleagues, Israeli cryptographer Adi Shamir recounts the difficulties he faced in getting a visa to attend the 2013 Cryptologic History Symposium sponsored by the National Security Agency. Adi Shamir is the “S” in the RSA public-key algorithm and is “one of the finest cryptologists in the world today,” according to historian David Kahn. The NSA Symposium begins tomorrow. For the reasons described below, Dr. Shamir will not be there. From: Adi Shamir Date: October 15, 2013 12:16:28 AM EDT To: Subject: A personal apology The purpose of this email is to explain why I will not be able to attend the forthcoming meeting of the History of Cryptology conference, even though I submitted a paper which was formally accepted. As an active participant in the exciting developments in academic cryptography in the last 35 years, I thought that it would be a wonderful opportunity to meet all of you, but unfortunately the US bureaucracy has made this impossible. The story is too long to describe in detail, so I will only provide its main highlights here. I planned to visit the US for several months, in order to attend the Crypto 2013 conference, the History of Cryptology conference, and to visit several universities and research institutes in between in order to meet colleagues and give scientific lectures. To do all of these, I needed a new J1 visa, and I filed the visa application at the beginning of June, two and a half months before my planned departure to the Crypto conference in mid August. I applied so early since it was really important for me to attend the Crypto conference – I was one of the founders of this flagship annual academic event (I actually gave the opening talk in the first session of the first meeting of this conference in 1981) and I did my best to attend all its meetings in the last 32 years. To make a long story short, after applying some pressure and pulling a lot of strings, I finally got the visa stamped in my passport on September 30-th, exactly four months after filing my application, and way beyond the requested start date of my visit. I was lucky in some sense, since on the next day the US government went into shutdown, and I have no idea how this could have affected my case. Needless to say, the long uncertainty had put all my travel plans (flights, accomodations, lecture commitments, etc) into total disarray. It turns out that I am not alone, and many foreign scientists are now facing the same situation. Here is what the president of the Weizmann Institute of Science (where I work in Israel) wrote in July 2013 to the US Ambassador in Israel: “I’m allowing myself to write you again, on the same topic, and related to the major difficulties the scientists of the Weizmann Institute of Science are experiencing in order to get Visa to the US. In my humble opinion, we are heading toward a disaster, and I have heard many people, among them our top scientists, saying that they are not willing anymore to visit the US, and collaborate with American scientists, because of the difficulties. It is clear that scientists have been singled out, since I hear that other ‘simple citizen’, do get their visa in a short time.” Even the president of the US National Academy of Science (of which I am a member) tried to intervene, without results. He was very sympathetic, writing to me at some stage: “Dear Professor Shamir I have been hoping, day by day, that your visa had come through. It is very disappointing to receive your latest report. We continue to try by seeking extra attention from the U. S. Department of State, which has the sole authority in these matters. As you know, the officers of the Department of State in embassies around the world also have much authority. I am personally very sympathetic and hopeful that your efforts and patience will still yield results but also realize that this episode has been very trying. We hope to hear of a last-minute success. Yours sincerely, Ralph J. Cicerone” What does all of this have to do with the History of Cryptology conference? In January 2013 I submitted a paper titled “The Cryptology of John Nash From a Modern Perspective” to the conference, and a short time afterwards I was told by the organizers that it was accepted. In July 2013 I told the NSA-affiliated conference organizers that I was having some problems in getting my visa, and gently asked whether they could do something about it. Always eager to help, the NSA people leaped into action, and immediately sent me a short email written with a lot of tact: “The trouble you are having is regrettable…Sorry you won’t be able to come to our conference. We have submitted our program and did not include you on it.” I must admit that in my 35 years of attending many conferences, it had never happened to me that an accepted paper
[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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Cryptographers condemn US National Security Agency’s tapping and tampering, but mathematicians shrug.
http://www.nature.com/news/researchers-split-over-nsa-hacking-1.13911 Researchers split over NSA hacking Cryptographers condemn US National Security Agency’s tapping and tampering, but mathematicians shrug. Ann Finkbeiner 08 October 2013 The National Security Agency is the largest employer of mathematicians in the United States. PATRICK SEMANSKY/ASSOCIATED PRESS The US National Security Agency (NSA) has upset a great many people this year. Since June, newspapers have been using documents leaked by former intelligence worker Edward Snowden to show how the secretive but powerful agency has spied on the communications of US citizens and foreign governments. Last month, the media reported that the NSA, which is based in Fort Meade, Maryland, had undermined Internet security standards. The revelations have sparked international outrage at the highest levels — even the president of Brazil cancelled a visit to the United States because of the spying. Yet amid the uproar, NSA-supported mathematicians and computer scientists have remained mostly quiet, to the growing frustration of others in similar fields. “Most have never met a funding source they do not like,” says Phillip Rogaway, a computer scientist at the University of California, Davis, who has sworn not to accept NSA funding and is critical of other researchers’ silence. “And most of us have little sense of social responsibility.” Mathematicians and the NSA are certainly interdependent. The agency declares that it is the United States’ largest maths employer, and Samuel Rankin, director of the Washington DC office of the American Mathematical Society, estimates that the agency hires 30–40 mathematicians every year. The NSA routinely holds job fairs on university campuses, and academic researchers can work at the agency on sabbaticals. In 2013, the agency’s mathematical sciences programme offered more than US$3.3 million in research grants. Furthermore, the NSA has designated more than 150 colleges and universities as centres of excellence, which qualifies students and faculty members for extra support. It can also fund research indirectly through other agencies, and so the total amount of support may be much higher. A leaked budget document says that the NSA spends more than $400 million a year on research and technology — although only a fraction of this money might go to research outside the agency itself. “I understand what’s in the newspapers, but the NSA is funding serious long-term fundamental research and I’m happy they’re doing it.” Many US researchers, especially those towards the basic-research end of the spectrum, are comfortable with the NSA’s need for their expertise. Christopher Monroe, a physicist at the University of Maryland in College Park, is among them. He previously had an NSA grant for basic research on controlling cold atoms, which can form the basis of the qubits of information in quantum computers. He notes that he is free to publish in the open literature, and he has no problems with the NSA research facilities in physical sciences, telecommunications and languages that sit on his campus. Monroe is sympathetic to the NSA’s need to track the development of quantum computers that could one day be used to crack codes beyond the ability of conventional machines. “I understand what’s in the newspapers,” he says, “but the NSA is funding serious long-term fundamental research and I’m happy they’re doing it.” Dena Tsamitis, director of education, outreach and training at Carnegie Mellon University’s cybersecurity research centre in Pittsburgh, Pennsylvania, also wants to maintain the relationship. She oversees visitors and recruiters from the NSA but her centre gets no direct funding. She says that her graduate students understand the NSA’s public surveillance to be “a policy decision, not a technology decision. Our students are most interested in the technology.” And the NSA, she says — echoing many other researchers — “has very interesting technology problems”. The academics who are professionally uneasy with the NSA tend to lie on the applied end of the spectrum: they work on computer security and cryptography rather than pure mathematics and basic physics. Matthew Green, a cryptographer at Johns Hopkins University in Baltimore, Maryland, says that these researchers are unsettled in part because they are dependent on protocols developed by the US National Institute of Standards and Technology (NIST) to govern most encrypted web traffic. When it was revealed that the NSA had inserted a ‘back door’ into the NIST standards to allow snooping, some of them felt betrayed. “We certainly had no idea that they were tampering with products or standards,” says Green. He is one of 47 technologists who on 4 October sent a letter to the director of a group created last month by US President Barack Obama to review NSA practices, protesting because the group does not include any independent technologists. Edward Felten, who studies
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
--- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [zfs] [Review] 4185 New hash algorithm support
) Skein1024/1024 16864123 us (39.15 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: Skein_256/256 Message: test_msg0 Result: OK Skein_256/256 Message: test_msg1 Result: OK Skein_256/256 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg0 Result: OK Skein_512/512 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg0 Result: OK Skein1024/1024 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg4 Result: OK Running performance tests (hashing 1024 MiB of data): Skein_256/256 3328342 us (7.73 CPB) Skein_512/512 2549537 us (5.92 CPB) Skein1024/1024 3547695 us (8.24 CPB) Building 32-bit test... Running 32-bit test... Running algorithm correctness tests: SHA256 Message: test_msg0 Result: OK SHA256 Message: test_msg1 Result: OK SHA384 Message: test_msg0 Result: OK SHA384 Message: test_msg2 Result: OK SHA512 Message: test_msg0 Result: OK SHA512 Message: test_msg2 Result: OK SHA512_224 Message: test_msg0 Result: OK SHA512_224 Message: test_msg2 Result: OK SHA512_256 Message: test_msg0 Result: OK SHA512_256 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): SHA256 6745601 us (15.66 CPB) SHA512 19033518 us (44.19 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: SHA256 Message: test_msg0 Result: OK SHA256 Message: test_msg1 Result: OK SHA384 Message: test_msg0 Result: OK SHA384 Message: test_msg2 Result: OK SHA512 Message: test_msg0 Result: OK SHA512 Message: test_msg2 Result: OK SHA512_224 Message: test_msg0 Result: OK SHA512_224 Message: test_msg2 Result: OK SHA512_256 Message: test_msg0 Result: OK SHA512_256 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): SHA256 4551774 us (10.57 CPB) SHA512 3029591 us (7.03 CPB) --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
- Forwarded message from Pawel Jakub Dawidek p...@freebsd.org -
Date: Mon, 7 Oct 2013 11:44:57 +0200
From: Pawel Jakub Dawidek p...@freebsd.org
To: z...@lists.illumos.org
Subject: Re: [zfs] [Review] 4185 New hash algorithm support
Message-ID: 20131007094456.gb1...@garage.freebsd.pl
User-Agent: Mutt/1.5.21 (2010-09-15)
Reply-To: z...@lists.illumos.org
On Mon, Oct 07, 2013 at 12:47:52AM +0100, Saso Kiselkov wrote:
Please review what frankly has become a bit of a large-ish feature:
http://cr.illumos.org/~webrev/skiselkov/new_hashes/
This webrev implements new hash algorithms for ZFS with much improved
performance. There are three algorithms included:
* SHA-512/256: truncated version of SHA-512 per FIPS 180-4. Uses
all existing code from the sha2 module (with new H(0) consts),
but the native 64-bit arithmetic used in SHA-512 provides a
~50% performance boost relative to SHA-256 on 64-bit hardware.
* Skein-512: 80% faster than SHA-256 in optimized C implementation,
and a very high security margin (Skein was a finalist in SHA-3).
Also includes a KCF SW provider.
* Edon-R-512: 350% faster than SHA-256 in optimized C implementation.
Security margin lower than Skein.
To address any security concerns associated with using new algorithms
this patch also implements salted checksum support. We store a random
256-bit secret key (the salt) in the MOS and use it to pre-seed the hash
algorithms (Skein and Edon-R use this, SHA-512/256 is just a straight
hash). Any attacker thus cannot simply mount a collision attack on the
algorithm, since they can't completely control the input.
I do like your patch and addition of first two algorithms, but I have to
comment on the third one.
By adding a salt to Edon-R-512 you assume that prerequisite to creating
collision is guessing the entire salt, so having 256bit salt makes it
safe. I'd say this is brave assumption. We (at least I) don't know how
this algorithm treats those first 256 bits. Maybe for large blocks some
(most?) of the salt enropy is lost? If we think Edon-R-512 is not
cryptographically secure, making any assumptions that weren't properly
analysed comes at too high risk, IMHO.
You are also calling your salting method being a MAC, where we do have
well-known and secure MAC algorithms that are based on hash functions
(ie. HMAC).
Personally I'd love to have an option to use HMAC/SHA256 for example
with secret key stored in pool. Currently in our product we put ZFS with
SHA256 on top of block-level disk encryption. I'd feel much better to
have proper data authentication using HMAC. At some point I may find
time to implement that based on your patch.
Do we want to allow to use different algorithms for using deduplication
within send/recv streams? I think SHA256 is now hardcoded?
It can of course be implemented separately, just wondering.
Few minor observations:
--- old/usr/src/lib/libzfs/common/libzfs_dataset.c Mon Oct 7 09:23:07 2013
+++ new/usr/src/lib/libzfs/common/libzfs_dataset.c Mon Oct 7 09:23:07 2013
@@ -1377,6 +1377,12 @@
property setting is not allowed on
bootable datasets));
(void) zfs_error(hdl, EZFS_NOTSUP, errbuf);
+ } else if (prop == ZFS_PROP_CHECKSUM ||
+ prop == ZFS_PROP_DEDUP) {
+ (void) zfs_error_aux(hdl, dgettext(TEXT_DOMAIN,
+ property setting is not allowed on
+ root pools));
+ (void) zfs_error(hdl, EZFS_NOTSUP, errbuf);
} else {
(void) zfs_standard_error(hdl, err, errbuf);
}
When I read this change it looks like we don't allow to change checksum
property on root pools at all?
--- /dev/null Mon Oct 7 09:23:09 2013
+++ new/usr/src/uts/common/fs/zfs/edonr_zfs.c Mon Oct 7 09:23:09 2013
[...]
+void *
+zio_checksum_edonr_tmpl_init(const zio_cksum_salt_t *salt)
+{
[...]
+ /*LINTED E_TRUE_LOGICAL_EXPR*/
+ ASSERT(EDONR_BLOCK_SIZE == 2 * (EDONR_MODE / 8));
There is CTASSERT() macro in FreeBSD that can be used for checks like
that, which generates compile-time error if it isn't true.
+ ctx = kmem_zalloc(sizeof (*ctx), KM_SLEEP);
For Skein you also use KM_PUSHPAGE flag.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
---
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f
Modify Your Subscription:
https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366
Powered by Listbox: http://www.listbox.com
- End forwarded message -
--
Eugen* Leitl a href=http
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [zfs] [Review] 4185 New hash algorithm support
- Forwarded message from Zooko Wilcox-OHearn zo...@leastauthority.com - Date: Mon, 7 Oct 2013 21:17:14 + From: Zooko Wilcox-OHearn zo...@leastauthority.com To: z...@lists.illumos.org Subject: [zfs] [Review] 4185 New hash algorithm support Message-ID: cam_a8jxvey4lnhmmxfzafwofgn0z0kxlkentcvrhq_mog48...@mail.gmail.com Reply-To: z...@lists.illumos.org Hi folks: I just joined this list because I saw this thread. I'm one of the architects of a distributed storage system named Tahoe-LAFS (https://Tahoe-LAFS.org). It has quite a few things in common with ZFS, architecturally, but it is also very different from ZFS, because it's not so much a real *filesystem* as it is like a BitTorrent that has an upload button as well as a download button. But it is like ZFS inasmuch as they both involve a heck of a lot of hashing for error-detection. I'm also an author of a secure hash function which has been designed for this kind of usage and which you should consider as an alternative to SHA-256, Edon-R, or Skein for use in ZFS. It is named BLAKE2. Here are the slides I presented about BLAKE2 at a recent academic crypto conference: ¹. ¹ https://blake2.net/acns/slides.html The slides mention ZFS. ZFS is mentioned on a slide with a list of tools that use secure hash functions for data-intensive purposes. Out of the list there, Tahoe-LAFS and ZFS are the only ones that use a hash function which is actually secure — SHA-256. The others all use hash functions that are known to be more or less unsafe — MD5 and SHA-1. So, before I go on with my pitch for why you should consider BLAKE2, first please clarify for me whether ZFS really needs a collision-resistant hash function, or whether it needs only a MAC. I had thought until now that ZFS doesn't need a collision-resistant hash unless dedup is turned on, and that if dedup is turned on it needs a collision-resistant hash. But this thread seems to indicate that even when dedup is turned on, it might be possible to use a MAC, by having a pool-wide secret to use for the MAC key… If I understand correctly (which I probably don't), that would make it impossible for anyone who doesn't know the secret to cause collisions during dedup, but still possible for someone who knows the secret (presumably root on that system, or someone who stole the secret) to generate blocks that would collide during dedup. If you used a collision-resistant hash for that purpose, then nobody would be able to cause collisions. If you need a MAC, I suggest Poly1305-AES. It is very efficient, has a nice proof that it is as secure as AES is, and it is part of a new proposed cipher suite for TLS ². ² http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01 If you need a collision-resistant hash function, I suggest BLAKE2. It is more efficient than SHA-256, Skein, or Keccak (see ³), and it has a better reputation among cryptographers than Edon-R has. In fact, BLAKE2's parent, BLAKE, was rated by NIST as being even more well-studied than Keccak was — see my slides, linked above, for quotes from NIST's final report on the SHA-3 contest. ³ http://bench.cr.yp.to/results-hash.html#amd64-hydra8 I get the impression that BLAKE2 has gotten a certain mind-share among cryptographers, because after this article ⁴ from the Center for Democracy and Technology came out, questioning NIST's plans to modify SHA-3 to improve its performance, there has been a heated discussion on the SHA-3 mailing list, and several of the cryptographers in that discussion (including the inventors of Keccak) have mentioned BLAKE2 as an example of a high-performance hash function. There has been one academic research paper analyzing BLAKE2 so far: ⁵ (in addition to a ton of them analyzing its predecessor, BLAKE, during the SHA-3 contest). ⁴ https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3 ⁵ http://eprint.iacr.org/2013/467 In addition to being high-performance in normal single-stream mode, BLAKE2 comes with parallelized modes, so that you can use 4 or 8 CPU cores to compute a hash up to 4- or 8- times as fast. You can get the academic papers, source code (both simple reference implementations and optimized implementations in various languages), test vectors, and so on: https://blake2.net Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - 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
Re: [cryptography] The Compromised Internet
On Wed, Sep 25, 2013 at 08:12:16PM -0400, grarpamp wrote: The US only applies to itself. Further, over the air, it's noise, the crypto is undetectable and unprovable. And it's (guerilla) software, not physical commercial product. Nor is this the old 'FCC says you can't encrypt ham bands' argument/tech. I don't see how a ham running a repeater backbone can prevent end to end encryption other than sniffing for traffic and actively disrupting it. I'm not sure tampering with transport is within ham ethics, though they definitely don't understand the actual uses for encryption, at least the old hands (are there even new hands?). Not a ham nor IANAL, so this is speculation. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] What the heck is going on with NIST’s cryptographic standard, SHA-3?
https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3 What the heck is going on with NIST’s cryptographic standard, SHA-3? by Joseph Lorenzo Hall [1] September 24, 2013 (Warning: this is a fairly technical post about cryptographic standards setting.) The cryptographic community has been deeply shaken since revelations earlier this month [2] that the National Security Agency (NSA) has been using a number of underhanded methods – stealing encryption keys, subverting standards setting processes, planting backdoors in products – to undermine much of the encryption used online. This includes crucial pieces of e-commerce like HTTPS (SSL/TLS) and Virtual Private Networks (VPN) that we use each day to purchase things online, to socialize in private, and that businesses use to communicate confidential and proprietary information. While the reporting has been vague and hasn’t pointed to specific software versions or protocols that have been compromised, last week RSA Security – a major supplier of cryptographic software and hardware – initiated a product recall [3] of sorts, warning users that one of its popular software encryption products contained a likely NSA-planted backdoor. The practical implication of the RSA recall is that much of the encryption that used this product since 2007 isn’t nearly as secure as it was supposed to be. Those of us who follow developments in the cryptographic community have noticed another troubling development: there are a number of cryptographers upset with how the National Institute of Standards and Technology (NIST) is standardizing a new set of encryption algorithms called SHA-3 (which stands for the third version of the Secure Hashing Algorithm). The remainder of this post explains what is going on with SHA-3 and how NIST could diffuse this particular controversy while it still has the chance. (Warning: In this post, I’m assuming the reader is familiar with the concepts underlying basic encryption tools, called “cryptographic primitives,” such as hash functions [4], digital signatures [5], and message authentication codes [6].) What is SHA-3? SHA-3 is the “next generation” hash algorithm being standardized by NIST. In 2005, researchers developed an attack [7] that called into question the security guarantees of an earlier secure hash algorithm, SHA-1. The characteristics of this 2005 attack seemed to hint that it could be refined to attack many of the secure hash functions at the time, including SHA-0, MD4, MD5 and even SHA-2. At the time, for many cryptographers, the message was clear: a new hash algorithm is needed and it should be based on completely different underlying mathematics that are not susceptible to the attacks threatening known hash functions. To be clear: SHA-1 is thought to be on its way out, as people expect the earlier attacks to be improved considerably in the coming years and there hasn’t been any result that calls into question the soundness of SHA-2 at all. Attacks always improve, so it’s imperative that there is an alternative hash function ready to go when and if the floor falls out of the earlier hash functions. NIST’s cryptographic technology group [8] is world-renowned for cryptographic algorithm standardization. In 2007, NIST began the process to develop and standardize a new secure hash algorithm that would be called SHA-3. The process for choosing a new algorithm was designed as a competition: new candidate algorithms were submitted by more than 60 research teams and over five years the entrants were whittled down to a set of finalists, from which a winner was chosen. In October of last year, NIST announced [9] that a team of Italian and Belgian cryptographers had won the competition with their submission named, “Keccak” (pronounced “KECH-ack”). What has NIST done with SHA-3? Since the announcement of Keccak as the winner, NIST has been working hard to turn Keccak into a standard. That is, NIST can’t just point to the academic paper and materials submitted by the Keccak team and call that a standard. NIST has to write the algorithm up in a standards-compliant format and include it in other NIST cryptographic standards documents, such as a successor to the Secure Hash Standard document (FIPS Publication 180-4) [10]. Here’s where the controversy starts. One of the most accomplished civilian cryptographers, NIST’s John Kelsey, gave an invited talk at a conference in August, the Workshop on Cryptographic Hardware and Embedded Systems 2013 (CHES’13) [11], where he described some of the changes NIST has made to Keccak in turning it into a standard. The changes were detailed in five slides (slides 44-48) of Kelsey’s slide deck for his talk [12]. Two major changes puzzled some in attendance: In the name of increased performance (running faster in software and hardware), the security levels of Keccak were drastically reduced. The four versions of the winning Keccak algorithm had security levels of 224-bits, 256-bits, 384-bits, and
Re: [cryptography] The Compromised Internet
On Fri, Sep 27, 2013 at 01:12:19PM -0400, grarpamp wrote: On 9/27/13, Eugen Leitl eu...@leitl.org wrote: I don't see how a ham running a repeater backbone can prevent end to end encryption other than sniffing for traffic and actively disrupting it. I'm not sure tampering with transport is within ham ethics, though they definitely don't understand the actual uses for encryption, at least the old hands (are there even new hands?). The mentioned tech has nothing to do with traditional 'ham'. HamNet/AMPRNet is ham-only. http://de.wikipedia.org/wiki/Hamnet http://www.amateurfunk-wiki.de/index.php/Linkstrecken_HAMNET And without the crypto key they can't see it and can't disrupt Of course they can see it, it's a TCP/IP network routed through their hardware, which is stock (Mikrotik/Ubiquiti etc.). it, it's background/spectrum noise/power to them. Traditionally, presumably hams might discover non-in-the-clear on a specific channel, perhaps triangulate, and report it to some regulatory body (or DoS it). That's not applicable, by design. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Unbreakable Cipher (2)
- Forwarded message from coderman coder...@gmail.com - Date: Wed, 25 Sep 2013 23:38:58 -0700 From: coderman coder...@gmail.com To: brian carroll electromagnet...@gmail.com Cc: cpunks cypherpu...@cpunks.org Subject: Re: The Unbreakable Cipher (2) On Wed, Sep 25, 2013 at 9:29 PM, brian carroll electromagnet...@gmail.com wrote: ... no- not for a multilinear/nonlinear bit set approach. voluminous data exchange... you're wrong. the key is to re-key so frequently there is never a significant volume transferred under the same symmetric key. in the manually keyed IPsec experiment i mentioned in another thread, we used synchronized key daemons to maintain a rolling pair of SA/AH+ESP associations that rotated on a per second interval. as long as you didn't transfer more than some obtuse number of terabits in a given second the assurance provided by a random key is intact. (and we used VIA C5P dual RNG processors to provide the manual keying material that was kept in sync between a pair of communicating stations over unencrypted 802.11b - there was no IKE or other public key exchange, just synchronized symmetric ciphers and digests) - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Unbreakable Cipher
On Wed, Sep 25, 2013 at 10:11:33AM -0400, John Young wrote: Is this conclusion still valid? If so, what could be done to restrict traffic volume to assure unbreakablility? And how to sufficiently test that. You need to be able to estimate the rate of information leakage. This seems to be related to measuring RNG entropy, and is considered a hard (perhaps hopeless?) problem. Presuming that NSA and cohorts have investigated this effect. It seems to be possible to construct a family of cyphers based on PRNGs with Very Large Internal State (the shared key is the state) that asymptotically approach (in a special/edge case are exactly equivalent to) one-time pads. You'd tap them for XOR with cleartext through a relatively small (=plenty of hidden state) window (not necessarily contiguous) and use enough iteration rounds to make sure the information has has a chance to propagate through the computational volume. Edge cases are low-dimensional CAs with a suitable rule, which should be easiest to attack. Higher-dimensional CA analoga have a lot of neighborhood cells, and their map to address space looks like a small world network, so state mixes quite rapidly, requiring fewer rounds. Whether making neighborhood itself random versus orthogonal is helping or hindering things is not obvious. Whether to make the neighborhood itself subject to change at each or N rounds is helping or hindering things is not obvious. The actual problem is to build them provably hard to reverse, and rekey (though a secure channel, natch) before they leak enough information about their inner state to be attackable. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Dissentr: A High-Latency Overlay Mix Network
https://github.com/ShaneWilton/dissentr Note: This project was created as part of a 36-hour hackathon - and primarily as a proof of concept. While the ideas may be sound, and the prototype may work as designed, the protocols involved in this specific project have not been peer-reviewed, and so I cannot recommend that the network be used for anything requiring serious privacy. Dissentr A High-Latency Overlay Mix Network Essentially, Dissentr is a security-minded network, inspired by Tor, with a few important characteristics which serve to differentiate it. High-Latency Tor is a low-latency network. This makes it ideal for real time activities like web browsing, but as a result, opens it up to attacks involving large-scale traffic analysis methods known as end-to-end correlation. In these attacks, an adversary with the ability to analyze massive amounts of traffic in a short period of time is able to match up traffic entering the network with the corresponding traffic which will inevitably soon exit it. Dissentr manages to protect against these sorts of attacks by being engineered as a high-latency network. Assuming any given node has not been compromised, that node will intentionally hold off on forwarding its traffic to the next node in the network until it is able to forward a large amount of data in bulk, rendering the aforementioned end-to-end correlation far less feasible. For an excellent discussion on this attack, and possible countermeasures, see Practical Traffic Analysis: Extending and Resisting Statistical Disclosure. Cascades Much like any mix network, Dissentr models its network as a graph of nodes, each responsible for handling the relay of traffic as it moves along some path through the network. Where Dissentr differs from a network such as Tor is in how this path is constructed. In Dissentr, the network is constructed out of cascades (A term I first heard described by Ian Goldberg, but I've been unable to pin down an original source for): essentially directed, acyclic sub-graphs, in which a node defines a set of trusted nodes, through which they are willing to relay traffic through. Dissentr simplifies this model by only allowing for nodes of out-degree 1, at this time. This construction brings about a number of useful results: In the event that a node is known to be compromised, individual nodes are allowed the ability to either remove themselves from a cascade, or bypass untrusted nodes entirely, without the necessity of a trusted third-party. The network is protected from supernode invasions, in which an attacker floods the network with compromised nodes, in the hopes of either endangering the network's health, or placing the security of users passing through their nodes at risk of traffic interception, and subsequent analysis. This can be guaranteed because cascades are constructed by virtue of a measure of trust between node-operators, and so long as there exists some non-zero subset of trusted operators, they retain the ability to form a cascade of their own, effectively shutting out the efforts of such an attacker. Use-Cases As mentioned previously, the high-latency nature of the network causes a shift in the sorts of activities best facilitated by its use, however, there do exist some unique opportunities which I have neither seen implemented in the context of a mix network, nor discussed in the literature. A personal favourite idea revolves around creating a platform for political blogging, which, assuming a noisy enough network, would offer political dissidents the ability to freely write about issues of corruption or government abuse, without many of the risks associated with using a lower-latency network like Tor. If it takes a week for a blog post to appear in circulation after the author posts it to the network, it becomes magnitudes more difficult for any assailant to trace the authorship of that blog post - especially if that author never visited the website which hosts their content in the first place! It also becomes a fairly trivial exercise to adapt the network to act as a mixing service for digital currency such as Bitcoin. Furthermore, by breaking the network into a number of smaller, disjoint networks for that purpose, one is be able to counter many of the current attacks which target existing mixing services. Cryptosystem I again emphasize that the cryptosystem in place is the result of a rather rushed 48-hour hackathon - in a production system, I would recommend implementing a peer-reviewed cryptosystem, such as the very lightweight Sphinx, or, pending their coming proof of security, the recently proposed Ibis. That being said, Dissentr works as follows: Every node in the network maintains an RSA-keypair, with the public key being exposed to every node in a given cascade. When a client wishes to send a message M through the network, they choose some cascade C. For each node in the cascade,
Re: [cryptography] Deleting data on a flash?
On Mon, Sep 23, 2013 at 11:02:45AM +0300, ianG wrote: On 23/09/13 07:12 AM, Dev Random wrote: I've been thinking about this for a while now and I don't see a way to do this with today's mobile devices without some external help. The issue is that it's pretty much impossible to delete data securely from a flash device. Why is that? I presume it's due to extra blocks due to overprovisioning. There is no way to verify the block you've zeroed or randomized has been really overwritten. It is much easier to destroy the secret of a cryptofs. I've just looked, and there seems to be no easy way to mount an encrypted partition on Android, though GuardianProject has a LUKS howto. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Ibis: An Overlay Mix Network for Microblogging by Ian Goldberg
- Forwarded message from Steve Weis stevew...@gmail.com - Date: Wed, 18 Sep 2013 21:50:45 -0700 From: Steve Weis stevew...@gmail.com To: liberationtech liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Ibis: An Overlay Mix Network for Microblogging by Ian Goldberg Reply-To: liberationtech liberationt...@lists.stanford.edu It was an interesting talk. The gist is that they've shrunk the overhead of the Sphinx mix net ( http://research.microsoft.com/en-us/um/people/gdane/papers/sphinx-eprint.pdf) to 47 bytes. They've done this by removing the requirement for message replies and using curve25519 for ECC. They've also encoded ciphertext with CJK characters to make up most of the 47-byte overhead and let you post close to 140 ASCII characters. That lets them use Twitter as a medium for mix net messages. Users will encrypt messages using a chosen path of Ibis mix net nodes, label them with a hash tag, and either tweet the encrypted message or send it directly through an Ibis node IP address. Ibis nodes will watch for messages with specific tags. When they detect them, they'll decrypt a mix net layer and pass them along to the next node. The final node will post the payload as a retweet. They are still trying to push through a security proof for the paper before posting it, along with a command-line client. I think Ian Goldberg said it would be up at http://ibis.uwaterloo.ca. On Wed, Sep 18, 2013 at 7:09 PM, Tom Ritter t...@ritter.vg wrote: This looks interesting! Am I being dense, or is there a paper or slides or anything somewhere non-Stanfordites can read? -tom -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at 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 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [liberationtech] Ibis: An Overlay Mix Network for Microblogging by Ian Goldberg
- Forwarded message from Steve Weis stevew...@gmail.com - Date: Wed, 18 Sep 2013 08:50:09 -0700 From: Steve Weis stevew...@gmail.com To: liberationt...@lists.stanford.edu liberationt...@lists.stanford.edu Subject: [liberationtech] Ibis: An Overlay Mix Network for Microblogging by Ian Goldberg Reply-To: liberationtech liberationt...@lists.stanford.edu Ian Goldberg is speaking about Ibis: An Overlay Mix Network for Microblogging today at the Stanford security seminar. The talk is 4:30pm in the Gates building, room 463A. http://crypto.stanford.edu/seclab/sem-12-13/goldberg.html Abstract: Microblogging services such as Twitter are extremely popular. While they are commonly used by people who wish to reveal their names and friends to the world, some users, such as activists on the ground, may wish to be able to post without automatically revealing their identities or locations. An obvious approach is to use a low-latency anonymity system, such as Tor. However, low-latency systems fall prey to end-to-end timing attacks easily accomplished by an ISP or a government monitoring clients while also watching for posts to appear in real time on the microblogging site. We present Ibis, a high-latency mix network designed specifically for microblogging. Ibis is an overlay network: the mix nodes can be microblogging clients that come online only sporadicly, and the intermediate encrypted messages are themselves posted as microblogged entries. We accomplish this through a novel cryptographic mix message format that uses only 47 bytes of overhead, while maintaining three-hop, 128-bit security against offline attack. This is joint work with Paul Hendry. Bio: Ian Goldberg is an Associate Professor of Computer Science and a University Research Chair at the University of Waterloo, where he is a founding member of the Cryptography, Security, and Privacy (CrySP) research group. He holds a Ph.D. from the University of California, Berkeley, where he discovered serious weaknesses in a number of widely deployed security systems, including those used by cellular phones and wireless networks. He also studied systems for protecting the personal privacy of Internet users, which led to his role as Chief Scientist at Zero-Knowledge Systems (now Radialpoint). His research currently focuses on developing usable and useful technologies to help Internet users maintain their security and privacy. He is a Senior Member of the ACM and a winner of the Early Researcher Award, the Outstanding Young Computer Science Researcher Award, and the Electronic Frontier Foundation's Pioneer Award. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at 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 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Random number generation influenced, HW RNG
- Forwarded message from Eric Young e...@pobox.com - Date: Tue, 10 Sep 2013 20:58:20 +1000 From: Eric Young e...@pobox.com To: Eugen Leitl eu...@leitl.org Cc: cypherpu...@al-qaeda.net, i...@postbiota.org, zs-...@zerostate.is, Cryptography List cryptogra...@metzdowd.com Subject: Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG X-Mailer: Evolution 3.2.3-0ubuntu6 On Sun, 2013-09-08 at 13:27 +0200, Eugen Leitl wrote: - Forwarded message from James A. Donald 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. I may have missed this part of the thread, but I'm interested in knowing the rational for letting the hyper-visor intercept the RDRAND call and return any value it likes, bypassing the random hardware. I've had one person speculate it would be useful for keeping 2 CPUs in sync, (the TSC can also be intercepted), but it does worry me that RDRAND calls can be rendered predictable by a compromised VM. eric For those interested, Intel document 325462.pdf, Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C Page 'Vol. 3C 27-23', Table 27-12. Format of the VM-Exit Instruction-Information Field as Used for RDRAND - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/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
Re: [cryptography] [Cryptography] Opening Discussion: Speculation on BULLRUN
- Forwarded message from Jeffrey I. Schiller j...@mit.edu - Date: Sun, 8 Sep 2013 21:23:33 -0400 From: Jeffrey I. Schiller j...@mit.edu To: John Gilmore g...@toad.com Cc: Cryptography cryptogra...@metzdowd.com Subject: Re: [Cryptography] Opening Discussion: Speculation on BULLRUN User-Agent: Mutt/1.5.21 (2010-09-15) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 06, 2013 at 05:22:26PM -0700, John Gilmore wrote: Speaking as someone who followed the IPSEC IETF standards committee pretty closely, while leading a group that tried to implement it and make so usable that it would be used by default throughout the Internet, I noticed some things: ... Speaking as one of the Security Area Directors at the time... I have to disagree with your implication that the NSA intentionally fouled the IPSEC working group. There were a lot of people working to foul it up! I also don’t believe that the folks who participated, including the folks from the NSA, were working to weaken the standard. I suspect that the effort to interfere in standards started later then the IPSEC work. If the NSA was attempting to thwart IETF security standards, I would have expected to also see bad things in the TLS working group and the PGP working group. There is no sign of their interference there. The real (or at least the first) problem with the IPSEC working group was that we had a good and simple solution, Photuris. However the document editor on the standard decided to claim it (Photuris) as his intellectual property and that others couldn’t recommend changes without his approval. This effectively made Photuris toxic in the working group and we had to move on to other solutions. This is one of the events that lead to the IETF’s “Note Well” document and clear policy on the IP associated with contributions. Then there was the ISAKMP (yes, an NSA proposal) vs. SKIP. As Security AD, I eventually had to choose between those two standards because the working group could not generate consensus. I believed strongly enough that we needed an IPSEC solution so I decided to choose (as I promised the working group I would do if they failed to!). I chose ISAKMP. I posted a message with my rationale to the IPSEC mailing list, I’m sure it is still in the archives. I believe that was in 1996 (I still have a copy somewhere in my personal archives). At no point was I contacted by the NSA or any agent of any government in an attempt to influence my decision. Folks can choose to believe this statement, or not. IPSEC in general did not have significant traction on the Internet in general. It eventually gained traction in an important niche, namely VPNs, but that evolved later. IPSEC isn’t useful unless all of the end-points that need to communicate implement it. Implementations need to be in the OS (for all practical purposes). OS vendors at the time were not particularly interested in encryption of network traffic. The folks who were interested were the browser folks. They were very interested in enabling e-commerce, and that required encryption. However they wanted the encryption layer someplace where they could be sure it existed. An encryption solution was not useful to them if it couldn’t be relied upon to be there. If the OS the user had didn’t have an IPSEC layer, they were sunk. So they needed their own layer. Thus the Netscape guys did SSL, and Microsoft did PCT and in the IETF we were able to get them to work together to create TLS. This was a *big deal*. We shortly had one deployed interoperable encryption standard usable on the web. If I was the NSA and I wanted to foul up encryption on the Internet, the TLS group is where the action was. Yet from where I sit, I didn’t see any such interference. If we believe the Edward Snowden documents, the NSA at some point started to interfere with international standards relating to encryption. But I don’t believe they were in this business in the 1990’s at the IETF. -Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSLSMV8CBzV/QUlSsRAigkAKCU6erw1U7FOt7A1QdItlGbFRfo+gCfeMg1 0Woyz0FyKqKYqS+gZFQWEf0= =yWOw -END PGP SIGNATURE- ___ The cryptography mailing list cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Backdoors in software
On Mon, Sep 09, 2013 at 01:50:54PM -0500, Nicolai wrote: On Mon, Sep 09, 2013 at 02:20:35PM +0200, David D wrote: TrueCrypt can be assumed ok based on Greenwald using it.If Snowden knew of a hole in TrueCrypt then Greenwald would not be using it. IMO. I don't think this is a useful criteria. After all, Greenwald probably uses Windows, right? Schneier uses Windows, too. http://www.truecrypt.org/docs/supported-operating-systems TrueCrypt currently supports the following operating systems: Windows 7 (32-bit and 64-bit) Windows Vista (32-bit and 64-bit) Windows XP (32-bit and 64-bit) Windows Server 2008 R2 (64-bit) Windows Server 2008 (32-bit and 64-bit) Windows Server 2003 (32-bit and 64-bit) Windows 2000 SP4 Mac OS X 10.8 Mountain Lion (32-bit and 64-bit) Mac OS X 10.7 Lion (32-bit and 64-bit) Mac OS X 10.6 Snow Leopard (32-bit) Mac OS X 10.5 Leopard Mac OS X 10.4 Tiger Linux (32-bit and 64-bit versions, kernel 2.6 or compatible) Note: The following operating systems (among others) are not supported: Windows RT, Windows 2003 IA-64, Windows 2008 IA-64, Windows XP IA-64, and the Embedded/Tablet versions of Windows. NB: I'm not making any claim for or against TrueCrypt. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Political Cypherpunks Trumps Apolitical Cryptography
- Forwarded message from John Young j...@pipeline.com - Date: Sun, 08 Sep 2013 09:12:25 -0400 From: John Young j...@pipeline.com To: cypherpu...@cpunks.org Subject: Political Cypherpunks Trumps Apolitical Cryptography X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 What is striking about discussion on the two cryptography mail lists, both set up to minimize discussing political and social issues to avoid cypherpunks acceptance of them, is the tentative reconsideration of those issues due to Snowden's revelations, miniscule as they are. Notable among those raising the political threat are those who disdained the issue on cypherpunks and stomped off to set up alternatives ham-handedly moderated to cease and desist the off-topic. A few now say, bray more like it, NSA has betrayed us through political manipulation of officials and the public, and that is an important point which often came up on cypherpunks and still does, with somewhat less complaining about it. For Snowden has shown the political has won out over the technical, and the technicals are fraught with what to do about it, and much fingerpointing is going on along with a few claims of having forewarned this betrayal would happen. No moderation yet has shut down this off-topic. But much gumming and gnawing of the futility of technical means against the vulgar political. What has been shown in the discussion is that the technical wizards are not nearly as competent at the messy political as they are at technical sophistication. The resulting conversation is a mish-mash of fairly high level technical discourse interleaved with fairly clumsy political opinionating. So technical clubs are being swung to answer political jabs, that is petty squabblling and exchange of slurs has replaced rational discourse. Thus the convo has become politicized with as much stupidity and ignorance as sharp thinking and mutual respect. NSA and its bosses would be happy if this became the norm in cryptography as in the real world. And some opine that this outcome is being, and has been in the past, and will be in the future, orchestrated for just that result. That sounds like what cypherpunks was set up to combat, the withdrawal from politcial affairs into safe sanctuary of infallible mathematics coated with unending challengences to implement illusory protection from political mayhem. So it has come to pass, there is no refuge from politics, and the once reviled tin-hats of conspiracy theories are replacing anomymous masks, especially by the best and brightest cryptographers who have been hoodwinked far more than dreamed of in earliest days of cypherpunks. Still, there are die-hard PR-driven comsec experts rolling out advice for what to do to protect the public -- meaning, cynically protecting their severely damaged reputation of concern for the public interest (R). Not yet willing to admit losing the comsec and privacy war so avidly promoted with HTTPS, SSL, PGP, PFS, OTR, Tor, on and on, they continue to hustle comsec customers with promises of here's what we have got to do, take it from us experienced veterans (read my remarks, hear my TV interviews, read my messages on cryptography, gorge on recyclings on Slashdot, Twitter, Reddit, Voice of America, EFF. Guardian, New York Times, ProPublica, ACLU, EPIC, on and on): Lo, special prosecute NSA, take it to the courts, a tired political gambit for media semaphoring, fund raising, conceding technical defeat and begging political rescue by what's that you say, account churning lawyers, political lobbyists and journalistic hacks. That is so obnoxious, murmurs the cryptography mail lists, so opportunistically off-topic, moderator do your censoring, let's get back to the good stuff. Despite the murmurrings there recurs calls for cut the cowardly shit, let's fight. One guess who said that. - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] regarding the NSA crypto breakthrough
On Thu, Sep 05, 2013 at 10:47:10AM -0700, coderman wrote: of all the no such agency disclosures, this one fuels the most wild speculation. It is reported that the journalists deliberately withheld details which are available in Snowden's original documents. Somebody better leak these, fast. The claims are that some code and magic constants have been weakened, but also that NSA still has problems with some methods. We need to know. Obviously, as a short-term workaround there's fallback to expensive/inconvenient methods like one-time pads, but long-term we obviously need new cyphers. Not tainted by any TLA poison. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Opening Discussion: Speculation on BULLRUN
/GRirC14C2cXieC8JwjrevIoBQmCLUutNK6 XC4sOGrFZ7Z37sXL+1jT =4NbV -END PGP SIGNATURE- ___ The cryptography mailing list cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Wed, Aug 14, 2013 at 09:47:09AM +1000, James A. Donald wrote: On 2013-08-14 6:10 AM, Nico Williams wrote: - it's really not easy to defeat the PRISMs. the problem is *political* more than technological. For a human to read all communications would be an impossible burden. We're rapidly approaching that point where judge, jury and executioner are completely automated. As such neither scaling issues of Stasi (at some point some half of the population were informants) nor quis custodiet are a problem. Instead, apply the following algorithm. Identify people of interest. Read communications between persons of interest. If several people of interest talk to Bob, then Bob may well also a person of interest. /Then/ read their communications. If significant, add Bob to the list of people of interest. IIRC there's already collection on three degrees of separation in place, and that is already a fair fraction of the global population so at least part of the judging is already automated. Looking at communication patterns, Identify the more central nodes among people of interest. Make a special effort to crack the communications of the most central nodes. The technological counter to this is the cypherpunks remailers, which are unfortunately user hostile, especially when used with a permanent identity. How badly bitrotted is the codebase? With the current threat model it looks like high-latency anonymous networks could well use a revival. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Bitcoin-development] Preparing for the Cryptopocalypse
- Forwarded message from Gregory Maxwell gmaxw...@gmail.com - Date: Sun, 4 Aug 2013 23:41:57 -0700 From: Gregory Maxwell gmaxw...@gmail.com To: Peter Vessenes pe...@coinlab.com Cc: Bitcoin Dev bitcoin-developm...@lists.sourceforge.net Subject: Re: [Bitcoin-development] Preparing for the Cryptopocalypse On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes pe...@coinlab.com wrote: I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He told me recently NTRU, which is lattice based, is one of the few (only?) NIST-recommended QC-resistant algorithms. Lamport signatures (and merkle tree variants that allow reuse) are simpler, faster, trivially implemented, and intuitively secure under both classical and quantum computation (plus unlikely some proposed QC strong techniques they're patent clear). They happen to be the only digital signature scheme that you really can successfully explain to grandma (even for values of grandma which are not cryptographers). They have poor space/bandwidth usage properties, which is one reason why Bitcoin doesn't use them today, but as far as I know the same is so for all post-QC schemes. Though I question the validity of the claim that ECC is so much more secure than RSA (with appropriate keysizes). The problems are intimately related, but under the best understanding ECC (with suitable parameters) ends up being the maximally hard case of that problem class. I do sometimes worry about breakthroughs that give index-calculus level performance for general elliptic curves, this still wouldn't leave it any weaker than RSA but ECC is typically used with smaller keys. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list bitcoin-developm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] ZeroReserve -- a friend 2 friend payment scheme and Bitcoin exchange
Implemented as a RetroShare plugin. https://github.com/zeroreserve/ZeroReserve ZeroReserve Friend 2 Friend Payment and Bitcoin exchange Prerequisite for building is a successful RetroShare build and sqlite3. To build, checkout the sources to the plugins directory of Retroshare and build with $ qmake make clean make To install on Windows, drop the resulting DLL into the %APPDATA%\Retroshare\extensions directory. To install on Linux, drop the resulting shared object into ~/.retroshare/extensions ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta
- Forwarded message from Mike Hearn m...@plan99.net - Date: Tue, 30 Jul 2013 14:12:51 +0200 From: Mike Hearn m...@plan99.net To: Wendell w...@grabhive.com Cc: Bitcoin Dev bitcoin-developm...@lists.sourceforge.net, Gregory Maxwell gmaxw...@gmail.com, bitcoin-l...@lists.sourceforge.net Subject: Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta The TPM is a piece of secure* hardware that provides various cryptographic services to the host system. It is important to understand that it is not a crypto accelerator. It is a place to store keys and small pieces of data (like hashes, counters) where it's difficult for someone to extract them even if they have physical access. The TPM is designed to support trusted computing, a rather splendid set of extensions to the x86 architecture that let you do remote attestation, software sealing and other things. Or at least it would be splendid if it had been really finished off and pushed to completion by the designers. Unfortunately due to various political issues it exists in a quasi-finished, semi-broken state which only experts can use. Without a doubt you have never run any software in a TC environment. As part of that role, the TPM provides some permanent storage in the form of NVRAM. Because the TPM is designed to be as cheap as possible, it has a limited number of write cycles. Normally you're meant to store Intel TXT launch control policies and sealed keys there, but Pond uses it in a different way by storing keys there that it encrypts local data with. By erasing the key in the TPM chips memory area, the data on disk is effectively destroyed too. This is useful because modern disks are often SSD drives, or physical metal disks that use log structured file systems. Because flash memory has a limited number of write cycles per cell, internally SSDs have firmware that remap writes from logical addresses to different physical addresses, the goal is to avoid wearing down the drive and extend its useful life. Normally it doesn't matter, but if you want to delete data such that it's really really gone, it obviously poses a problem. Using TPM NVRAM solves it, albiet, at a high usability cost. *note: actual tamper resistance of real-world TPM chips is not something that seems to have been studied much On Tue, Jul 30, 2013 at 1:27 PM, Wendell w...@grabhive.com wrote: Can you explain this process for those of us not too familiar with TPM chips? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote: As a testament to the seriousness with which Pond takes forward security, it can use the NVRAM in a TPM chip to reliably destroy keys for data that an SSD device might have otherwise made un-erasable. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ bitcoin-list mailing list bitcoin-l...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] a Cypherpunks comeback
On Mon, Jul 22, 2013 at 09:41:14AM +0200, Adam Back wrote: Could you please get another domain name, that name is just ridiculous. It might tickle your humour but I guarantee it does not 99% of potential subscribers... Unless your hidden objective is to drive away potential subscribers. For those who dislike posting to the The Base, here's an alternative domain for the same list: https://cpunks.org/mailman/options/cypherpunks Adam On Sun, Jul 21, 2013 at 11:07:26AM +0200, Eugen Leitl wrote: - Forwarded message from Riad S. Wahby r...@jfet.org - Date: Sat, 20 Jul 2013 12:41:25 -0400 From: Riad S. Wahby r...@jfet.org To: cpunks-recipients-suppres...@proton.jfet.org Subject: a Cypherpunks comeback User-Agent: Mutt/1.5.21 (2010-09-15) tl;dr: I'm writing to invite you back to the Cypherpunks mailing list. If you're interested, you can join via https://al-qaeda.net/mailman/listinfo/cypherpunks Hello, In the past couple days I've exchanged emails with John Young and Eugen Leitl on some brokenness in the Cypherpunks mailing list. This discussion brought us to a discussion of attempting to resurrect the list's wetware, as it were, in addition to its software. At Eugen's request, John dug up a couple Majordomo WHO outputs from about 15 years ago; I tidied up the lists, and now I'm writing to you. So! if you still have an interest in crypto, privacy, and politics, and if you want to discuss that interest with a bunch of like-minded weirdos from the aether, you can subscribe yourself via the web interface above or by sending an email with subscribe in the body to cypherpunks-requ...@al-qaeda.net. (I am aware the provocative choice of domain name may discourage you somewhat. I can only tell you that I've been running a Cypherpunks list of some sort from this domain for a bit over a decade, and I haven't yet been spirited away in a black helicopter. Here's hoping for another helicopter-free decade.) Best regards, and welcome back, preemptively, -=rsw on behalf of jya, eugen, and rsw - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [liberationtech] Random number generator failure in Rasperri Pis?
- Forwarded message from KheOps khe...@ceops.eu - Date: Fri, 19 Jul 2013 14:03:23 +0200 From: KheOps khe...@ceops.eu To: liberationt...@lists.stanford.edu liberationt...@lists.stanford.edu Subject: [liberationtech] Random number generator failure in Rasperri Pis? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 Reply-To: liberationtech liberationt...@lists.stanford.edu Hi all, Just came accross this article, apparently showing the bad quality of the hardware RNG in Raspberri Pi devices. http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ Quite interesting since (pseudo-) random numbers are heavily used in crypto. Interesting also to see another post on this topic, after the study of a random number generation procedure formerly used in Cryptocat and that was also problematic. Datalove, KheOps -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tahoe-dev] proposal: add padding
- Forwarded message from Zooko O'Whielacronx zoo...@gmail.com - Date: Fri, 12 Jul 2013 16:56:47 + From: Zooko O'Whielacronx zoo...@gmail.com To: Tahoe-LAFS development tahoe-...@tahoe-lafs.org Subject: Re: [tahoe-dev] proposal: add padding Reply-To: Tahoe-LAFS development tahoe-...@tahoe-lafs.org No, no, we rely on the correctness of our encryption to hide all information about the plaintext from an attacker who doesn't know the encryption key. Therefore, the pad bytes are all just zero bytes, and we believe that this pattern gives nothing useful to the cryptanalyst. (Our encryption is currently AES. I hope in the future to upgrade it to AES⊕XSalsa20 — see #1164 and wiki:OneHundredYearCryptography.) https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1164# use XSalsa20+AES-128 encryption https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography Regards, Zooko ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
On Fri, Jul 12, 2013 at 10:29:49PM +0300, ianG wrote: Not to mention, Intel have been in bed with the NSA for the longest time. Secret areas on the chip, pop instructions, microcode and all that ... A more interesting question is whether the non-USA competitors are also similarly friendly. It seems there's a good niche for open hardware, either run in FPGAs (which are backdoorable, of course), or designs which can be verified optically, preferably using relatively large, obsolete structures. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] failure submission address now up at http://www.cryptofails.com/
In case you come across particular hair-raising crypto horrors, please submit them to the author listed on http://www.cryptofails.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
On Sat, Jul 13, 2013 at 01:43:49AM -0400, Patrick Mylund Nielsen wrote: Heh, might as well just give up. http://cm.bell-labs.com/who/ken/trust.html (I know what you meant, just couldn't resist.) Certainly a classic, but these days you can really bootstrap your toolchain in a cleanroom quite quickly. See e.g. http://www.excamera.com/sphinx/fpga-j1.html which is fundamentally not safe from attacks like http://www.h-online.com/security/news/item/Backdoor-found-in-popular-FPGA-chip-1585579.html but it's hard to see how you could get something in there in a tight, human-inspectable compilate, and use the FPGA as a sacrificial bootstrap step only. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
- Forwarded message from Matt Mackall m...@selenic.com - Date: Thu, 11 Jul 2013 17:34:48 -0500 From: Matt Mackall m...@selenic.com To: liberationtech liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Heml.is - The Beautiful Secure Messenger X-Mailer: Evolution 3.4.4-1 Reply-To: liberationtech liberationt...@lists.stanford.edu On Thu, 2013-07-11 at 13:47 -0700, Andy Isaacson wrote: Linux now also uses a closed RdRand [2] RNG if available. There was a bunch of churn when this code went in, so I could be wrong, but I believe that RdRand is only used to stir the same entropy pool as all of the other inputs which are used to generate random data for /dev/random et al. It's hard to leverage control of one input to a random pool into anything useful. It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. From a quick skim of current sources, much of that has recently been rolled back (/dev/random, notably) but kernel-internal entropy users like sequence numbers and address-space randomization appear to still be exposed to raw RdRand output. (And in the meantime, my distrust of Intel's crypto has moved from standard professional paranoia to actual legitimate concern.) -- Mathematics is the supreme nostalgia of our time. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Crypto fails -- showcasing bad cryptography
http://www.cryptofails.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] What project would you finance? [WAS: Potential funding for crypto-related projects]
On Sun, Jun 30, 2013 at 07:09:57PM -0700, Yosem Companys wrote: Speaking of which... If you had an extra $2-3K to give to a liberationtech or crypto project, who do you think would benefit the most? A BTNS implementation. There aren't any. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] post-PRISM boom in secure communications (WAS skype backdoor confirmation)
On Mon, Jul 01, 2013 at 01:31:51PM +0200, Guido Witmond wrote: The only answer is to take key management out of the users' hands. And do it automatically as part of the work flow. You need at least a Big Fat Warning when the new fingerprint differs from the cached one, and it's not just expired. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
On Thu, May 23, 2013 at 09:38:18AM +0200, David Adamson wrote: Danilo Gligoroski danilo.gligoro...@gmail.com wrote: 1. Indeed these discussions among the security community 2. Eventually some contacts with journalists will help the cause (one live demonstration on some security/crypto conference like Usenix, Black Hat, Crypto, ... will do the job). 3. I see a chance for some other product like: Zfone (that never took significant popularity),maybe Pidgin, maybe Cryptocat, ... 4. Even some open source security plugin for Skype. My two cents: 4a: A SSH Java open source wrapper around Skype will do the job. The chat logs or any other traffic that Skype is leaking to some Echelon-like spying sites will be externally encrypted by the SSH wrapper. To move this thread a bit sideways, does anyone know whether Hangout claims to be end to end secure? Considering that Google is dropping XMPP support, I'm investigating other options, e.g. Jitsi. Has there been a security review for Jitsi? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Biggest Fake Conference in Computer Science
This is spam. I had to ban the guy from all my mailing lists. On Sat, Apr 20, 2013 at 10:25:22AM -0400, jimsimps...@hushmail.com wrote: We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. If WORLDCOMP is not fake then why did DBLP suddenly stopped listing the proceedings after? The status of your WORLDCOMP papers can be changed from “scientific” to “other” (i.e., junk or non-technical) at any time. See the comments http://www.mail-archive.com/tccc@lists.cs.columbia.edu/msg05168.html of a respected researcher on this. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and try to threaten the critiques of WORLDCOMP. That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. WORLDCOMP’13 will be held at a different resort. WORLDCOMP will not be held after 2013. The paper submission deadline for WORLDCOMP’13 was March 18 and it was extended to April 6 and now it is extended to April 20 (it may be extended again) but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Prof. Hamid Arabnia expends the deadline to get more papers (means, more registration fee into his pocket!). Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http
Re: [cryptography] Cypherpunks mailing list
On Mon, Mar 25, 2013 at 05:50:18PM +0100, Adam Back wrote: Isn't exactly that a nice property of a cypherpunks list? No it is not, it is a way to persuade people to leave, or not join the listserv. We have to agree to disagree on that one. A 'punk' of any kind will tend to thumb his nose at authorities. If they consider the name annoying, so much the better. Maybe someone with a more neutral domain could try it - or a cypherpunks.* domain if they have a listserv handy. Cypherpunks is a distributed mailing list. A subscriber can subscribe to one node of the list and thereby participate on the full list. Each node (called a Cypherpunks Distributed Remailer [CDR], although they are not related to anonymous remailers) exchanges messages with the other nodes in addition to sending messages to its subscribers. Yes I know, but that badly named listserv is the last CDR. I find the base is a very good name for a listserv. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cypherpunks mailing list
On Mon, Mar 25, 2013 at 07:03:04PM +0100, Adam Back wrote: But my point actually was b...@al-qaeda.net??? Come on that is watch list Of course it is pure watch list bait. That's the point. bait and an invitation NOT to join list blah, whatever it is about. If you think it's a deterrent, then it's not the right list to join, anyway. I think I should be on any watch list known to man, if not, they've been asleep at the wheel. And it would be self-DoS, which is precisely the point. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [FoRK] ELF .so encryption contract work, probably resulting in open source
- Forwarded message from Stephen D. Williams s...@lig.net - From: Stephen D. Williams s...@lig.net Date: Wed, 13 Mar 2013 19:43:06 -0700 To: Friends of Rohit Khare f...@xent.com, fo...@lig.net, ge...@lig.net, Michael Tiemann tiem...@redhat.com, fosdwn...@lig.net Subject: [FoRK] ELF .so encryption contract work, probably resulting in open source User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 Reply-To: Friends of Rohit Khare f...@xent.com We need the ability to encrypt the code in code segments of an ELF .so, for Linux / Android at least, with an AES key and also decrypt it in memory after loading by libdl using the same key. Key management is out of scope. Might want selective decryption/encryption. Signed code is in scope. Result will probably be releasable as open source. This is something that should already exist, we need it, and I can pay for it. If you know anyone interested, please connect us. I could do it in 1-3 weeks, but that's not going to happen anytime soon for a long todo list of reasons. Stephen -- Stephen D. Williams s...@lig.net stephendwilli...@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer ___ FoRK mailing list http://xent.com/mailman/listinfo/fork - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Cryptography super-group creates unbreakable encryption
- Forwarded message from Fabio Pietrosanti (naif) li...@infosecurity.ch - From: Fabio Pietrosanti (naif) li...@infosecurity.ch Date: Thu, 14 Feb 2013 02:03:26 +0100 To: liberationtech liberationt...@lists.stanford.edu Subject: Re: [liberationtech] Cryptography super-group creates unbreakable encryption User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 Reply-To: liberationtech liberationt...@lists.stanford.edu Here some notes i collected with a quick review of the source code: https://pad.riseup.net/p/silentcircle -naif On 2/14/13 1:36 AM, Nadim Kobeissi wrote: This is good news! Still far from a complete source code release, but it's good that they're progressing, even if very slowly. Once all of the code is out I'll finally shut up about Silent Circle. NK -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Edon-R hashing and dedup
- Forwarded message from Matthew Ahrens mahr...@delphix.com - From: Matthew Ahrens mahr...@delphix.com Date: Thu, 14 Feb 2013 13:32:35 -0800 To: z...@lists.illumos.org Subject: Re: [zfs] Edon-R hashing and dedup Reply-To: z...@lists.illumos.org On Mon, Feb 11, 2013 at 6:22 AM, Sašo Kiselkov skiselkov...@gmail.comwrote: So I've been talking to some people around storage and found out that SHA-256 hashing *is* a significant cost in implementing dedup. I know I'm arriving late to this discussion. For my own understanding, I'd like to attempt to summarize the various positions and get everyone's feedback. SHA-256 is slow; we'd like to find a faster algorithm to replace it, which will use less CPU. Such a replacement must be usable for dedup without verification. (Performance and behavior with verification is a secondary concern to the points outlined here.) Dedup inherently relies on probabilistic correctness: if there is a hash collision, incorrect data will be returned. This is true even with the best hash algorithms (including SHA-256), and even without the possibility of storing malicious data. However, the probability involved is exceedingly small. Given 2^64 bytes (16 exabytes) in 8KB blocks, the odds of a collision are approximately 1/2^155. This is less likely than consecutively buying 5 jackpot-winning lottery tickets (assuming lottery odds 1/100 million). Dedup is sometimes used with user-generated data (i.e. untrusted, possibly malicious users provide the data to store). In the case, the hash algorithm should be such that it is infeasible to find a block which hashes to a given value. Otherwise an untrusted user may cause ZFS to return incorrect data. Dedup is sometimes used only with trusted data (i.e. none of the data can be maliciously generated). In this case, the algorithm need only distribute input blocks evenly over all 2^256 possible hash values. It is OK if it is feasible to find a block with a given hash value, because the risk associated is no worse than the ideal case (e.g 1/2^155 chance of returning incorrect data with the workload described above). SHA-256 is currently used for both of these use cases (trusted and untrusted data). So a replacement should also be usable for both. Optionally, we could implement a third, even faster, algorithm for use only in the trusted case. Some people believe that this choice may be misused (i.e. used even when the data can not be trusted), and therefore this option should not be offered. I'm not an expert in crypto algorithms; I've only read the wikipedia page on the SHA-3 competition ( http://en.wikipedia.org/wiki/NIST_hash_function_competition). Being fairly paranoid mainly due to my lack of expertise in this area, I would prefer to choose one of the finalists as a replacement for SHA-256. It sounds like BLAKE and Skein have reasonable performance. I think that the easiest way forward will be to first agree on a high-performance replacement for SHA-256, which is usable in all cases that SHA-256 is, including with untrusted data. We can then evaluate demand for an even faster algorithm to be used only with trusted data. --matt --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Edon-R hashing and dedup
- Forwarded message from Sašo Kiselkov skiselkov...@gmail.com - From: Sašo Kiselkov skiselkov...@gmail.com Date: Tue, 12 Feb 2013 23:14:36 +0100 To: z...@lists.illumos.org CC: Nico Williams n...@cryptonector.com, Richard Elling richard.ell...@gmail.com Subject: Re: [zfs] Edon-R hashing and dedup User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 Reply-To: z...@lists.illumos.org On 02/12/2013 10:31 PM, Nico Williams wrote: On Tue, Feb 12, 2013 at 12:34 PM, Garrett D'Amore garrett.dam...@gmail.com wrote: I think security could be important here. A determined attacker with access to the file system (perhaps very indirectly) could cause devastating corruption if he could arrange for collisions against a key file or block on a dataset with dedup and no verify set. Admittedly the likelihood of a successful attack is low, but that isn't the same as saying that security is not a consideration for the ZFS hash function. That's why dedup requires a cryptographic hash. No, the cryptographic bit was chosen as a simple designator of hash with collision resistance, since cryptographic security implies that. Any SHA-3 candidate that was not rejected due to weaknesses discovered in cryptanalysis is almost certainly good enough for dedup. I would contend that the priority for ZFS dedup is: 1) software speed 2) collision resistance 3) cryptographic security The last two are not the same. Other hashes I considered were: BLAKE2: 1) It's slower than Edon-R (considerably so, the best I managed to get was ~5 CPB). 2) The above result requires using SSE 4.1 or other advanced vector instructions, which is difficult to support in the kernel. This also means that performance will suffer significantly if these instructions aren't available (e.g. on older CPUs or non-x86 CPUs). 3) It's derived from BLAKE, one of the SHA-3 finalists, which should make it theoretically as safe (though it hasn't been subjected to cryptanalysis to make sure the implementors haven't made a mistake). Blue Midnight Wish: 1) It's somewhat slower than Edon-R (though not as slow as BLAKE2) 2) Has been subjected to SHA-3 cryptanalysis and currently no preimage attacks exist against it (and no practical attacks on the full version of the hash either). 3) Its implementation is pure C, like Edon-R (no SSE trickery required). Let's, however, not lose focus on what is really important. Edon-R has *not* been broken. 1st preimage at complexity 2^343 is at most a thinking pause, however, it is nowhere near being anything practical. We'd be using the hash truncated to 256-bits anyway, which makes an exhaustive search still much easier to perform. The reason SHA-3 discarded it is because SHA-3 has a much broader scope and is supposed to mandate a standard for hashing all sorts of data at all possible sensitivity levels. ZFS dedup has an extremely narrow scope and the nature of our data is much more constrained, meaning, even if some theoretical attack can be made remotely practical, it is still nowhere near to posing any problems for our particularly narrow-scoped application. Cheers, -- Saso --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Edon-R hashing and dedup
making contriving up fantasies of attacks that can neither be quantitatively assessed nor approach by any rational means. Cheers, - -- Saso -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlEayasACgkQle4gLqwmJMfR+QCgn+1ohjckklfDbH24OYSXp4j8 KyAAn0Bi0fYKY03q+Q7d9+NAZB1MEwnY =1fHP -END PGP SIGNATURE- --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Gmail and SSL
- Forwarded message from Randy na...@afxr.net - From: Randy na...@afxr.net Date: Fri, 14 Dec 2012 09:47:03 -0600 To: NANOG list na...@nanog.org Subject: Gmail and SSL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will offer[s] a higher level of security to better protect your information. I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option. I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic. Please google, remove this requirement. Source: http://support.google.com/mail/bin/answer.py?hl=enanswer=21291ctx=gmail#strictSSL - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Quantum cryptography conquers noise problem
(ob caveat snake oil crypto) http://www.nature.com/news/quantum-cryptography-conquers-noise-problem-1.11849 Quantum cryptography conquers noise problem Encoded photons sent a record distance along busy optical fibres. Zeeya Merali 20 November 2012 Quantum cryptography could keep messages ultra-secure — if the right detector can be developed. N. Gregory/Alamy It’s hard to stand out from the crowd — particularly if you are a single photon in a sea of millions in an optical fibre. Because of that, ultra-secure quantum-encryption systems that encode signals into a series of single photons have so far been unable to piggyback on existing telecommunications lines. But now, physicists using a technique for detecting dim light signals have transmitted a quantum key along 90 kilometres of noisy optical fibre1. The feat could see quantum cryptography finally enter the mainstream. You cannot measure a quantum system without noticeably disrupting it. That means that two people can encode an encryption key — for bank transfers, for instance — into a series of photons and share it, safe in the knowledge that any eavesdropper will trip the system’s alarms. But such systems have not been able to transmit keys along telecommunications lines, because other data traffic swamps the encoded signal. As a result, quantum cryptography has had only niche applications, such as connecting offices to nearby back-up sites using expensive 'dark' fibres that carry no other signals. “This is really the bottleneck for quantum cryptography,” says physicist Nicolas Gisin, a scientific adviser at quantum-cryptography company ID Quantique in Geneva, Switzerland. Physicists have attempted to solve the problem by sending photons through a shared fibre along a 'quantum channel' at one characteristic wavelength. The trouble is that the fibre scatters light from the normal data traffic into that wavelength, polluting the quantum channel with stray photons. Andrew Shields, a physicist at the Toshiba Cambridge Research Laboratory, UK, and his colleagues have now developed a detector that picks out photons from this channel only if they strike it at a precise instant, calculated on the basis of when the encoded photons were sent. The team publishes its results in Physics Review X. Designing a detector with such a sharp time focus was tough, explains Shields. Standard detectors use semiconducting devices that create an avalanche of electrical charge when struck by a single photon. But it usually takes more than one nanosecond (10−9 seconds) for the avalanche to grow large enough to stand out against the detector’s internal electrical hiss — much longer than the narrow window of 100 picoseconds (10−10 seconds) needed to filter a single photon from a crowd. The team’s ‘self-differentiating’ detector activates for 100 picoseconds, every nanosecond. The weak charge triggered by a photon strike in this short interval would not normally stand out, but the detector measures the difference between the signal recorded during one operational cycle and the signal from the preceding cycle — when no matching photon was likely to be detected. This cancels out the background hum. Using this device, the team has transmitted a quantum key along a 90-kilometre fibre, which also carried noisy data at 1 billion bits per second in both directions — a rate typical of a telecommunications fibre. The team now intends to test the technique on a real telecommunications line. Gisin’s team has independently developed a photon detector with a similar time window, which they presented at the QCrypt 2012 meeting at the Centre for Quantum Technologies in Singapore in September. However, Gisin has calculated that such a technique cannot be used to transmit quantum signals beyond the range of a large city of 100 kilometres2. Scattering accumulates over distance, so there would eventually be so many stray photons that it would be impossible to filter them out, even with a precisely timed detector. Still, 90 kilometres is a “world record that is a big step forward in demonstrating the applicability of quantum cryptography in real-world telecommunications infrastructures”, says Vicente Martín, a physicist at the Technical University of Madrid. Nature doi:10.1038/nature.2012.11849 References Patel, K. A. et al. Phys. Rev. X 2, 041010 (2012). Article Show context Eraerds, P., Walenta, N., Legré, M., Gisin, N. Zbinden, H. N. J. Phys. 12, 063027 (2010). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Your GPU's “Fingerprint” Could Lead to New Security Methods
http://h30565.www3.hp.com/t5/Feature-Articles/Your-GPU-s-Fingerprint-Could-Lead-to-New-Security-Methods/ba-p/8418 Your GPU's “Fingerprint” Could Lead to New Security Methods by Andy Patrizio (apatrizio) on 29-10-2012 08:00 AM starlight_dreamstimefree_141720.jpg In the online world, a World of Warcraft account can be worth serious money. With such an incentive, malware is set to steal your WoW login and password, should you become infected. To protect an account, WoW users have the option of purchasing an authenticator for a minor fee of $6.50. Of course, if you lose the authenticator or if it breaks, poof! goes your game access. Security veterans recognize this as two-factor authentication: a password and a separate, physical security device that the owner must have in their possession. While two-factor authentication can greatly increase your security, it also represents another point of vulnerability because you can always lose the device. Researchers in Europe have come up with an alternative. Instead, your computer's graphics processor unit (GPU) would be the authenticator, identifying a user by tying him to his specific GPU. The Physically Unclonable Functions Found in standard PC Components Project, or PUFFIN, say that every GPU has a unique and defining set of characteristics that make each GPU as unique and individual as a snowflake or a fingerprint. These differences are known as a physical unclonable functions (PUF); they can only be detected by software and by knowing where to look. This is how the PUFFIN group found the uniqueness to GPU memory in the first place, since it was looking for PUFs. The PUFFIN group, which specializes in cryptography, uses GPUs for number crunching, since these chips are essentially giant math co-processors. To get higher performance, the PUFFIN group designed an assembly language application and gained access to the static RAM on the GPU. One of the things they did was look at the contents of a GPU’s SRAM to see if the previous contents were still there, explained Dr. Tanja Lange, a professor in the department of Mathematics and Computer Science at Technische Universiteit Eindhoven, in Eindhoven, Holland. What they found looked promising for a PUF. To further investigate the behavior, they joined forces with two other universities, including the University of Chicago, and Intrinsic-ID, a Dutch company specializing in PUFs. The physical layout of SRAM cells is such that each of them falls to a 0 or 1 when unpowered, Dr. Lange explained. The choice depends on tiny manufacturing differences. When the SRAM is powered on, these values stay until drivers overwrite them with data. Like fingerprints, the behavior of falling to 0 or to 1 is not perfectly deterministic, but we know how to deal with noisy data. It was known already that in general SRAM can be used to build PUFs, she said. What this means is the 0s and 1s of SRAM have a unique arrangement to each GPU – which enables your GPU to become your authenticator. A WoW gamer won't need the separate physical authenticator any more, as her GPU can handle authentication for them. Or, on the flip side, a GPU could be the validation that allows only a certain PC to access a certain resource. For example, C-level executives could have their own secured, private space on a corporate network which only they could access, with their PC's GPU acting as authentication. No other PC would be able to access that network space. The PUFFIN group managed to dig into the GPUs to read out the uninitialized memory. It could extract the information from Nvidia GPUs using Nvidia's CUDA language for programming the GPU processor. The researchers have not experimented with GPUs from AMD or Intel yet but they hope to find a similar scenario. In principle, this should apply to anything out there, said Daniel J. Bernstein, a professor of computer science at the University of Illinois at Chicago and also a part-time professor at Technische Universiteit Eindhoven. Whether we can get access from software is a new game for every processor. There's no reason things should be different for AMD and Intel. There should be the same variability in static RAM. Whether we can access it is another question. GPU makers don't want anyone looking at the initialization memory, so it took some effort on the part of the Eindhoven group to get at the memory. Access [to the GPU SRAM] has to be integrated with OS kernel and hypervisor. There's still more steps to be taken. What we have now is a demo that GPUs have this identification information we can access and there are no clear obstacles to using it as security, said Bernstein. But he adds that it's not something that can be dropped into products today. Based on what we've seen so far, it is impossible for anyone to clone the card, said Lange. But turning identity into a full-fledged security mechanism is several steps we have to go through. Indeed, it will require an industry-wide standard
Re: [cryptography] best way to create entropy?
- Forwarded message from Naslund, Steve snasl...@medline.com - From: Naslund, Steve snasl...@medline.com Date: Thu, 11 Oct 2012 23:27:56 -0500 To: na...@nanog.org Subject: RE: best way to create entropy? I know that a popular method for generating random bit streams is to take radio (stellar) noise and convert it into a digital bit stream. Very popular among crypto geeks. Steven Naslund -Original Message- From: Dan White [mailto:dwh...@olp.net] Sent: Thursday, October 11, 2012 10:55 PM To: Jonathan Lassoff Cc: North American Network Operators Group Subject: Re: best way to create entropy? On 10/11/12 17:08 -0700, Jonathan Lassoff wrote: On Thu, Oct 11, 2012 at 5:01 PM, shawn wilson ag4ve...@gmail.com wrote: in the past, i've done many different things to create entropy - encode videos, watch youtube, tcpdump -vvv /dev/null, compiled a kernel. but, what is best? just whatever gets your cpu to peak or are some tasks better than others? Personally, I've used and recommend this USB stick: http://www.entropykey.co.uk/ Internally, it uses diodes that are reverse-biased just ever so close to the breakdown voltage such that they randomly flip state back and forth. +1. -- Dan White - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-dev] Even more notes on relay-crypto constructions
by c, so that seems like something like 80 instructions per byte for a naive implementation. There are still probably more optimizations to be done, especially if we have wacky SIMD features to play with, or we can combine some of the operations above into single ones. Dynamic multiple issue and such CPU architectural tricks might get it down even more. Nevertheless, it still looks like it'd be expensive enough getting GF(2^128) right to make GF(2^128) unattractive. Still, maybe somebody should hack this up for the public good, whether we turn out to need GF(2^128) or not. As a further wrinkle with GF(2^128), OpenSSL doesn't seem to actually expose its multiply in GF(2^128) functions as far as I can tell: we would need to snarf such code from elsewhere. Oh! ARMv8 has an optional crypto instruction set that supports AES, SHA256, and GF(2^128) multiplication [ARMv8]. If it looks like most of the ARMs we care about are going to get it, that could factor into our planning. I won't believe claims that AES hardware will be widely available until it actually is present in every new processor from a major manufacturer. Agreed. -- Nick ___ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-dev] Even more notes on relay-crypto constructions
insecurity that I'm aware of are that although it has fewer known flaws than AES, it has received less attention than AES, therefore is likelier to _unsuspected_ problems. The counterargument there is that there _are_ several dozen cryptographers who have tried to attack it (or attack reduced-round variants of it), several of whom have also done successful results against AES. [DJB-Comm] Per-key setup time is basically nonexistent. Per-key setup time consists of one vector addition (of the first half of the key into the constants). (DJB's timing reports in http://cr.yp.to/papers.html#chacha repeat this operation for each block, but I would rather do it once per key if at all possible.) There are a lot of constructions out there that want to do multiplication in GF(2^128) as a basic operation. That turns out to be less than totally straightforward, though. On newer intel chips, you've got a multiply without carry instruction that can supposedly let you get to around 2 cycles per byte. On other platforms, you're reduced to worse trickery to try to get good performance without timing side-channels, for an amount of trickery dependent on what operation you're trying to do exactly. The easiest GF(2^128) operation to implement safely and quickly is multiplication by a known compile-time value. (It's easy enough that even I could do it.) Next easiest is multiply a large number of values by the same run-time-fixed value -- you do precomputation on the value in order to generate some tables. (The scary, fast variants use big tables; the still-a-little-scary variants use 256-byte tables, and get performance on high-end Intel boxes around 7-10 cycles per byte when doing GCM.) Full-on multiplication of two arbitrary GF(2^128) values is slowest still. The obvious way to implement GF(2^128) multiplication of a large number of secret inputs y by one learned-at-runtime secret c is: * Compute a table of c*X^i for i = 0, ..., 127. (This table takes 128*128 bits, or 2048 bytes. Multiplication by X is easy and tolerably fast.) * For each input y (= y_0*X^0 + ... + y_127*X^127, with the y_i in GF(2)), compute y_0*(c*X^0) + ... + y_127*(c*X^127). (You've done this step for Pynchon Gate already; hopefully that runs in constant time.) As a further wrinkle with GF(2^128), OpenSSL doesn't seem to actually expose its multiply in GF(2^128) functions as far as I can tell: we would need to snarf such code from elsewhere. Oh! ARMv8 has an optional crypto instruction set that supports AES, SHA256, and GF(2^128) multiplication [ARMv8]. If it looks like most of the ARMs we care about are going to get it, that could factor into our planning. I won't believe claims that AES hardware will be widely available until it actually is present in every new processor from a major manufacturer. Robert Ransom ___ tor-dev mailing list tor-...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] CryptoParty Handbook
redundant data and carry on even if some writes fail, such as RAID-based file systems * file systems that make snapshots, such as Network Appliance's NFS server * file systems that cache in temporary locations, such as NFS version 3 clients * compressed file systems In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount). The wipe man page says Journaling filesystems (such as Ext3 or ReiserFS) are now being used by default by most Linux distributions. No secure deletion program that does filesystem-level calls can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is better implemented in the operating system. Some people see this concern as hypothetical, but it's pretty easy to test with loopback mounting. I just made a 100 MB file, initialized it with zeroes, created an ext4 filesystem in it, and loopback mounted the filesystem. Then I created several very large text files with repeating, easy-to-recognize contents, and then deleted the files with shred -u. It was still possible to find a small number of copies of the text file contents in the underlying storage file afterward -- probably because of data journaling in ext4. The book spends several pages describing how to make GUI interfaces for wipe and shred under GNOME, remarks that wipe is a little more secure than shred, and doesn't mention that (according to their own official documentation) neither program can be assumed to work properly on a modern system! :-( Things like this make me worry that this book needs some more work. -- Seth Schoen sch...@eff.org Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] CryptoParty Handbook
- Forwarded message from Asher Wolf asherw...@cryptoparty.org - From: Asher Wolf asherw...@cryptoparty.org Date: Fri, 05 Oct 2012 13:26:09 +1000 To: liberationt...@lists.stanford.edu Subject: Re: [liberationtech] CryptoParty Handbook User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Reply-To: liberationtech liberationt...@lists.stanford.edu At the moment, public edit function on the crowd-sourced portal for the CryptoParty Handbook has been removed due to ongoing attempts at vandalism of the document. If you would like to contribute, make edits or alterations, please either email me at: asherw...@cryptoparty.org On 5/10/12 12:11 PM, Nick M. Daly wrote: Andrew Mallis o...@ideograph.ca writes: This 392 page, Creative Commons licensed handbook is designed to help those with no prior experience to protect their basic human right to Privacy in networked, digital domains... Most importantly however this handbook is intended as a reference for use during Crypto Parties. Andrew, this is great work. I started reading it on the bus today and found a few bits that could be updated or clarified. The numbers are page numbers. - [ ] 5: Remove the link to opensourceecology.org. - [ ] 7: as many or as few as two people - an incomplete thought. - [ ] 12: add the you've got no business in my business argument: Privacy exists because part of the human experience is personal, intimate, even. Robbing people of that devalues human life and experience. - [ ] 21: give time values to password lengths and predictability. e.g.: a completely random 8 character password provides up to 12 hours of privacy after your password is exposed, if attacked by one average blackhat [0]. Attacked by a script kitten? Maybe longer, depending on the strength of their graphics card(s). Attacked by a nation-state? It's probably seconds. - [ ] 22: add grc.com/passwords as a link for fully random passwords. - [ ] 25: Lower threatenable area: consider POP3 for your email to move it off the easily accessible servers as quickly as possible. If it's inconvenient for you, it'll be even more so for your attackers. Is there a preferred contribution method? I didn't see one mentioned in the PDF, but I probably missed it. Nick 0: http://arstechnica.com/security/2012/08/passwords-under-assault/ -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] cjdns review
On Fri, Oct 05, 2012 at 10:58:40AM +0200, Guus Sliepen wrote: 1. Measure. Don't speculate. I found a benchmark here: https://github.com/cjdelisle/cjdns/blob/master/rfcs/benchmark.txt So it seems that is not as slow as I suspected: it can forward packets at a rate of 7 Gbit/s on an Opteron 6128. So for a VPN or overlay network that is OK. But for their intended goal of being able to work completely independent of, and a replacement for, an existing Internet, it does require an awful lot of CPU power on routers. Current routers have memory lookups on expensive (CAM) route memory, so if the logic is easy enough to cast into ASIC (or even an FPGA) the resulting packet forwarding rate might be actually quite impressive for amount of silicon and power footprint. 4. Perhaps most importantly, the public-key computation (Curve25519) is reusable (see crypto_box_afternm()) whenever the sender-receiver set is the same. This means that specifying crypto_box() for every packet does _not_ imply public-key cryptography for every packet. I did not know of this feature; and delving into the source code of cjdns, crypto_box_afternm() is indeed what is being used. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Jim Klimov jimkli...@cos.ru - From: Jim Klimov jimkli...@cos.ru Date: Thu, 04 Oct 2012 13:44:21 +0400 To: z...@lists.illumos.org CC: Eugen Leitl eu...@leitl.org Subject: Re: ZFS dedup? hashes (Re: [cryptography] [zfs] SHA-3 winner announced) Reply-To: jimkli...@cos.ru Organization: JSC COS/HT User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 2012-10-03 18:52, Eugen Leitl wrote: I infer from your comments that you are focusing on the ZFS use of a hash for dedup? (The forward did not include the full context). A forged collision for dedup can translate into a DoS (deletion) so 2nd pre-image collision resistance would still be important. This subject was discussed a few months ago on zfs-discuss, I believe the thread history may be here: http://mail.opensolaris.org/pipermail/zfs-discuss/2012-July/051865.html Regarding the dedup-collision attacks, the problem is such: zfs dedup uses a checksum of a low-level block of ZFS data (which has passed compression, and encryption in case of Solaris 11). The final on-disk blocks with whatever contents are checksummed as part of ZFS integrity verification (lack of bitrot), and the stronger of these checksums can be used as keys into the deduplication table (DDT) if enabled for these datasets and used upon write (i.e. prepare the final block contents, make checksum, find it in DDT, increment the DDT entry counter or make a new DDT entry with counter=1). The DDT is shared by many datasets on the pool, and accounting of used/free space becomes interesting, but the users have little if any ways to know whether their data was deduped (might infer that from changes of used/free space, but one can never be sure if HIS recently written file was involved). The block is several sectors in size, now ranging from 512b to 128Kb. In order to craft an attack on dedup you should: 1) Know what data will be written by the victim - exactly, including raw data, compression algo, encryption, etc.; 2) Create a block with forged data which has the same checksum (as used by this block's metadata on disk - currently sha256, maybe more as a result of Saso's work); 3) Be the very first writer into this pool that creates a block with this hash and enters it into the DDT. Reality is that any co-user of space on the deduped pool might do this. However, impracticality is that you need such intimate access to the victim's source data and system setup details, that you might just as well be the storage admin who can just corrupt and overwrite the victim's userdata block with whatever trash. Also, as far as dedup goes, a simple setting of verify=on requires comparison of on-disk block with the one ZFS is going to save (given they have same checksums, maybe size, and one is already in DDT), and if these two don't match ZFS should just write the new block non-deduped. The attack would at most waste space on the storage if the victim's data is indeed dedupable and ultimately many identical copies are saved, but the forged block only sits and occupies the DDT entry. Incidentally a somewhat related problem with dedup (probably more in cloud storage than local dedup of storage) is that the dedup function itself can lead to the confirmation or even decryption of documents with sufficiently low entropy as the attacker can induce you to store or directly query the dedup service looking for all possible documents. eg say a form letter where the only blanks to fill in are the name (known suspected) and a figure (1,000,000 possible values). What sort of attack do you suggest? That a storage user (attacker) pre-creates a million files of this form with filled-in data? Having no access to ZFS low-level internals and metadata, the end-user has no reliable way of knowing that a particular file got deduped. (And it's not files, but component blocks, to be exact). And if an admin does that, he might just as well read the victim's file directly (on non-encrypted pool). Or did I misunderstand your point? Also if there is encryption there are privacy and security leaks arising from doing dedup based on plaintext. And if you are doing dedup on ciphertext (or the data is not encrypted), you could follow David's suggestion of HMAC-SHA1 or the various AES-MACs. In fact I would suggest for encrypted data, you really NEED to base dedup on MACs and NOT hashes or you leak and risk bruteforce decryption of plaintext by hash brute-forcing the non-encrypted dedup tokens. I am not a cypher expert to even well decipher this part ;) HTH, //Jim Klimov - 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 ___ cryptography mailing list
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Sašo Kiselkov skiselkov...@gmail.com - From: Sašo Kiselkov skiselkov...@gmail.com Date: Thu, 04 Oct 2012 15:19:59 +0200 To: z...@lists.illumos.org CC: Eugen Leitl eu...@leitl.org Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Reply-To: z...@lists.illumos.org On 10/04/2012 02:41 PM, Eugen Leitl wrote: - Forwarded message from David McGrew (mcgrew) mcg...@cisco.com - From: David McGrew (mcgrew) mcg...@cisco.com Date: Thu, 4 Oct 2012 12:19:55 + To: Eugen Leitl eu...@leitl.org, cryptography@randombit.net cryptography@randombit.net Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) user-agent: Microsoft-MacOutlook/14.2.1.120420 It would be redundant to use HMAC-SHA256 in conjunction with authenticated encryption modes like those mentioned on the Oracle webpage that I mentioned (AES-GCM and AES-CCM).Perhaps what you meant to say is that when those modes are used, that SHA256 is used as the ZFS data-integrity checksum? Or is it the case that the data-integrity checksum can use a keyed message authentication code? If we get around to implementing encryption in Illumos, we would most likely go the same route. Thanks for your insights, though, they are certainly valuable. Is there any public specification for how cryptography is used in either the Sun/Oracle version or the Illumos version of ZFS? I'm not really sure how Oracle implemented their stuff in detail. I know that they use the block-level checksum to also authenticate the data, but then they also say that you can perform a block validation even if you don't have the encryption key. Best talk to Oracle about the details on that. Illumos' ZFS doesn't have encryption, so block authentication isn't important for us. Cheers, -- Saso --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Sašo Kiselkov skiselkov...@gmail.com - From: Sašo Kiselkov skiselkov...@gmail.com Date: Thu, 04 Oct 2012 15:39:18 +0200 To: z...@lists.illumos.org CC: Eugen Leitl eu...@leitl.org Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 On 10/04/2012 02:41 PM, Eugen Leitl wrote: - Forwarded message from Adam Back a...@cypherspace.org - From: Adam Back a...@cypherspace.org Date: Thu, 4 Oct 2012 13:39:35 +0100 To: Eugen Leitl eu...@leitl.org Cc: cryptography@randombit.net, Jim Klimov jimkli...@cos.ru, Adam Back a...@cypherspace.org Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) User-Agent: Mutt/1.5.21 (2010-09-15) On Thu, Oct 04, 2012 at 11:47:08AM +0200, Jim Klimov wrote: [decrypting or confirming encrypted or ACLed documents via dedup] eg say a form letter where the only blanks to fill in are the name (known suspected) and a figure (1,000,000 possible values). What sort of attack do you suggest? That a storage user (attacker) pre-creates a million files of this form with filled-in data? The otherway around - let the victim store their confidential but low entropy file. Then the attacker writes all permutations, and does timing or disk free stats or other side channel to tell which was the correct guess. Since block dedup happens at transaction group (txg) commit intervals (i.e. the blocks aren't dedup'ed in memory, but only at txg commit to stable storage), in order to get reliable results (from observing storage behavior) you'd need to probe an entirely unloaded system extremely slowly (a few blocks per txg interval at best). Needless to say this is extremely optimistic and is still highly impractical. Any kind of other chatter on system (other processes doing something) will crush any hopes of this kind of attack yielding any useful data. Moreover, dedup is typically used in large storage systems (NAS/SAN) where one rarely gets local access (most users access the system via some file-level sharing protocol, e.g. NFS, or block-level, such as iSCSI or FC), which cover the inner workings of the storage system with a thick and heavy protocol blanket. Given that one can get a private key out of an RSA private key holding server by being another unprivileged process, based on cache lines, timing etc it seems to me likely you would be able to tell dedup. And maybe you can dedup lots of times, eg create, delete, wait for space reclaim, write again (to get better accuracy stats from having lots of timing samples.) As mentioned above, you'll be probably limited by txg commit intervals, making this attack highly impractical. Cheers, -- Saso - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced)
- Forwarded message from Jim Klimov jimkli...@cos.ru - From: Jim Klimov jimkli...@cos.ru Date: Thu, 04 Oct 2012 19:12:16 +0400 To: z...@lists.illumos.org CC: Pawel Jakub Dawidek p...@freebsd.org, Eugen Leitl eu...@leitl.org Subject: Re: [cryptography] ZFS dedup? hashes (Re: [zfs] SHA-3 winner announced) Reply-To: jimkli...@cos.ru Organization: JSC COS/HT User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 2012-10-04 18:00, Pawel Jakub Dawidek wrote: Invalidating one side channel doesn't mean there aren't more. It is safer to assume there are more. True. One security project I was affiliated with began with an axiom: a networked system is considered broken into, and the project was about providing safe communications - necessarily without traditional networking gear/interfaces - between internal data-processing subnets and those required to face the evil internet and thus tainted and corrupted ;) Another one that comes to my mind is to wait until the load is small and observe with df(1) if the used space grows when we write and by how much. You can even do binary search by writing many possible blocks and observing if the space grew as much as it should. If not, maybe we have a hit and we can split our blocks in half and retry, etc. This would work over NFS just fine. IMHO your dataset's (NFS share's) used space should grow regardless of dedup in action. However, if your viewpoint includes the parent pool, something might be inferred indeed. But as Saso said, you need a quiet pool doing nothing else but your cracking task for the duration of TXG interval, which is unlikely already - more so on shared cloud storage. //Jim - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] SHA-3 winner announced
- Forwarded message from Sašo Kiselkov skiselkov...@gmail.com - From: Sašo Kiselkov skiselkov...@gmail.com Date: Wed, 03 Oct 2012 15:39:39 +0200 To: z...@lists.illumos.org CC: Eugen Leitl eu...@leitl.org Subject: Re: [cryptography] [zfs] SHA-3 winner announced User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Well, it's somewhat difficult to respond to cross-posted e-mails, but here goes: On 10/03/2012 03:15 PM, Eugen Leitl wrote: - Forwarded message from Adam Back a...@cypherspace.org - From: Adam Back a...@cypherspace.org Date: Wed, 3 Oct 2012 13:25:06 +0100 To: Eugen Leitl eu...@leitl.org Cc: cryptography@randombit.net, Adam Back a...@cypherspace.org Subject: Re: [cryptography] [zfs] SHA-3 winner announced User-Agent: Mutt/1.5.21 (2010-09-15) (comment to Saso's email forwarded by Eugen): Well I think it would be fairer to say SHA-3 was initiatied more in the direction of improving on the state of art in security of hash algorithms [snip] In that you see the selection of Keecak, focusing more on its high security margin, and new defenses against existing known types of attacks. At no point did I claim that the NIST people chose badly. I always said that NIST's requirements need not align perfectly with ZFS' requirements. If the price of that is slower, so be it - while fast primitives are very useful, having things like MD5 full break and SHA-1 significant weakening take the security protocols industry by surprise is also highly undesirable and expensive to fix. To some extent for the short/mid term almost unfixable given the state of software update, and firmware update realities. Except in ZFS, where it's a simple zfs set command. Remember, Illumos' ZFS doesn't use the hash as a security feature at all - that property is not the prime focus. So while I am someone who pays attention to protocol, algorithm and implementation efficiency, I am happy with Keecak. ZFS is not a security protocol, therefore the security margin of the hash is next to irrelevant. Now that is not to say that it's entirely pointless - it's good to have some security there, just for the added peace of mind, but it's crazy to focus on it as primary concern. And CPUs are geting faster all the time, the Q3 2013 ivybridge (22nm) intel i7 next year is going to be available in 12-core (24 hyperthreads) with 30GB cache. Just chuck another core at if if you have problems. ARMs are also coming out in more cores. Aaah, the good old but CPUs are getting faster every day! argument. So should people hold off for a few years before purchasing new equipment for problems they have now? And if these new super-duper CPUs are so much higher performing, why not use a more efficient algo and push even higher numbers with them? If I could halve my costs by simply switching to a faster algorithm, I'd do it in a heartbeat! And AMD 7970 GPU has 2048 cores. Are you suggesting we run ZFS kernel code on GPUs? How about driver issues? Or simultaneous use by graphical apps/games? Who's going to implement and maintain this? It's easy to propose theoretical models, but unless you plan to invest the energy in this, it'll most likely remain purely theoretical. For embedded and portable use, a reasonably fast and energy frugal 32-bit or 64-bit processor is really cheap these days. OK I know there's always a market for 8-bit processors, on the extreme cheap/low power end, but the validity of the cost complaint is diminishing even there. My point in recommending a higher-speed hash is not for low-power systems - these wouldn't even come near dedup for the foreseeable future. Cheers, -- Saso - 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [tahoe-dev] Tahoe-LAFS Weekly Conference Call summary 2012-08-07
/pycryptopp/ticket/46# Add combined AES+XSalsa20 cipher module https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1679# Nondeterministic NoSharesError for direct CHK download in 1.8.3 and 1.9.1 ¹ https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Bibliography#CipherCombiners tickets mentioned in this letter: https://tahoe-lafs.org/trac/pycryptopp/ticket/46# Add combined AES+XSalsa20 cipher module ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Behind Intel's New Random-Number Generator
http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 Behind Intel's New Random-Number Generator The random-number generator uses digital circuits to stump the smartest hackers By Greg Taylor, George Cox / September 2011 Image: Carl DeTorres Imagine that it's 1995 and you're about to make your very first online purchase. You open your Netscape browser, sipping coffee as the home page slowly loads. You then navigate to Amazon.com, a new online bookstore your friend told you about. As you proceed to make your purchase and enter your payment information, the address your browser points to changes from one starting with http to one that begins with https. That signals that your computer has established an encrypted connection with Amazon's server. This allows you to send credit card information to the server without worrying that an identity thief will intercept the transmission. Unfortunately, your first online transaction was doomed from the start: It will soon be discovered that the supposedly secure transfer protocol your browser just followed wasn't very secure after all. The problem was that the secret keys Netscape was using weren't random enough. They were strings of only 40 bits, meaning there were around a trillion possible number combinations. That may seem like a lot, but hackers were able to break these codes, even with mid-1990s computer speeds, in about 30 hours. The nominally random number Netscape used to form a secret key was based on just three values—time of day, process identification number, and parent-process identification number—all of them predictable. This allowed the attackers to reduce the number of keys that they needed to try, and to find the right one much sooner than Netscape had anticipated. image of lava lamp Photo: iStockphoto A Whole Lot of Lava Lavarand was developed in 1996 to generate randomness from lava lamps. Over a million people grabbed numbers from the Lavarand website. Netscape's programmers would have loved to use a completely random number to form the encryption key, but they had a hard time figuring out how to come up with one. That's because digital computers are always in well-defined states, which change only when the programs they are running tell them to change. The best you can often do with a computer is to simulate randomness, generating what are called pseudorandom numbers by using some sort of mathematical procedure. A set of such numbers may at first glance look perfectly random, but somebody else using the same procedure could easily generate exactly the same set of numbers, which often makes them a poor choice for encryption. Researchers have managed to devise pseudorandom-number generators that are considered cryptographically secure. But you must still start them off using a special seed value; otherwise, they'll always generate the same list of numbers. And for that seed, you really want something that's impossible to predict. Fortunately, it's not hard to harvest truly unpredictable randomness by tapping the chaotic universe that surrounds a computer's orderly, deterministic world of 1s and 0s. But how exactly do you do that? For several years, you could find an online source of random numbers, called Lavarand. It got its numbers from the pictures a computer took of the waxy blobs churning away inside lava lamps. More sophisticated hardware-based systems use quantum-mechanical phenomena, such as photons striking a half-silvered mirror, as a basis for generating random numbers. You can even get an ordinary unassisted computer to produce random numbers based on erratic events taking place within its own mundane hardware—the precise timing of keystrokes, for example. But to get many of these numbers, you'd need to hammer away at a lot of keys. We and our colleagues at Intel think this should be easier. That's why for more than a decade now, many of our company's chip sets have included an analog, hardware-based random-number generator. The problem is that its analog circuitry squanders power. Also, it's hard to keep that analog circuitry working properly as we improve our fabrication processes. That's why we have now developed a new and entirely digital system that allows a microprocessor to produce a copious stream of random values without those difficulties. Soon it will be coming to a processor near you. chart, uncertain circuits UNCERTAIN CIRCUITS: When transistor 1 and transistor 2 are switched on, a coupled pair of inverters force Node A and Node B into the same state [left]. When the clock pulse rises [yellow, right], these transistors are turned off. Initially the output of both inverters falls into an indeterminate state, but random thermal noise within the inverters soon jostles one node into the logical 1 state and the other goes to logical 0. Click on image for enlargement. Intel's first attempt to help an average computer produce better random numbers came in 1999, when the company
Re: [cryptography] [zfs] Fwd: Re: zfs encryption
- Forwarded message from Richard Lowe richl...@richlowe.net - From: Richard Lowe richl...@richlowe.net Date: Sat, 21 Jul 2012 22:08:45 -0400 To: r...@gentoo.org, z...@lists.illumos.org Subject: Re: [zfs] Fwd: Re: zfs encryption Reply-To: z...@lists.illumos.org hg clone ssh://a...@hg.opensolaris.org//hg/zfs-crypto/gate -- Rich --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tahoe-dev] “On the limits of the use cases for authenticated encryption”
- Forwarded message from Zooko Wilcox-O'Hearn zo...@zooko.com - From: Zooko Wilcox-O'Hearn zo...@zooko.com Date: Wed, 11 Jul 2012 15:08:33 -0300 To: Tahoe-LAFS development tahoe-...@tahoe-lafs.org Subject: Re: [tahoe-dev] “On the limits of the use cases for authenticated encryption” Reply-To: Tahoe-LAFS development tahoe-...@tahoe-lafs.org I've been thinking about this more, including re-reading BenL's post to tahoe-dev. I was inspired by hearing that Tahoe-LAFS's use case had been discussed at the recent Directions in Authenticated Ciphers workshop: http://hyperelliptic.org/DIAC/ I've decided that I wasn't really on the right track to say Authenticated Encryption is useless for Tahoe-LAFS use cases, and instead I should say We need *public key* Authenticated Encryption instead of *symmetric key* Authenticated Encryption for Tahoe-LAFS use cases. • symmetric-key Authenticated Encryption = Message Authentication Code + cipher • signcryption = digital signature + public key encryption • Tahoe-LAFS mutable = digital signature + cipher • Tahoe-LAFS immutable = data identified by its secure hash + cipher Regards, Zooko ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] can the German government read PGP and ssh traffic?
On Fri, May 25, 2012 at 11:19:33AM -0700, Jon Callas wrote: My money would be on a combination of traffic analysis and targeted malware. We know that the Germans have been pioneering using targeted malware against Skype. Once you've done that, you can pick apart anything else. Just a simple matter of coding. Unrelated, IIRC Microsoft changed the architecture of supernodes to allow for lawful interception with Skype. It would be interesting to see inasmuch an open source version of Skype would want to evade that infrastructure, while asserting interoperability with legacy users. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] John Nash’s Letter to the NSA
http://agtb.wordpress.com/2012/02/17/john-nashs-letter-to-the-nsa/ John Nash’s Letter to the NSA February 17, 2012 by Noam Nisan The National Security Agency (NSA) has recently declassified an amazing letter that John Nash sent to it in 1955. It seems that around the year 1950 Nash tried to interest some US security organs (the NSA itself was only formally formed only in 1952) in an encryption machine of his design, but they did not seem to be interested. It is not clear whether some of his material was lost, whether they ignored him as a theoretical professor, or — who knows — used some of his stuff but did not tell him. In this hand-written letter sent by John Nash to the NSA in 1955, he tries to give a higher-level point of view supporting his design: In this letter I make some remarks on a general principle relevant to enciphering in general and to my machine in particular. He tries to make sure that he will be taken seriously: I hope my handwriting, etc. do not give the impression I am just a crank or circle-squarer. My position here is Assist. Prof. of Math. My best known work is in game theory (reprint sent separately). He then goes on to put forward an amazingly prescient analysis anticipating computational complexity theory as well as modern cryptography. In the letter, Nash takes a step beyond Shannon’s information-theoretic formalization of cryptography (without mentioning it) and proposes that security of encryption be based on computational hardness — this is exactly the transformation to modern cryptography made two decades later by the rest of the world (at least publicly…). He then goes on to explicitly focus on the distinction between polynomial time and exponential time computation, a crucial distinction which is the basis of computational complexity theory, but made only about a decade later by the rest of the world: So a logical way to classify enciphering processes is by t he way in which the computation length for the computation of the key increases with increasing length of the key. This is at best exponential and at worst probably at most a relatively small power of r, ar^2 or ar^3, as in substitution ciphers. He conjectures the security of a family of encryption schemes. While not totally specific here, in today’s words he is probably conjecturing that almost all cipher functions (from some — not totally clear — class) are one-way: Now my general conjecture is as follows: for almost all sufficiently complex types of enciphering, especially where the instructions given by different portions of the key interact complexly with each other in the determination of their ultimate effects on the enciphering, the mean key computation length increases exponentially with the length of the key, or in other words, the information content of the key. He is very well aware of the importance of this “conjecture” and that it implies an end to the game played between code-designers and code-breakers throughout history. Indeed, this is exactly the point of view of modern cryptography. The significance of this general conjecture, assuming its truth, is easy to see. It means that it is quite feasible to design ciphers that are effectively unbreakable. As ciphers become more sophisticated the game of cipher breaking by skilled teams, etc., should become a thing of the past. He is very well aware that this is a conjecture and that he cannot prove it. Surprisingly, for a mathematician, he does not even expect it to be solved. Even more surprisingly he seems quite comfortable designing his encryption system based on this unproven conjecture. This is quite eerily what modern cryptography does to this day: conjecture that some problem is computationally hard; not expect anyone to prove it; and yet base their cryptography on this unproven assumption. The nature of this conjecture is such that I cannot prove it, even for a special type of ciphers. Nor do I expect it to be proven. All in all, the letter anticipates computational complexity theory by a decade and modern cryptography by two decades. Not bad for someone whose “best known work is in game theory”. It is hard not to compare this letter to Goedel’s famous 1956 letter to von Neumann also anticipating complexity theory (but not cryptography). That both Nash and Goedel passed through Princeton may imply that these ideas were somehow “in the air” there. ht: this declassified letter seems to have been picked up by Ron Rivest who posted it on his course’s web-site, and was then blogged about (and G+ed) by Aaron Roth. Edit: Ron Rivest has implemented Nash’s cryptosystem in Python. I wonder whether modern cryptanalysis would be able to break it. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tahoe-dev] pycryptopp benchmarks
- Forwarded message from Brian Warner war...@lothar.com - From: Brian Warner war...@lothar.com Date: Thu, 22 Mar 2012 12:09:40 -0700 To: tahoe-...@tahoe-lafs.org Subject: Re: [tahoe-dev] pycryptopp benchmarks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 Reply-To: Tahoe-LAFS development tahoe-...@tahoe-lafs.org On 3/21/12 11:00 AM, Zooko Wilcox-O'Hearn wrote: On 64-bit servers, the it costs something around 10 *nanoseconds* per byte, and on François's little low-power ARM box, it costs about 200 nanoseconds per byte. FYI, djb and friends just published a paper about high-speed crypto on ARM processors with the NEON vector instruction set (which includes the iPad 1 and iPhone 4), specifically the NaCl algorithms (Salsa20, Poly1305, Curve25519, and Ed25519). They got encryption down to 5.6 CPU cycles per byte. http://cr.yp.to/highspeed/neoncrypto-20120320.pdf cheers, -Brian ___ tahoe-dev mailing list tahoe-...@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [info] The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say)
(yay, Bamford is back from the dead) http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/1 The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say) By James Bamford March 15, 2012 | 7:24 pm | Categories: Crypto, Cybersecurity, Miscellaneous, NSA, Paranoia, privacy, Surveillance Photo: Name Withheld; Digital Manipulation: Jesse Lenz The spring air in the small, sand-dusted town has a soft haze to it, and clumps of green-gray sagebrush rustle in the breeze. Bluffdale sits in a bowl-shaped valley in the shadow of Utah’s Wasatch Range to the east and the Oquirrh Mountains to the west. It’s the heart of Mormon country, where religious pioneers first arrived more than 160 years ago. They came to escape the rest of the world, to understand the mysterious words sent down from their god as revealed on buried golden plates, and to practice what has become known as “the principle,” marriage to multiple wives. Today Bluffdale is home to one of the nation’s largest sects of polygamists, the Apostolic United Brethren, with upwards of 9,000 members. The brethren’s complex includes a chapel, a school, a sports field, and an archive. Membership has doubled since 1978—and the number of plural marriages has tripled—so the sect has recently been looking for ways to purchase more land and expand throughout the town. But new pioneers have quietly begun moving into the area, secretive outsiders who say little and keep to themselves. Like the pious polygamists, they are focused on deciphering cryptic messages that only they have the power to understand. Just off Beef Hollow Road, less than a mile from brethren headquarters, thousands of hard-hatted construction workers in sweat-soaked T-shirts are laying the groundwork for the newcomers’ own temple and archive, a massive complex so large that it necessitated expanding the town’s boundaries. Once built, it will be more than five times the size of the US Capitol. Rather than Bibles, prophets, and worshippers, this temple will be filled with servers, computer intelligence experts, and armed guards. And instead of listening for words flowing down from heaven, these newcomers will be secretly capturing, storing, and analyzing vast quantities of words and images hurtling through the world’s telecommunications networks. In the little town of Bluffdale, Big Love and Big Brother have become uneasy neighbors. The NSA has become the largest, most covert, and potentially most intrusive intelligence agency ever. Under construction by contractors with top-secret clearances, the blandly named Utah Data Center is being built for the National Security Agency. A project of immense secrecy, it is the final piece in a complex puzzle assembled over the past decade. Its purpose: to intercept, decipher, analyze, and store vast swaths of the world’s communications as they zap down from satellites and zip through the underground and undersea cables of international, foreign, and domestic networks. The heavily fortified $2 billion center should be up and running in September 2013. Flowing through its servers and routers and stored in near-bottomless databases will be all forms of communication, including the complete contents of private emails, cell phone calls, and Google searches, as well as all sorts of personal data trails—parking receipts, travel itineraries, bookstore purchases, and other digital “pocket litter.” It is, in some measure, the realization of the “total information awareness” program created during the first term of the Bush administration—an effort that was killed by Congress in 2003 after it caused an outcry over its potential for invading Americans’ privacy. But “this is more than just a data center,” says one senior intelligence official who until recently was involved with the program. The mammoth Bluffdale center will have another important and far more secret role that until now has gone unrevealed. It is also critical, he says, for breaking codes. And code-breaking is crucial, because much of the data that the center will handle—financial information, stock transactions, business deals, foreign military and diplomatic secrets, legal documents, confidential personal communications—will be heavily encrypted. According to another top official also involved with the program, the NSA made an enormous breakthrough several years ago in its ability to cryptanalyze, or break, unfathomably complex encryption systems employed by not only governments around the world but also many average computer users in the US. The upshot, according to this official: “Everybody’s a target; everybody with communication is a target.” For the NSA, overflowing with tens of billions of dollars in post-9/11 budget awards, the cryptanalysis breakthrough came at a time of explosive growth, in size as well as in power. Established as an arm of the Department of Defense following Pearl Harbor, with the primary purpose of preventing another surprise assault, the NSA
[cryptography] airgaps in CAs
Is anyone aware of a CA that actually maintains its signing secrets on secured, airgapped machines, with transfers batched and done purely by sneakernet? -- 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] trustable self-signed certs in a P2P environment (freedombox)
I presume many here are aware of the Eben Moglen-started FreedomBox initiative, which sets out to build a Debian distro for lplug computers and similar which will package many existing tools for the end result of an end-user owned and operated, anonymizing and censorship-resistant infrastructure. One of the problems I did not see well-addressed yet is infrastructure for a cert trust network, which uses social graph information (FreedomBox is supposed to package a P2P alternative to Facebook Co) for cert fingerprint validation. Is anyone aware of existing code which caches SSL cert fingerprints and alerts when one suddenly changes, informing of a potential MITM in progress? Thanks. -- 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] New online class on Cryptography from Stanford, taught by Dan Boneh
http://www.crypto-class.org/ About The Course Cryptography is an indispensable tool for protecting information in computer systems. This course explains the inner workings of cryptographic primitives and how to correctly use them. Students will learn how to reason about the security of cryptographic constructions and how to apply this knowledge to real-world applications. The course begins with a detailed discussion of how two parties who have a shared secret key can communicate securely when a powerful adversary eavesdrops and tampers with traffic. We will examine many deployed protocols and analyze mistakes in existing systems. The second half of the course discusses public-key techniques that let two or more parties generate a shared secret key. We will cover the relevant number theory and discuss public-key encryption, digital signatures, and authentication protocols. Towards the end of the course we will cover more advanced topics such as zero-knowledge, distributed protocols such as secure auctions, and a number of privacy mechanisms. Throughout the course students will be exposed to many exciting open problems in the field. The course will include written homeworks and programming labs. The course is self-contained, however it will be helpful to have a basic understanding of discrete probability theory. The Instructor Professor Dan Boneh heads the applied cryptography group at the Computer Science department at Stanford University. Professor Boneh's research focuses on applications of cryptography to computer security. His work includes cryptosystems with novel properties, web security, security for mobile devices, digital copyright protection, and cryptanalysis. He is the author of over a hundred publications in the field and a recipient of the Packard Award, the Alfred P. Sloan Award, and the RSA award in mathematics. Professor Boneh received his Ph.D from Princeton University and joined Stanford in 1997. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Sat, Oct 29, 2011 at 08:10:38PM +1100, ianG wrote: Is there any particular reason why PCI(e) is preferred as a hardware interface? Because that's the only thing server boards typically have. Plus, PCIe is much preferable to PCI in terms of throughput (not that makes a bottleneck for a crypto accelerator) and latency. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] attacks against bitcoin
How safe is the bitcoin cryptosystem and the communication network against targeted attacks? -- 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
On Sat, Jun 11, 2011 at 02:16:55AM -, John Levine wrote: In article 021ccba9-9203-4896-8412-481b94595...@cs.columbia.edu you write: http://gcn.com/articles/2011/06/09/bitcoins-digital-currency-silk-road-charles-schumer-joe-manchin.aspx?s=gcndaily_100611 I wouldn't call bitcoins digital cash. They're more like digital tulip bulbs, or bearer shares of theglobe.com. Whatever they are, it's a self limiting problem since the bubble will burst soon enough. Unlike fiat currencies, algorithms assert limit of total volume. And the mint and transaction infrastructure is decentral, so there's no single point of control. These both are very useful properties. I don't expect Bitcoin to be it, but it is definitely a predecessor to a number of such currencies which will become practical both for machines and people. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Preserve us from poorly described/implemented crypto
On Tue, Jun 07, 2011 at 05:18:42PM -0400, Steven Bellovin wrote: Remember how well the original IBM PC clicky keyboard went over (I think I'm the only person in the US who actually liked it - veryone gave me theirs after upgrading to the newer lightweight and silent ones) Im typing on a large, heavy, clicky IBM keyboard right now... I stocked up on Model M SpaceSavers and full-size Model M's some 15 years ago. Have moved to Cherry MX (not blues, SteelSeries) gold crosspoints only a few weeks ago. -- 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
