Re: [cryptography] Question About Best Practices for Personal File Encryption

[shawn wilson]

I just use gpg and armor the file. If its text, there's also a vim plugin
that works perfectly with this method.
On Aug 16, 2014 12:06 AM, "Mark Thomas"  wrote:

> I have a question for the group, if I may ask it here and in this manner
> (?).
>
> What are you guys using to encrypt individual files and folders or even
> entire drives like a USB?
>
> I am thinking that:
>
> 1. any commercial product could be compromised and not completely secure.
> Like Apple’s FileVault2, which Apple has a key to.
>
> 2. It is probably open source.
>
> 3. It is probably implemented with the command line.
>
> Am I on the right track? If so does anyone know of a helpful guide to get
> started with OpenSSL on the command line besides the man pages?
>
> Regards,
>
> Mark
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Question About Best Practices for Personal File Encryption

[Andy Isaacson]

On Sun, Aug 17, 2014 at 10:56:33PM +0200, Alfie John wrote:
> Given an open source program, it can be accountable by anyone. If there
> is a bug, it can be patched. If there is a deliberate backdoor, it can
> be pointed to as an example of why to completely abandon the program and
> mark the developer as tainted forever.

I'm a significant proponent of open source, and the benefits you
enumerate here are definitely true.  Open source can be helpful in
reviewing code, in grokking developer intent, in providing a hash-chain
guarantee of code lineage, in providing change history and justification
when reviewing new releases of a previously audited program, and in
fostering positive engineering practices.

However --

> Given a proprietary program, it is accountable to the supplier and you
> have no other option. If there is a bug, all you can do is hope for a
> patch. If there is a deliberate backdoor, all you can do is hope that
> someone will spots if it is ever reverse engineered.

Your "proprietary program" strawman is full of holes.

The intellectual labor of decompiling a program delivered as a binary is
not especially large compared to the labor required to do a thorough
systematic review.  Given IDA Pro and a non-obfuscated Win32 or Linux
app, people I trust say the decompilation process is on the order of
10%-20% of the total effort of a review.

Binary patches are not great by any means, but they are definitely a
feasible method of deploying fixes, and this method works and is well
tested in the real world.  Some kinds of deployments basically require
binary patching, no matter what the underlying source management
technology.  (The Linux Ksplice project provides one prominent example.)

Backdoors are an enormous problem for both open source and
binary-distribution codebases, and claiming that open source will save
you from backdoors ignores the reality of the situation.  Just to start,

http://underhanded.xcott.com/
http://www.wired.com/2013/04/underhanded-c-contest/
http://graphics.stanford.edu/~danielrh/vote/vote.html
http://codegolf.stackexchange.com/questions/tagged/underhanded?sort=votes&pageSize=50

"Building Reliable Voting Machine Software", Ka-Ping Yee
http://zesty.ca/voting/

page 148 of http://zesty.ca/pubs/yee-phd.pdf provides a sobering
assessment of the difficulty of finding intentionally inserted bugs in
open source software.

-andy
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Fwd: Cryptoparty 2014 - Hi my name is Ed - 2014/09/20

[shawn wilson]

Is anyone (or know anyone) in the DC area who would like to talk at
this event? The focus is on defensive security, identity, and tools
(and some UX as it relates to things like gnupg). But I'd also like to
see some more technical talks involving math or programatic use of
encryption.

