NSA domestic intelligence "vacuum"
WASHINGTON, D.C. — Five years ago, Congress killed an experimental
Pentagon antiterrorism program meant to vacuum up electronic data
about people in the U.S. to search for suspicious patterns. Opponents
called it too broad an intrusion on Americans' privacy, even after the
Sept. 11 terrorist attacks.
But the data-sifting effort didn't disappear. The National Security
Agency, once confined to foreign surveillance, has been building
essentially the same system.
http://online.wsj.com/article/SB120511973377523845.html?mod=todays_us_page_one
Hat tip: Bruce Schneier's blog.
–
Perry E. Metzger perry@piermont.com
———————————————————————
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Re: [FDE] Paula Parker’s, Detective Inspector of Merseyside Police, response to Child Pornography on internet
My understanding is that there are several standard ways of attacking
drive encryption:
* Asking the suspect for the encryption key
* Threatening the suspect to get the encryption key
* Brute forcing the passphrase using other information around
* Looking for the key in memory
But if you use strong passphrases and your users are torture-proof,
they're probably on a pretty good footings.
On Mar 25, 2008, at 12:31 PM, Owens Bernard B wrote:
>
> The nexus between the referenced article and this list seems to be
> when
> Detective Sergeant Geoff Conway is quoted: "Encryption and passwords
> hold no fear for us. If there is something on a computer, we will find
> it."
>
> That's news to me. The agency I work for is positively manic (and
> rightly so) to make sure that any computer that leaves our controlled
> space is fully encrypted. I think my management would be unpleasantly
> surprised to learn that our encryption can be easily swept aside by DS
> Geoff of Merseyside.
>
> In all seriousness, do such articles have any impact? Do vendors on
> this list commonly encounter people who are convinced that no FDE
> scheme
> is proof against even reasonably smart and resource-rich attacks?
>
> I don't sell FDE products; I just use and administer them every
> day. My
> users understand the need for FDE and accept the minor inconveniences
> involved as long as they have faith that it works. If my users were
> to
> read something like this and believe it, they'd get really irritated
> at
> me for making them type yet another apparently unnecessary password
> before they begin work each morning.
>
> Any thoughts?
>
> Bernard Owens
> Computer Specialist
> USTreas/IRS
>
>
>
>
> _______________________________________________
> FDE mailing list
> FDE@www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
announcing allmydata.org "Tahoe", the Least-Authority Filesystem, v1.0
ANNOUNCING Allmydata.org "Tahoe", the Least-Authority Filesystem, v1.0
We are pleased to announce the release of version 1.0 of the "Tahoe"
Least Authority Filesystem.
The "Tahoe" Least Authority Filesystem is a secure, decentralized,
fault-tolerant filesystem. All of the source code is available under
a Free Software, Open Source licence (or two).
This filesystem is encrypted and distributed over multiple peers in
such a way it continues to function even when some of the peers are
unavailable, malfunctioning, or malicious.
A one-page explanation of the security and fault-tolerance properties
that it offers is visible at:
http://allmydata.org/source/tahoe/trunk/docs/about.html
We believe that this version of Tahoe is stable enough to rely on as a
permanent store of valuable data. The version 1 branch of Tahoe will
be actively supported and maintained for the forseeable future, and
future versions of Tahoe will retain the ability to read files and
directories produced by Tahoe v1.0 for the forseeable future.
This release of Tahoe will form the basis of the new consumer backup
product from Allmydata, Inc. — http://allmydata.com .
This is the successor to Allmydata.org "Tahoe" Least Authority
Filesystem v0.9, which was released March 13, 2008 [1]. Since v0.9
we've made the following changes:
* Use an added secret for convergent encryption to better protect the
confidentiality of immutable files, and remove the publically
readable hash of the plaintext (ticket #365).
* Add a "mkdir-p" feature to the WAPI (ticket #357).
* Many updates to the Windows installer and Windows filesystem
integration.
Tahoe v1.0 produces files which can't be read by older versions of
Tahoe, although files produced by Tahoe >= 0.8 can be read by Tahoe
1.0. The reason that older versions of Tahoe can't read files
produced by Tahoe 1.0 is that those older versions require the file to
come with a publically-readable hash of the plaintext, but exposing
such a hash is a confidentiality leak, so Tahoe 1.0 does not do it.
WHAT IS IT GOOD FOR?
With Tahoe, you can distribute your filesystem across a set of
computers, such that if some of the computers fail or turn out to be
malicious, the filesystem continues to work from the remaining
computers. You can also share your files with other users, using a
strongly encrypted, capability-based access control scheme.
Because this software is the product of less than a year and a half of
active development, we do not categorically recommend it for the
storage of data which is extremely confidential or precious. However,
we believe that the combination of erasure coding, strong encryption,
and careful engineering makes the use of this software a much safer
alternative than common alternatives, such as RAID, or traditional
backup onto a remote server, removable drive, or tape.
This software comes with extensive unit tests [2], and there are no
known security flaws which would compromise confidentiality or data
integrity. (For all currently known security issues please see the
Security web page: [3].)
This release of Tahoe is suitable for the "friendnet" use case [4] –
it is easy to create a filesystem spread over the computers of you and
your friends so that you can share files and disk space with one
another.
LICENCE
You may use this package under the GNU General Public License, version
2 or, at your option, any later version. See the file "COPYING.GPL"
for the terms of the GNU General Public License, version 2.
You may use this package under the Transitive Grace Period Public
Licence, version 1.0. The Transitive Grace Period Public Licence says
that you may distribute proprietary derived works of Tahoe without
releasing the source code of that derived work for up to twelve
months, after which time you are obligated to release the source code
of the derived work under the Transitive Grace Period Public Licence.
See the file "COPYING.TGPPL.html" for the terms of the Transitive
Grace Period Public Licence, version 1.0.
(You may choose to use this package under the terms of either licence,
at your option.)
INSTALLATION
Tahoe works on Linux, Mac OS X, Windows, Cygwin, and Solaris. For
installation instructions please see "docs/install.html" [5].
HACKING AND COMMUNITY
Please join us on the mailing list [6] to discuss uses of Tahoe.
Patches that extend and improve Tahoe are gratefully accepted — the
RoadMap page [7] shows the next improvements that we plan to make and
CREDITS [8] lists the names of people who've contributed to the
project. The wiki Dev page [9] contains resources for hackers.
SPONSORSHIP
Tahoe is sponsored by Allmydata, Inc. [10], a provider of consumer
backup services. Allmydata, Inc. contributes hardware, software,
ideas, bug reports, suggestions, demands, and money (employing several
allmydata.org Tahoe hackers and instructing them to spend part of
their work time on this free-software project). We are eternally
grateful!
Zooko O'Whielacronx
on behalf of the allmydata.org team
March 25, 2008
San Francisco, California, USA
[1] http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=2315
[2] http://allmydata.org/trac/tahoe/wiki/Dev
[3] http://allmydata.org/trac/tahoe/wiki/Security
[4] http://allmydata.org/trac/tahoe/wiki/UseCases
[5] http://allmydata.org/source/tahoe/trunk/docs/install.html
[6] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
[7] http://allmydata.org/trac/tahoe/roadmap
[8] http://allmydata.org/trac/tahoe/browser/CREDITS?rev=2345
[9] http://allmydata.org/trac/tahoe/wiki/Dev
[10] http://allmydata.com
———————————————————————
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Re: [FDE] Paula Parker’s, Detective Inspector of Merseyside Police, response to Child Pornography on internet
The nexus between the referenced article and this list seems to be when
Detective Sergeant Geoff Conway is quoted: "Encryption and passwords
hold no fear for us. If there is something on a computer, we will find
it."
That's news to me. The agency I work for is positively manic (and
rightly so) to make sure that any computer that leaves our controlled
space is fully encrypted. I think my management would be unpleasantly
surprised to learn that our encryption can be easily swept aside by DS
Geoff of Merseyside.
In all seriousness, do such articles have any impact? Do vendors on
this list commonly encounter people who are convinced that no FDE scheme
is proof against even reasonably smart and resource-rich attacks?
I don't sell FDE products; I just use and administer them every day. My
users understand the need for FDE and accept the minor inconveniences
involved as long as they have faith that it works. If my users were to
read something like this and believe it, they'd get really irritated at
me for making them type yet another apparently unnecessary password
before they begin work each morning.
Any thoughts?
Bernard Owens
Computer Specialist
USTreas/IRS
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
[FDE] Paula Parker’s, Detective Inspector of Merseyside Police, response to Child Pornography on internet
http://www.liverpooldailypost.co.uk/liverpool-news/regional-news/2008/03/24/rising-tide-of-hi-tech-child-abuse-revealed-64375-20666220/
“Using the term child pornography lessens the impact and tends to legitimize it.”
“Let’s be clear about this, these are pictures of children being abused. The aim of our work is to reduce the people viewing abusive images of children, and thereby reduce the number of children being abused.” said Paula Parker
Sifting through images on a computer can be time consuming and psychologically draining task for the investigators. So the department acquired a “Categorization for Pictures (C4P)” software that can calculate hashes of each picture and categorize each image automatically. The investigator has to only categorize the image once, and thereafter any copy of that image on any computer can be caught by C4P automatically. This means the investigators has to view 50% to 60% fewer images now, and prosecute a lot more pedophiles.
Re: Protection for quasi-offline memory nabbing
At 10:38 AM 3/21/2008 -0700, Jon Callas wrote:
>Despite that my hypotheses are only that, and I have no experimental
>data, I think that using a large block cipher mode like EME to induce
>a pseudo-random, maximally-fragile bit region is an excellent
>mitigation strategy.
Isn't EME patented? – Alex
–
Alex Alten
alex@alten.org
———————————————————————
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Re: [p2p-hackers] convergent encryption reconsidered
Jim:
Thanks for your detailed response on the convergent encryption issue.
In this post, I'll just focus on one very interesting question that
you raise: "When do either of these attacks on convergent encryption
apply?".
In my original note I was thinking about the allmydata.org "Tahoe"
Least Authority Filesystem. In this post I will attempt to follow
your lead in widening the scope. In particular GNUnet and Freenet
are currently active projects that use convergent encryption. The
learn-partial-information attack would apply to either system if a
user were using it with files that she intended not to divulge, but
that were susceptible to being brute-forced in this way by an attacker.
On Mar 20, 2008, at 10:56 PM, Jim McCoy wrote:
>
> On Mar 20, 2008, at 12:42 PM, zooko wrote:
>
>> Security engineers have always appreciated that convergent
>> encryption allows an attacker to perform a
>> confirmation-of-a-file attack — if the attacker already knows
>> the full plaintext of a file, then they can check whether a
>> given user has a copy of that file.
>
> The truth of this depends on implementation details, and is an
> assertion that cannot be said to cover all or even most of the
> potential use-cases for this technique.
You're right. I was writing the above in the context of Tahoe,
where, as Brian Warner explained, we do not attempt to hide the
linkage between users and ciphertexts. What I wrote above doesn't
apply in the general case.
However, there is a very general argument about the applicability of
these attacks, which is: "Why encrypt?".
If your system has strong anonymity properties, preventing people
from learning which files are associated with which users, then you
can just store the files in plaintext.
Ah, but of course you don't want to do that, because even without
being linked to users, files may contain sensitive information that
the users didn't intend to disclose. But if the files contain such
information, then it might be acquired by the learn-partial-
information attack.
When designing such a system, you should ask yourself "Why
encrypt?". You encrypt in order to conceal the plaintext from
someone, but if you use convergent encryption, and they can use the
learn-partial-information attack, then you fail to conceal the
plaintext from them.
You should use traditional convergent encryption (without an added
secret) if:
1. You want to encrypt the plaintext, and
2. You want convergence, and
3. You don't mind exposing the existence of that file (ignoring the
confirmation-of-a-file attack), and
4. You are willing to bet that the file has entropy from the
attacker's perspective which is greater than his computational
capacity (defeating the learn-partial-information attack).
You should use convergent encryption with an added secret (as
recently implemented for the Tahoe Least Authority Filesystem) if:
1. You want to encrypt the plaintext, and
2. You want convergence within the set of people who know the added
secret, and
3. You don't mind exposing the existence of that file to people in
that set, and
4. You are willing to disclose the file to everyone in that set, or
else you think that people in that set to whom you do not wish to
disclose the file will not try the learn-partial-information attack,
or if they do that the file has entropy from their perspective which
is greater than their computational capacity.
I guess the property of unlinkability between user and file addresses
issue 3 in the above list — the existence of a file is a much less
sensitive bit of information than the existence of a file in a
particular user's collection.
It could also effect issue 4 by increasing the entropy the file has
from an attacker's perspective. If he knows that the ciphertext
belongs to you then he can try filling in the fields with information
that he knows about you. Without that linkage, he has to try filling
in the fields with information selected from what he knows about all
users. But hiding this linkage doesn't actually help in the case the
attacker is already using everything he knows about all users to
attack all files in parallel.
Note that using an added secret does help in the parallel attack
case, because (just like salting passwords) it breaks the space of
targets up into separate spaces which can't all be attacked with the
same computation.
> The first problem is isolating the original
> ciphertext in the pool of storage. If a file is encrypted using
> convergent encryption and then run through an error-correction
> mechanism to generate a number of shares that make up the file an
> attacker first needs to be able to isolate these shares to generate
> the orginal ciphertext. FEC decoding speeds may be reasonably fast,
> but they are not without some cost. If the storage pool is
> sufficiently large and you are doing your job to limit the ability of
> an attacker to see which blocks are linked to the same FEC operation
> then the computational complexity of this attack is significantly
> higher than you suggest.
The attacker can do this job more easily, in two ways:
1. He doesn't need to erasure-decode in order to check whether a
given erasure-coded share was generated from a given plaintext. He
can work forward from guessed-plaintext to encryption key to partial
ciphertext to partial erasure coded share, and check that. (Brian
Warner already explained that this is actually even easier for an
attacker in Tahoe, because he can then go from encryption key to
storage index and check that, but in this post I'm trying to address
the more general case.)
2. In the "parallel attack", he doesn't need to figure out which
erasure-coded shares correspond to which files. For example, suppose
he collects the first 32 bytes of many "blocks", where a block is the
output of erasure coding after encryption. Then he tries plausible
plaintexts, generates the encryption key, generates the first few
bytes of ciphertext, and then generates the first 32 bytes of erasure
coded share. (The details vary here depending on the encryption and
erasure coding, but you see that for typical encryption and typical
erasure coding, this is much less work than you might think.) Now he
checks if the 32 bytes that he generated appear in the set of 32-byte
block headers that he collected. If he gets a match, then he has
learned the full contents of a file in the system, although he
doesn't know which file or which user.
Regards,
Zooko
———————————————————————
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
[FDE] SOS loses SSN, and PII of 51,000 Agilent employees
Read more at:
http://www.mercurynews.com/ci_8660115?source=rss
I hope this deters companies from outsourcing processing of such confidential data to contractors who lack proper controls to protect customer’s data.
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
Re: [mm] How is DNSSEC
bmanning@vacation.karoshi.com wrote:
> On Sat, Mar 22, 2008 at 03:52:49PM +0000, Ben Laurie wrote:
>> bmanning@vacation.karoshi.com wrote:
>>> On Sat, Mar 22, 2008 at 02:46:40PM +0000, Ben Laurie wrote:
>>>> bmanning@vacation.karoshi.com wrote:
>>>>> Er… Allow me the option o fdisbeleiving your assertion.
>>>>> PTR records can and do point to mutiple names. Some narrow
>>>>> implementations have assumed that there will only be a single
>>>>> data element and this myth – that PTRs only point to a single
>>>>> name – is and has been spread widely.
>>>> You can disbelieve my assertion if you wish, but I am only quoting the
>>>> RFC. RFC 1035, to be precise:
>>>>
>>>> "Address nodes are used to hold pointers to primary host names
>>>> in the normal domain space."
>>>>
>>>> (section 3.5. IN-ADDR.ARPA domain). So, the "myth" is in the scripture.
>>>
>>> ah… open to interpretation. what is a "primary" host name?
>> RFC 1035 does not say, in the case of hosts, but the intent is quite
>> clear from the text on gateways:
>>
>> "Gateways will often have two names in separate domains, only one of
>> which can be primary."
>
>
> the intent for gateways… hosts w/ multiple IP's (VMware etc)
> are not gateways. comparing oranges w/ dragonfruits.
If you insist on language lawyering, I can play.
I'd say it is clear from:
a) The lack of a repeated PTR record for a host IP in the example,
b) The use of the word 'primary',
c) The fact that the authors felt it necessary to explain what they saw
as an exceptional case, i.e. that a gateway could have two names
that in the case of hosts, the authors expected there to only be a
single PTR record for reverse lookup.
Of course, we have the power to change RFCs. But there's a process for that.
Cheers,
Ben.
–
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." – Robert Woodruff
———————————————————————
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
