Re: [cryptography] "Zero knowledge" as a term for end-to-end encryption
On Tue, Feb 12, 2013 at 10:27 PM, ianG wrote: > AFAIK, the term 'least authority' as used by Tahoe-LAFS folks does not > refer to 'zero knowledge' as per cryptographic protocols, but to the > concept of least authority as derived from the 'capabilities' school of > security thought. > I strongly agree that capabilities are quite important to the Tahoe-LAFS idea of least authority, and I have been following the project for many years. But I think the Tahoe style of least authority and end-to-end encryption go hand-in-hand. Tahoe's capabilities are crypto capabilities, a.k.a. "capabilities as keys". The capability tokens are the cryptographic keys themselves. This means the entire storage system is opaque to anyone who doesn't hold at least a readcap. The system, by design, deals only in ciphertext. It's ciphertext all the way down After the launch of MEGA, I've seen several sites (e.g. SpiderOak) trying to claim to be the first to have invented this concept. I don't know who did it first, but I'm pretty sure Tahoe was the first to actually get it right. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
> Those are some pretty odd stats... Camellia is almost as popular as 3DES? Well, it is what we see :). And all in all Camellia is even more popular than 3DES in our data set (there are some more less popular cipher suites for both 3DES and Camellia). It is pretty close though. Bernhard ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
Bernhard Amann writes: >We see quite a bit of ECDHE traffic at the sites that feed our notary. At the >moment, the top-3 cipher suites we see (by connection count) are >TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA and >TLS_ECDHE_RSA_WITH_RC4_128_SHA. > >We also see TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (7th most popular). If >http://www.imperialviolet.org/2012/03/02/ieecdhe.html is still correct, >RC4+ECDHE is chosen by Chrome and Firefox. AES+ECDHE is Safari and Internet >Explorer. > >The first non-AES/RC4 cipher suite is TLS_RSA_WITH_3DES_EDE_CBC_SHA (9th most >popular) followed by TLS_RSA_WITH_CAMELLIA_256_CBC_SHA. Those are some pretty odd stats... Camellia is almost as popular as 3DES? Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Feb 13, 2013, at 3:22 PM, Peter Gutmann wrote: > Bodo Moeller writes: >> On Wed, Feb 13, 2013 at 12:52 PM, Peter Gutmann >> wrote: >> >>> active use of ECC suites on the public Internet is practically nonexistent >> >> That's not entirely accurate; try www.google.com. > > It was based on the last (SSL Observatory?) scans at the time which found > about five or six servers worldwide, presumably the test servers being run by > Certicom, Red Hat, Microsoft, etc. If Google supports ECC now that'd be good, > one more site to test against. We see quite a bit of ECDHE traffic at the sites that feed our notary. At the moment, the top-3 cipher suites we see (by connection count) are TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA and TLS_ECDHE_RSA_WITH_RC4_128_SHA. We also see TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (7th most popular). If http://www.imperialviolet.org/2012/03/02/ieecdhe.html is still correct, RC4+ECDHE is chosen by Chrome and Firefox. AES+ECDHE is Safari and Internet Explorer. The first non-AES/RC4 cipher suite is TLS_RSA_WITH_3DES_EDE_CBC_SHA (9th most popular) followed by TLS_RSA_WITH_CAMELLIA_256_CBC_SHA. Bernhard ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
Bodo Moeller writes: >On Wed, Feb 13, 2013 at 12:52 PM, Peter Gutmann >wrote: > >>active use of ECC suites on the public Internet is practically nonexistent > >That's not entirely accurate; try www.google.com. It was based on the last (SSL Observatory?) scans at the time which found about five or six servers worldwide, presumably the test servers being run by Certicom, Red Hat, Microsoft, etc. If Google supports ECC now that'd be good, one more site to test against. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] "Meet the groundbreaking new encryption app set to revolutionize privacy..."
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/13 07:18, Jon Callas wrote: > Deleting the things, however, is trivial. This is a place that iOS > shines. Every file is encrypted with a unique key and if you > delete the file, it is cryptographically erased. You're correct in > that flash *is* notoriously difficult to wipe unencrypted secrets. > Fortunately for us, all the flash on iOS is encrypted and the > crypto management is easy to use. Hi Jon, I've been trying to understand the properties of iOS's file encryption with regard to recovering deleted files. As far as I can tell, it works as follows - please correct me if I'm wrong. The file's unique key (let's call it k1) is encrypted with a class key (k2) before being stored on disk. If the file uses the strongest class of protection (NSFileProtectionComplete), k2 is encrypted with a key derived from the user's passcode and the device's UID (k3) before being stored on disk, and k2 and k3 are erased from memory whenever the device is locked. After being encrypted with k3, k2 is stored in effaceable storage, and is erased from disk if the user changes the passcode. The UID never leaves the device, so a brute force attack on k3 must be run on the device itself, making the attack slow. Consider a situation where the user receives a message, stores it with NSFileProtectionComplete, and then deletes it. The device is then seized. The file (encrypted with k1) and k1 (encrypted with k2) are stored in ordinary non-effaceable storage, so they may be recoverable after deletion. If the device is seized while it's unlocked, k2 is in memory, so it may be possible to decrypt k1 and thus decrypt the file. If the device is seized while it's locked, a slow brute force attack may recover k3, so it may be possible to decrypt k2, and thus decrypt k1, and thus decrypt the file. Is that correct? If so, it seems to me that deleting the file doesn't provide much extra protection - the attacks that can decrypt the file are the same attacks that could decrypt it if it hadn't been deleted. Don't get me wrong, iOS does a really impressive job of making those attacks hard - my point is only that they're no harder for deleted files than for files that haven't been deleted. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRG9ERAAoJEBEET9GfxSfM48EH/3o0LIKNsx9OlgdtUYTs7o8b e06uc/b6sIT0Csc0AqLjKfkUWPexq1IoxuGgktlkdhY/bqWWUhRtBmvNDVqA7gjE gojdAC3QaGTOCNqIJ75toGAOtWWhzKflkfHfPeCWkWB6u6qfskEJoVvWwSjLZ9n/ VLTbKeTIKBO14/xpGKp3AVhXIOjgm8hDuPw/Y8J77FCkM6VclYXVRLLRT2vK2iP8 kyLnPUyUdcdHBmwgGII0uxOAGr8mxfjf+nwpo+USGUijImH7b0lIN4JbTOh/phOg w+/RdUsl0DvkEEwVaD3aC4yvgzpikSMkhC/0tHl04aV4Q+tKAZQt1+7JHrIxtmA= =Daje -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] Edon-R hashing and dedup
FYI, my argument was that for dedup one wants a cryptographic hash only because those are the ones that provide the best collision resistance, even though we don't need the other security properties of cryptographic hashes (not even collision resistance) if we have verify=on. Nico -- ___ 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 - From: Sašo Kiselkov Date: Wed, 13 Feb 2013 00:01:08 +0100 To: z...@lists.illumos.org CC: Pawel Jakub Dawidek , Garrett D'Amore , Richard Elling 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 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/2013 11:37 PM, Pawel Jakub Dawidek wrote: > On Tue, Feb 12, 2013 at 08:26:34PM +0100, Sašo Kiselkov wrote: >> Hi Garrett, >> >> On 02/12/2013 07:34 PM, Garrett D'Amore wrote: >>> I think security could be important here. >> >> I don't dispute that, all I'm saying is that security isn't our >> primary concern and all in all dedup doesn't really focus on it - >> the hash isn't a security feature. I'll elaborate below. > > I'm sorry, but ZFS is general purpose file system and hash function > used for dedup just has to be secure. You don't know how someone > will use the file system. By that logic, we should mandate verification with dedup, because the chance of a random collision is just on the order of 2^128:1! > Take UFS for example. When you create a file it has to write data, > create an inode and point the inode at the data. The order is very > important here. If you first create an inode then point an inode at > the data and at the end write the data it is a security bug, > because if you crash before writing the data, the inode will point > at some previous data, who knows what kind of data was there before > - maybe sshd private key? And it's possible that cosmic rays will hit your SAS interface in just the right manner so as to correctly recompute the fletcher checksum and make the in-flight BP point to a block containing sshd's private keys. Oh the horror! >> There are basically two types of attacks that you could mount >> against such a system: >> >> 1) Secret plaintext retrieval: you know the hash of the target, >> but want to retrieve some secret plaintext from the target (e.g. >> /etc/shadow). >> >> 2) Plaintext modification: you know the plaintext and the hash, >> but want to induce data corruption or alteration of the >> plaintext (e.g. modifying a known /etc/shadow to change the root >> password). >> >> We can comfortably dismiss #1 - if you know the hash of the >> secret plaintext, you've already broken into the storage system >> so deeply that you can just go ahead and read or modify the file >> anyway. > > We absolutely can not dismiss neither #1 nor #2. Only because you > cannot come up with feasible an attack vector, doesn't mean there > isn't one. > > #1 gives you ability to read file you have no permission to read. > #2 gives you ability to modify file you have no permission to > modify. > > How you get the hash in #1 or how do you trick someone to make #2 > possible is totally different story, but let me provide some > examples. > > #1 attack. You have access to company's shared storage and you can > sniff HTTP traffic. The shared storage is used to hold important > documents that are also time-stamped using external service over > HTTP. The company is happy to use this external service as TSA (and > you) sees only hashes. Now you have document's hash without deeply > breaking into storage system. If you can find collision you can get > this important document as well. I know that's not the best example > as time-stamping make sense only when hash is collision-resistant, > but you get the idea - there is no need to break into storage > system to get the hash. Except that nobody uses Edon-R-512/256 is such a manner. > #2 attack. Attend a key signing party that your victim is going to > attend. Download victim's public key and create your key with the > same weak ZFS hash as victim's public key. Fingerprint based on > strong hash of course will be different. Give your fingerprint to > the same people your victim is giving his fingerprint. Now if > someone is running ZFS with dedup and weak checksum and will > download your key first and then your victim's key your attack > succeeded. He will now be encrypting messages to your victim using > your public key. > > Another #2 attack. Certificate of some new CA is added to major > browsers. Generate certificate that matches ZFS weak hash of this > new CA cert. Start spamming or send e-mail to few selected targets. > With maildirs it should be pretty easy to make the proper alignment > so that if the new browser's version is installed and new CA cert > stored dedup instead of writing it, will point at your cert > instead. I'm sorry, but these are just pure fantasy land. The attacks you describe are so unbelievably contrived that you might as well resort to rubber hose cryptanalysis and be done with: https://xkcd.com/538/ What you propose is akin to performing dental surgery through the anus. This is exactly the sort of discussion I was hoping to avoid: armchair experts making contri
Re: [cryptography] [zfs] Edon-R hashing and dedup
- Forwarded message from Sašo Kiselkov - From: Sašo Kiselkov Date: Tue, 12 Feb 2013 23:14:36 +0100 To: z...@lists.illumos.org CC: Nico Williams , Richard Elling 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 > 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=22842876&id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl 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] Q: CBC in SSH
[Bodo Moeller (2013-02-13 14:26:56 UTC)] > On Wed, Feb 13, 2013 at 12:52 PM, Peter Gutmann > wrote: > > active use of ECC suites on the public Internet is practically nonexistent > > > > That's not entirely accurate; try www.google.com. I didn't know that. Here is more: http://www.imperialviolet.org/2011/11/22/forwardsecret.html - Harald ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Wed, Feb 13, 2013 at 12:52 PM, Peter Gutmann wrote: active use of ECC suites on the public Internet is practically nonexistent > That's not entirely accurate; try www.google.com. Bodo ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
ianG writes:
>Hmmm, I'd say that is 11 times longer than it needs to be :) Anything wrong
>with just this:
>
> CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_GCM_SHA384 =
> { 0x00, 0xXX }
The suites listed were based on a survey of what was used/supported
(admittedly, given that active use of ECC suites on the public Internet is
practically nonexistent, this was more of a "what can this implementation do"
rather than "what's being actively used"). So the suites were the common
subset that pretty much everything I could find supported. And that's the
point of the RFC, "here's a fixed subset which will (modulo odd implementation
bugs) guarantee interoperability if you use them".
>But when people come to help, they don't improve the protocol ... what they
>instead do is seek personal gratification in trivial replacement of
>algorithms. What they can't do is agree on a reasonable upgrade that takes
>care of the passage of time ("we know so much more today") with a new single
>suite, and instead compromise on rewarding everyone's ego with a little
>number somewhere.
That's pretty much exactly how these design-by-committee messes come about
(alongside groupthink and whatnot).
>It is therefore an additional hypothesis of mine that committees cannot do
>security protocols.
Yup. The ideal size for a security protocol design is about three people (to
ensure there's cross-checking). You can make it smaller if you can replace
the lost people with a lot of skill and talent (or if it's, say, a minor
tweak/obvious fix of some protocol rather than a completely new design), but
as you make it larger the committee crapification sets in.
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] ZKPs and other stuff at Zero Knowledge Systems (Re: "Zero knowledge" as a term for end-to-end encryption)
I dont think its too bad, its fairly intuitive and related english meaning also. At zero-knowlege we had a precedent of the same use: we used it as an intentional pun that we had "zero-knowledge" about our customers, and in actuality in one of the later versions we actually had a ZKP (to do with payment privacy). Well they were a licensee for Brands credentials but shamefully the early versions were just relying on no logging in a server to get privacy for the "paid up account" status necessary to establish a connection. One of the fun aspects was totting up the number of people in the company who actually understood the company name (at a mathematical / crypto level what a ZKP is), must've been a dozen perhaps out of a peak of 300 employees! My contribution to their crypto was end-to-end forward anonymity, which didnt get implemented in the "freedom network" before they closed it down to focus on selling personal firewalls via ISPs (under their new brand radialpoint.com). But the e2e forward anon concept was implemented by Zach Brown and Jerome Etienne in a ZKS skunk works project that never got deployed. And after ZKS Zach reimplemented something similar in open souce project cebolla which isnt actively developed at present now but the code is here: http://www.cypherspace.org/cebolla/ Now there is ToR and i2p which are actively developed, and I presume at this point they would both have forward anonymity. Without e2e forward anon any one of the default 3 hops in your connection could record traffic passing through and then subpoena the other hops to identify the source and destination (and web logs perhaps at the dest). E2e forward anon is pretty simple - establish a forward secret connection between User and node A call that tunnel 1. Tunnel a foward secret connection establishment through tunnel 1 between User and node B call that tunnel 2. Then tunnel a foward secret establishment through tunnel 2 between User and node C. Node A is the entry node, node C is the exit node. QED. Costs no more than the previous method, and actually as I remember the establishment is faster and more reliable also. Adam Not without some precedent, there was a company called Zero Knowledge Systems back in the early 2000s that tried to build what we now would see as a Skype or Tor competitor. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