If anyone is interested, the hacdc forum is an open Google group or
you can email me (I can also provide another email that I use gpg with
if you'd prefer).


-- Forwarded message --
From: shawn wilson 
Date: Sun, Jun 8, 2014 at 7:27 PM
Subject: Cryptoparty 2014 - Hi my name is Ed - 2014/09/20
To: "blab...@hacdc.org" 


tldr:
Speaking/links/software spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing
Meetup event: http://www.meetup.com/hac-dc/events/187948232/

For those who don't follow the list, the back story on the subtitle
(besides me thinking it's ironic) is:
https://groups.google.com/a/hacdc.org/forum/#!topic/Blabber/-N8UxXMvfxU

First, we need speakers!!! In order to have an event like the last two
years, people need to volunteer to present on what they know. Here's
last year's doc (for reference)
https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdHVlN3ZDMmNQTVlUZVJDZTA4UHZSY2c&usp=sharing
and here's this year's doc (for you to sign up and update
software/links on [1]):
https://docs.google.com/spreadsheet/ccc?key=0AlbW1qRSpLFMdEM5MzV4YTBhQ0g0ZXdveUVuXzR3ckE&usp=sharing

If you work at a news agency or activist group where you feel you're
handling communication and individuals' privacy correctly maybe you or
your CTO would like to talk about it?
If you enjoy crypto and would like to talk about your experience, sign up.
If you think that crypto is hard and have ideas on how to improve it
(I know you do) maybe you should give a talk. [2]
If you have a friends, colleges, college professors, etc who is kinda
local who you think would add content to our discussion, get them to
sign up to give a talk.

On the other hand, if you'd like to become more familiar with the most
cryptographically secure ways to store and transmit data including how
to setup encrypted (or signed) email, FDE [3], best password hashes to
use and how hashing works, common mistakes when creating
passwords/making more secure passwords, etc - please come.

Here's the meetup event: http://www.meetup.com/hac-dc/events/187948232/
The event can still be pretty flexible (there's more going on at the
church the week before, but I think we could work around that). I
think I'll wait a few days to see if anyone shows any event conflicts
(within the same sphere of computer/internet/security) but this should
be it.

[1] We can debate on the usefulness of an unmaintained TrueCrypt, but
it probably should stay in that list for now.
[2] 
https://researchspace.auckland.ac.nz/bitstream/handle/2292/2310/02whole.pdf?sequence=2
and later https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf
[3] FDE - full disk encryption (will probably be mentioned later in this thread)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Question About Best Practices for Personal File Encryption

[Tony Arcieri]

On Fri, Aug 15, 2014 at 9:05 PM, Mark Thomas  wrote:

> any commercial product could be compromised and not completely secure.
> Like Apple’s FileVault2, which Apple has a key to.


There aren't known backdoors in FileVault2, or for that mater, Microsoft's
Bitlocker. Apple, on the other hand, has been pretty forthcoming with law
enforcement backdoors in iPhones (which, actually, seem fairly reasonable,
IMO)

Don't trust their encrypted filesystem? You better not trust the OS either,
for that surely has access to all of the encryption keys you've ever put in
main memory.

tl;dr: if you don't trust proprietary encrypted filesystems, you better not
trust the proprietary OSes they're built into either.

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Question About Best Practices for Personal File Encryption

[ianG]

On 17/08/2014 19:39 pm, Ryan Carboni wrote:
> Or in the case of OpenSSL, no one notices the backdoor as it is
> indistinguishable from an obscure programming error.


The difference between a corporate backdoor and an open source backdoor
is likely that when it is finally discovered, the corporate
embarrassment is still easy enough to suppress:  NDAs are a weapon.

Sunlight is your friend.  The many eyeballs thing doesn't really find
any more bugs, it seems, but it certainly guarantees a scandal.  The
agencies don't go where the sunlight is brightest.


> On Sun, Aug 17, 2014 at 5:01 AM, ianG  > wrote:
> 
> On 17/08/2014 05:09 am, Jeffrey Goldberg wrote:
> > On 2014-08-16, at 4:51 PM, David I. Emery  > wrote:
> 
> > I do think, however, that if there are such backdoors, it would have
> > to be known to only a very small number of people. Too many of the
> people
> > who work on Apple security would blow the whistle. So it would have to
> > be introduced in such a way that most of the people who actually
> develop
> > these tools are unaware of the backdoors. It’s certainly possible, but
> > it does shift balance of plausibility.
> 
> Right.  As I understand it, the standard way that this is done is to
> create a special features group in another closely-allied country.  That
> group secures permission from HQ to do some rework for their "special
> national needs."
> 
> That group then inserts in the backdoor, then ships the entire patch off
> to HQ.  Unless the center is reviewing for obfuscated tricks from a
> trusted partner, the backdoor slides in, and nobody knows it is there.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Question About Best Practices for Personal File Encryption

[Ryan Carboni]

Or in the case of OpenSSL, no one notices the backdoor as it is
indistinguishable from an obscure programming error.


On Sun, Aug 17, 2014 at 5:01 AM, ianG  wrote:

> On 17/08/2014 05:09 am, Jeffrey Goldberg wrote:
> > On 2014-08-16, at 4:51 PM, David I. Emery  wrote:
>
> > I do think, however, that if there are such backdoors, it would have
> > to be known to only a very small number of people. Too many of the people
> > who work on Apple security would blow the whistle. So it would have to
> > be introduced in such a way that most of the people who actually develop
> > these tools are unaware of the backdoors. It’s certainly possible, but
> > it does shift balance of plausibility.
>
> Right.  As I understand it, the standard way that this is done is to
> create a special features group in another closely-allied country.  That
> group secures permission from HQ to do some rework for their "special
> national needs."
>
> That group then inserts in the backdoor, then ships the entire patch off
> to HQ.  Unless the center is reviewing for obfuscated tricks from a
> trusted partner, the backdoor slides in, and nobody knows it is there.
>
>
>
> iang
>
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Question About Best Practices for Personal File Encryption

[ianG]

On 17/08/2014 05:09 am, Jeffrey Goldberg wrote:
> On 2014-08-16, at 4:51 PM, David I. Emery  wrote:

> I do think, however, that if there are such backdoors, it would have
> to be known to only a very small number of people. Too many of the people
> who work on Apple security would blow the whistle. So it would have to
> be introduced in such a way that most of the people who actually develop
> these tools are unaware of the backdoors. It’s certainly possible, but
> it does shift balance of plausibility.

Right.  As I understand it, the standard way that this is done is to
create a special features group in another closely-allied country.  That
group secures permission from HQ to do some rework for their "special
national needs."

That group then inserts in the backdoor, then ships the entire patch off
to HQ.  Unless the center is reviewing for obfuscated tricks from a
trusted partner, the backdoor slides in, and nobody knows it is there.



iang

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography