Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: users

STEED - Usable end-to-end encryption

 

 

First page Previous page 1 2 3 4 Next page Last page  View All GnuPG users RSS feed   Index | Next | Previous | View Threaded


jerome at jeromebaum

Oct 18, 2011, 9:16 AM

Post #26 of 80 (4075 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

> Even webmail. It is easy to write a browser extension to do the crypto
> stuff. Installing browser extensions is even easier than installing
> most other software.

I'd make it a point of discussion whether it's still webmail proper then.

But you could also use Javascript, Java or Flash, so yes this is doable
for webmail. I wouldn't trust my ISP to deliver the encryption module
though. It kind of defeats the "end-point" part in "end-point
encryption". As your average user I have no way to verify the module and
nobody can vouch for it as it's dynamically updated by my ISP.

So a fixed, open-source browser extension is really the only way to do
this properly. How is this different from installing an MUA (given that
a browser extension is often a full-blown piece of software with full
rights to the system)?

With the webmail argument and since webmail is probably majority access
for private email, it's looking more important to work with the ISPs,
but I stand by my point of not building this on a single pillar.

--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Oct 18, 2011, 9:18 AM

Post #27 of 80 (4051 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 10/18/2011 11:58 AM, Werner Koch wrote:
> We did this for about 15 years - without any success. If you look
> at some of the studies you will see that you can't teach that stuff
> to non-techies - sometimes not even to engineers.

As a data point from 2005:

I was teaching computer literacy at the University of Iowa. The first
day of class I asked the 35 students which of them brought a computer of
any kind to class. Three people raised their hands: they all said they
brought laptops. When I asked how many brought cell phones, all 35
raised their hands. The only people who thought cell phones were
computers were the three who brought laptops.

I then asked if a game console (XBox, Playstation, take your pick) was a
computer. The class was almost evenly split: half said yes, on account
of how you could surf the web with it. Half said no, because you can't
write a Word document with it.

Admittedly, this is not a representative sample of college students.
That said, I think it's an informative anecdote.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


holtzm at cox

Oct 18, 2011, 11:50 AM

Post #28 of 80 (4053 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Mon, Oct 17, 2011 at 05:50:42PM -0600, Aaron Toponce wrote:

.........snip..........
>
> At any rate, I would love to see more client-to-client encryption in email.
> I've always wondered if there could be an "OTR" approach to mail, somehow,
> so people don't need to generate and manage their own sets of keys, as that
> seems to be the largest hinderence to widespread adoption.
> the user should do, is compose the mail, hit send, and everything is

Not true. The greatest hindrance to widespread adoption is the phrase I
often hear..."I've got nothing to hide" It drives me up a wall.


> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


--
Bob Holtzman
If you think you're getting free lunch,
check the price of the beer.
Key ID: 8D549279
Attachments: signature.asc (0.19 KB)


gollo at fsfe

Oct 18, 2011, 12:59 PM

Post #29 of 80 (4054 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

* Robert Holtzman <holtzm [at] cox> [111018 21:43,
mID <20111018185035.GB4590 [at] cox>]:

> The greatest hindrance to widespread adoption is the phrase I often
> hear..."I've got nothing to hide" It drives me up a wall.

+1

Martin
Attachments: smime.p7s (3.96 KB)


yyy at yyy

Oct 19, 2011, 1:20 AM

Post #30 of 80 (4059 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

----- Original Message -----
From: "Werner Koch" <wk [at] gnupg>
To: "Jerome Baum" <jerome [at] jeromebaum>
Cc: <gnupg-users [at] gnupg>
Sent: Tuesday, October 18, 2011 7:00 PM
Subject: Re: STEED - Usable end-to-end encryption


> On Tue, 18 Oct 2011 16:35, jerome [at] jeromebaum said:
>
>> operations will be the most important part to making that work, and the
>> ISPs don't have to help out there (modulo webmail which isn't even
>> end-point).
>
> Even webmail. It is easy to write a browser extension to do the crypto
> stuff. Installing browser extensions is even easier than installing
> most other software.
>
There is firegpg plugin for firefox, and it does not works well with
latest versions (installing it in firefox5 was not straightforward).
I am not aware of any other public key encryption plugin
for firefox or for any other browser. Some webmails have
POP3/IMAP/SMTP, but some does not. (for example inbox.lv
for qute long time had only POP3, but not SMTP)

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


tom at ritter

Oct 19, 2011, 6:11 AM

Post #31 of 80 (4081 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 18 October 2011 12:00, Werner Koch <wk [at] gnupg> wrote:
> On Tue, 18 Oct 2011 16:35, jerome [at] jeromebaum said:
>
>> operations will be the most important part to making that work, and the
>> ISPs don't have to help out there (modulo webmail which isn't even
>> end-point).
>
> Even webmail. It is easy to write a browser extension to do the crypto
> stuff. Installing browser extensions is even easier than installing
> most other software.


It's not easy. I'm aware of FireGPG, CR-GPG, and Penango and they
range from non-functional to barely-functional, some of the time.

Email encryption is a super-hard problem because even within a 'target
audience', you have to deal with hard problems, and
cross-target-audience they get even harder.

The Young Crowd: Most people I know use gmail web interface and their phone.
The Old Crowd: Most of these folks I know use yahoo, hotmail, or their
ISP with Outlook Express.
The Super-Old-Crowd: Anything, but it needs to be easy enough to set
up that a member of the Old Crowd can do it *for* a member of this
crowd.
Corporate: It has to enterprise manageable, key escrow, compliant, etc
Devs/Security Folks: Key Management! My private key can never leave my
possession.
Other Security Folks: Absolutely NO javascript cryptography. Zero, none.

And there's the very practical problem of _sometimes_ I do need to
read my mail from a machine that is not my own. As a security person
I almost never do it. But 'the young crowd' do it all the time. You
have to satisfy that requirement also.

>From what I've seen - S/MIME within an organization satisfies most of
Corporate, until you send an email outside the organization. Enigmail
satisfies some developers/security folk (but you lose email on your
phone and webmail - which is pretty nice.)

Any solution you come up with for one group _should_ interoperate with
the solution(s) for the others.

And any solution that relies on an ISP or webmail provider making
changes is just unlikely. The most innovation we've seen recently has
come from the Chrome and Mozilla teams who are driving browser
security with HSTS, Pinning, and Content Security Policy. Internet
Explorer is driving browser security in another direction with
reputational-based downloads and anti-phishing.

So trying to drive a secure, browser-based cryptoapi seems to be a
reasonable possibility. (See DOMCrypt). For browsers without the
API, you could use a plugin to provide it, and eventually hopefully
the browser makes it part of the browser proper and the extension is
obsolete.
That almost solves webmail. Except that the provider needs to support
it - and you could opt to leave your key on the server vs not, that
partially solves key management (because it's a choice). It could use
OpenPGP and interoperate with Enigmail/Mutt. But you're still left
trying to interoperate with corporate, phone-mail, convincing
yahoo/hotmail/other obscure webmails to support it, intergrating it
into the next Outlook Express ("Windows Mail" I think?), and having an
understandable UI.

I've been working with and on remailers recently, and this is a
similar problem. It's bloody hard. I don't know if there will ever
be a better solution than what we have now, and what we have now
sucks.

-tom

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


alex at gpgtools

Oct 19, 2011, 7:46 AM

Post #32 of 80 (4046 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Hi,

On 19.10.2011, at 15:11, Tom Ritter wrote:
> Other Security Folks: Absolutely NO javascript cryptography. Zero, none.

well, JavaScript itself is just another programming language and combined with modern technologies like HTML5 Web Storage there is nowadays technically no need to implement browser plugins for different versions and platforms. See [1].

Best regards, Alex

[1] http://www.gpgtools.org/mobile/index.html

--
http://gpgtools.org


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


harakiri_23 at yahoo

Oct 19, 2011, 11:07 AM

Post #33 of 80 (4049 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

--- On Mon, 10/17/11, Werner Koch <wk [at] gnupg> wrote:

> From: Werner Koch <wk [at] gnupg>
> Subject: STEED - Usable end-to-end encryption
> To: gnupg-devel [at] gnupg
> Cc: "Marcus Brinkmann" <marcus [at] gnu>, gnupg-users [at] gnupg
> Date: Monday, October 17, 2011, 2:11 PM
> Hi!

>
> http://g10code.com/docs/steed-usable-e2ee.pdf
>
> There is also a brief (for now) web page dedicated to this
> project:
>
> http://g10code.com/steed.html

Here is some input, you might not like it - but still:

I dont see any ground breaking new approaches to the topic - key search via DNS has been in commercial products for over 10 years already - nothing new - heck isnt there even an RFC that describes this?

Letting the keys automatically be generated by the client is not a new approach either commercial solutions do this too - however - did you think of the keys the user already has? His ID for example - you are sponsored by the german government - the first thing which should have come into your mind is that everybody can use his "Personalausweis" as a Smartcard because it already has a private/public keypair. Other european countries could follow...

Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so.

Use existing tools most user have installed on his machine by default - work with these and get a suiteable end-to-end encryption going!

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 19, 2011, 12:30 PM

Post #34 of 80 (4058 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Werner, Marcus,

Thank you for thinking about taking end-to-end e-mail encryption to the next
level. I really like your ideas.

However, I think you're not ambitious enough when you opt for using DNS for key
distribution. Yes, the infrastructure and RR types[1] are already there. But it
brings this nasty dependency on the provider. Because the part of the client
updates to the DNS is a key missing part in the DNS infrastructure as today, and
I don't see providers adding that soon.

I'm thinking more of things like DHT, Distributed Hash Tables, in BitTorrent, or
similar concepts in other peer-to-peer networks. I have no idea how it works :),
but it does. You fire up your BitTorrent, all the data it needs is the hash of a
torrent file, and suddenly it learns IP-addresses of other people who share that
torrent file. If you could do something similar for mapping e-mail addresses to
certificates, you don't need ISP's to implement extra stuff. Because I think
that is a really major hurdle; probably a too steep one, IMHO.

And if you design that infrastructure general enough to do X-to-certificate, we
could use the same infra for opportunistic end-to-end encryption of TCP/IP,
which would be great to have too, but a different paper altogether :).

Peter.

[1] "Entries" in the DNS, for people not up to DNSpeed ;)
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 19, 2011, 12:40 PM

Post #35 of 80 (4072 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 19/10/11 21:30, Peter Lebbing wrote:
> that is a really major hurdle; probably a too steep one, IMHO.

Given that all normal, literal hurdles are at right angles to the ground, they
are all equally steep. Obviously I meant high :D.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


expires2011 at ymail

Oct 19, 2011, 1:03 PM

Post #36 of 80 (4079 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Wednesday 19 October 2011 at 7:07:45 PM, in
<mid:1319047665.75751.YahooMailClassic [at] web130223>,
Harakiri wrote:


> Also - inventing just ANOTHER protocol for email
> encryption that mail clients should implement? Heck,
> the only protocol available in all major mail clients
> right now for out of the box encryption is only smime -
> for PGP you need plugins - even after so many years
> there is no out of the box solution for the other major
> standard - lets not talk about all the compatibility
> issues with smime in all existing clients. And you just
> want add another NEW standard which will solve issues?
> I dont think so.

On the other hand, perhaps the message to take from the current low
adoption levels of encrypted email is that the current protocols need
replacing (or major tweaking). (-;



> Use existing tools most user have installed on his
> machine by default - work with these and get a
> suiteable end-to-end encryption going!

If tools are installed by default but not enabled by default, maybe
the group that needs bringing on board is not ISPs/email providers but
OEMs and those who produce operating systems, email clients and
browsers?


- --
Best regards

MFPA mailto:expires2011 [at] ymail

What's another word for synonym?
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTp8tQ6ipC46tDG5pAQojwQQAyVC7lwcAqp82tR9lwxLQ2Y5bfdmw0Fym
yYD/xnFlEB2Pxyzsvizdb0SyCgrGlpqIePhCw8YqGMW6ZWVl+l1Q3mU3SI67G+db
s74vMtMLVr2zMW7FiGfKpHrDad6Gj1RQHoBSjN4kmalcTEGMediABmXgwFrfk9le
/Ze5URFyJj4=
=V8zt
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


smujohnson at gmail

Oct 19, 2011, 1:09 PM

Post #37 of 80 (4051 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Hi,

I read this briefly, and I'd actually like to read it over later and maybe
contribute some ideas. The lack of people caring about cryptography is
quite apparent, and may be solved with some good ideas of making things less
annoying / hard to use.

I'd be happy to help.


On Mon, Oct 17, 2011 at 11:11 AM, Werner Koch <wk [at] gnupg> wrote:

> Hi!
>
> Over the last year Marcus and me discussed ideas on how to make
> encryption easier for non-crypto geeks. We explained our plans to
> several people and finally decided to start a project to develop such a
> system. Obviously it is based on GnuPG but this is only one component
> of the whole system. We prepared a short paper; if you are interested
> you may download it from
>
> http://g10code.com/docs/steed-usable-e2ee.pdf
>


kloecker at kde

Oct 19, 2011, 1:10 PM

Post #38 of 80 (4063 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Wednesday 19 October 2011, Harakiri wrote:
> --- On Mon, 10/17/11, Werner Koch <wk [at] gnupg> wrote:
> > From: Werner Koch <wk [at] gnupg>
> > Subject: STEED - Usable end-to-end encryption
> > To: gnupg-devel [at] gnupg
> > Cc: "Marcus Brinkmann" <marcus [at] gnu>, gnupg-users [at] gnupg
> > Date: Monday, October 17, 2011, 2:11 PM
> > Hi!
> >
> >
> > http://g10code.com/docs/steed-usable-e2ee.pdf
> >
> > There is also a brief (for now) web page dedicated to this
> > project:
> >
> > http://g10code.com/steed.html
>
> Here is some input, you might not like it - but still:
>
> I dont see any ground breaking new approaches to the topic - key
> search via DNS has been in commercial products for over 10 years
> already - nothing new - heck isnt there even an RFC that describes
> this?
>
> Letting the keys automatically be generated by the client is not a
> new approach either commercial solutions do this too - however - did
> you think of the keys the user already has? His ID for example - you
> are sponsored by the german government - the first thing which
> should have come into your mind is that everybody can use his
> "Personalausweis" as a Smartcard because it already has a
> private/public keypair.

No, it does not. At least, not by default. If you buy a qualified
certificate then you can put this certificate on your "Personalausweis",
but, given how expensive such a certificate is, I doubt that a lot of
people will use this feature of the Personalausweis. There are probably
more people with an OpenPGP-capable smartcard than there are people with
a German Personalausweis with an expensive certificate.


> Other european countries could follow...
>
> Also - inventing just ANOTHER protocol for email encryption that mail
> clients should implement? Heck, the only protocol available in all
> major mail clients right now for out of the box encryption is only
> smime - for PGP you need plugins - even after so many years there is
> no out of the box solution for the other major standard - lets not
> talk about all the compatibility issues with smime in all existing
> clients. And you just want add another NEW standard which will solve
> issues? I dont think so.

What NEW standard are you talking about? Werner wants to use OpenPGP.
The only thing he wants to simplify is key exchange.


> Use existing tools most user have installed on his machine by default
> - work with these and get a suiteable end-to-end encryption going!

I'm not sure what existing tools you mean. Are you talking about S/MIME?
You said yourself that S/MIME is no viable solution because of
compatibility issues.


Regards,
Ingo
Attachments: signature.asc (0.19 KB)


expires2011 at ymail

Oct 19, 2011, 1:18 PM

Post #39 of 80 (4057 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Wednesday 19 October 2011 at 8:30:48 PM, in
<mid:4E9F2568.6080709 [at] digitalbrains>, Peter Lebbing wrote:


> If you could do something similar for
> mapping e-mail addresses to certificates

It would be awesome if this could be achieved without revealing other
email addresses or UIDs that might happen to map to the same
key/certificate.


- --
Best regards

MFPA mailto:expires2011 [at] ymail

Did you hear? They took the word gullible out of the dictionary
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTp8whKipC46tDG5pAQosxQP9GrQFRgLGah55Xn3wtD1yOs1LfSiodMxu
t4pEi3ecFQPrVvhExXhaqqm2MnDk14CG6xonZorMbrOc++oPqaismQ1ZCOagHiU0
Klqy3k/S0sWR2XIK7ec9G4BRNUirKtsIA4Etj0BXyfbuuDZ0weWxFPelZ5VBD6Ow
ZLQ+joDgtdk=
=iWzE
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 19, 2011, 1:22 PM

Post #40 of 80 (4053 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

>> If you could do something similar for
>> mapping e-mail addresses to certificates
>
> It would be awesome if this could be achieved without revealing other
> email addresses or UIDs that might happen to map to the same
> key/certificate.

Hash the UID many times. (Didn't someone propose that a while ago?)

--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

Oct 19, 2011, 1:49 PM

Post #41 of 80 (4055 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 19/10/11 22:22, Jerome Baum wrote:
>> It would be awesome if this could be achieved without revealing other
>> email addresses or UIDs that might happen to map to the same
>> key/certificate.
>
> Hash the UID many times. (Didn't someone propose that a while ago?)

By default the STEED system as proposed creates a new certificate for every
e-mail address. So unless manually overridden, there is a one-to-one relation
between e-mail addresses and certificates and no way to "enumerate all e-mail
addresses".

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


jerome at jeromebaum

Oct 19, 2011, 1:54 PM

Post #42 of 80 (4055 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On 2011-10-19 22:49, Peter Lebbing wrote:
> On 19/10/11 22:22, Jerome Baum wrote:
>>> It would be awesome if this could be achieved without revealing other
>>> email addresses or UIDs that might happen to map to the same
>>> key/certificate.
>>
>> Hash the UID many times. (Didn't someone propose that a while ago?)
>
> By default the STEED system as proposed creates a new certificate for every
> e-mail address. So unless manually overridden, there is a one-to-one relation
> between e-mail addresses and certificates and no way to "enumerate all e-mail
> addresses".
>
> Peter.
>

Re-reading the original quote ("map to the same key/certificate") that's
right. I had assumed he was talking about the DHT correlating keys (so
just like you can tell in the BitTorrent DHT which other torrents some
IP is involved in by doing enough work, you might be able to tell which
other certificates that IP uploaded -- but all this is nonsense in the
original context, which I misread).

--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


hka at qbs

Oct 19, 2011, 2:06 PM

Post #43 of 80 (4073 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Wednesday 19 of October 2011 22:10:30 Ingo Klöcker wrote:
> On Wednesday 19 October 2011, Harakiri wrote:
> >
> > Also - inventing just ANOTHER protocol for email encryption that mail
> > clients should implement? Heck, the only protocol available in all
> > major mail clients right now for out of the box encryption is only
> > smime - for PGP you need plugins - even after so many years there is
> > no out of the box solution for the other major standard - lets not
> > talk about all the compatibility issues with smime in all existing
> > clients. And you just want add another NEW standard which will solve
> > issues? I dont think so.
>
> What NEW standard are you talking about? Werner wants to use OpenPGP.
> The only thing he wants to simplify is key exchange.

since when key servers are hard to use? the short PGP fingerprints can easily
be told on the phone (so you have a voice verification of the key if you know
the person) and the full can be verified just as easily.

The problem is that people don't feel the need for authentication and privacy
in e-mail. They feel that e-mail is secure (after all I use encryption to my
e-mail server).

Regards,
--
Hubert Kario

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


expires2011 at ymail

Oct 19, 2011, 2:36 PM

Post #44 of 80 (4050 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Wednesday 19 October 2011 at 9:49:20 PM, in
<mid:4E9F37D0.50601 [at] digitalbrains>, Peter Lebbing wrote:



> By default the STEED system as proposed creates a new
> certificate for every e-mail address. So unless
> manually overridden, there is a one-to-one relation
> between e-mail addresses and certificates and no way to
> "enumerate all e-mail addresses".

Fair enough if you are using the default. The paper also mentions "One
Key for all Accounts" and says "The system should allow for this use
case, which needs to be supported by all clients by allowing
previously created keys to be configured and deployed with an account."

- --
Best regards

MFPA mailto:expires2011 [at] ymail

Wait. You think I'm right?
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTp9C5qipC46tDG5pAQot2wP9Hon1hAbbLzbYo02qBgaW1UZHA/GBBFgH
+t77FNBc3OaolffxGzAZol9FhT+wrzsKkn6yos6E+Ub+rvZHHFgyNGoPPt5WSsBI
U0gfK/is3xBVcmsM8YdWBYcd3l2dQeMyP3tw3CxHCU3DaDUjsjC9+kC3mJ3+E/g5
qjasVBWBFuU=
=m9sn
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


marcus.brinkmann at ruhr-uni-bochum

Oct 19, 2011, 7:16 PM

Post #45 of 80 (4066 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Hi Peter,

thanks for your feedback.

On 10/19/2011 09:30 PM, Peter Lebbing wrote:
> However, I think you're not ambitious enough when you opt for using DNS for key
> distribution. Yes, the infrastructure and RR types[1] are already there. But it
> brings this nasty dependency on the provider. Because the part of the client
> updates to the DNS is a key missing part in the DNS infrastructure as today, and
> I don't see providers adding that soon.

You are right that it is a challenge to get the support in the providers, but
note that changes in the mail client are required anyway. Sure, changing the
client and changing the DNS infrastructure are two different kind of beasts,
but we probably can not do without the providers completely if we want
ubiquitous support.

> I'm thinking more of things like DHT, Distributed Hash Tables, in BitTorrent, or
> similar concepts in other peer-to-peer networks. I have no idea how it works :),
> but it does. You fire up your BitTorrent, all the data it needs is the hash of a
> torrent file, and suddenly it learns IP-addresses of other people who share that
> torrent file. If you could do something similar for mapping e-mail addresses to
> certificates, you don't need ISP's to implement extra stuff. Because I think
> that is a really major hurdle; probably a too steep one, IMHO.

Yes, P2P networks are great, let's do more of those. But why stop at
certificates? Just use a P2P network for all of DNS.

See what happened? I just turned it around. :)

The paper notes how we can utilize DNSSEC to strengthen our trust model.
Similarly, we can utilize a P2P based DNS system. Now instead of one problem,
we got two :)

P2P systems are tricky to get right, and have their own tradeoffs. Also,
while acceptance for our proposal among service providers will be tough to
get, I'd expect that getting acceptance for a P2P based system would be even
harder. A lot of things have to fall into place to make a P2P network a
viable alternative, and not all of them are technical.

Thanks,
Marcus

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


lists-gnupgdev at lina

Oct 19, 2011, 8:30 PM

Post #46 of 80 (4055 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

Am 20.10.2011 04:16, schrieb Marcus Brinkmann:
> You are right that it is a challenge to get the support in the providers

the lowest efford are discovery via personal web pages like doing XDR or
maybe webfinger. Most users wont be able to have special RRs - not even
for their own domains (which is also rather seldom).

I would use <link rel=""> like openID does.

Gruss
Bernd


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 20, 2011, 2:04 AM

Post #47 of 80 (4043 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Thu, 20 Oct 2011 05:30, lists-gnupgdev [at] lina said:

> the lowest efford are discovery via personal web pages like doing XDR or
> maybe webfinger. Most users wont be able to have special RRs - not even

Most users don't have personal web pages. So what now? Well many users
have a facebook page - but this would make facebook mandatory and we
woold need support from them (at least to guarantee that they don't
break any assumptions). Not much different to work with ISPs.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


wk at gnupg

Oct 20, 2011, 2:26 AM

Post #48 of 80 (4065 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Wed, 19 Oct 2011 22:10, kloecker [at] kde said:

> What NEW standard are you talking about? Werner wants to use OpenPGP.

and S/MIME! We actually don't care. For certain MUAs it is much
simpler to implement something on top of S/MIME than to trying to get
OpenPGP support. The actual protocol in use does not matter to the user
(only to use experts).


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


mwood at IUPUI

Oct 20, 2011, 6:56 AM

Post #49 of 80 (4054 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

What proportion of consumer-grade ISPs have bothered to implement
DNSSEC for serving their customers? I don't think mine does, and
they're a big outfit. If I asked, I expect they'd think I was
speaking Aldebaranese or something.

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


ott at mirix

Oct 20, 2011, 1:25 PM

Post #50 of 80 (4035 views)
Permalink
Re: STEED - Usable end-to-end encryption [In reply to]

On Thu, Oct 20, 2011 at 04:16:01AM +0200, Marcus Brinkmann wrote:
> On 10/19/2011 09:30 PM, Peter Lebbing wrote:
> > However, I think you're not ambitious enough when you opt for using DNS for key
> > distribution. Yes, the infrastructure and RR types[1] are already there. But it
> > brings this nasty dependency on the provider. Because the part of the client
> > updates to the DNS is a key missing part in the DNS infrastructure as today, and
> > I don't see providers adding that soon.
>
> You are right that it is a challenge to get the support in the providers, but
> note that changes in the mail client are required anyway. Sure, changing the
> client and changing the DNS infrastructure are two different kind of beasts,
> but we probably can not do without the providers completely if we want
> ubiquitous support.

But who are the providers? Except for people who work in computer
science, physics or similar fields I don't know people who run their own
mail servers or are part of a cooperative. Most other people use a
handful of providers who often offer free service in exchange for the
loss of privacy or at least some form of semi-targeted advertisement. Do
you expect those providers to ruin their business models by implementing
this proposal? I wouldn't count on them.

Perhaps the providers could also be forced by law not to implement
this, because (if I remember correctly) come countries require that
they store at least the header information (including subject, which
should also be encryted by the system) for traffic analysis. So in
the worst case the providers couldn't implement this without breaking
the law (I doubt that citizens could use the system without breaking the
law in this situation either, but individuals are often more venturous
than organisations).

What about making everyone their own provider? The efforts in this
direction intiated by Eben Moglen that lead to the FreedomBox and other
projects seem to go in the right direction. It doesn't seem to me less
realistic than requiring cooperation from providers.

Regards,
Matthias-Christian

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

First page Previous page 1 2 3 4 Next page Last page  View All GnuPG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.