Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

James A. Donald"  writes:

The key, and the hash of the key, is a long string of random
gibberish.  It should not be visible to end users.  Experience
demonstrates that showing it repels 99% of end users.

On 2013-03-06 9:33 PM, StealthMonger wrote:


Merchant includes its telephone number in every advertisement and 
repeatedly admonishes prospects to call.


That is a short string of gibberish.

Your only argument is that the key ID is "longer" or more "random".


Exactly so.

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

[cryptography] Sodium: NaCl repackaged for portability/ease-of-use

[Tony Arcieri]

Hello crypto-people,

Frank Denis just announced Sodium, a fork of NaCl containing only the
reference C code, packaged using a standard autotools build system:

http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/

NaCl has traditionally been hard to use because it targets *IX exclusively
and the assembly versions of the various algorithms are not PIC yet. For
this reason there are a lot of issues making NaCl work portably (e.g.
across 32-bit/64-bit platforms, let alone Windows)

Sodium is designed to be portable, easy to compile/package, and it even
works on Windows!

Some might think this undermines some of the original goals of NaCl,
however djb has suggested it as an option in the past:

On Sun, Dec 16, 2012 at 10:27 PM, D. J. Bernstein  wrote:

>* More language support. The real work here is making everything
>  PIC. Of course, if what matters is the API rather than speed, then
>  achieving PIC is easy: just remove the asm.


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

Re: [cryptography] Client TLS Certificates - why not?

[Jeffrey Walton]

On Wed, Mar 6, 2013 at 6:33 AM, StealthMonger
 wrote:
> ...
>
>> The key, and the hash of the key, is a long string of random
>> gibberish.  It should not be visible to end users.  Experience
>> demonstrates that showing it repels 99% of end users.
>
> Merchant includes its telephone number in every advertisement and
> repeatedly admonishes prospects to call.
>
> The telephone number may be a long string of random digits.  Yet end
> users understand that they have to use it if they want to follow up.
You've moved the problem around again :)

I have thought about a pre-recorded telephone messages to provide
authenticity assurances. What do we do when the telecoms are in bed
with the government? Its happened in real life: the US Congress passed
a law that it [unauthorized wiretapping and domestic spying] was OK
after the fact, even though it was illegal before the incident
(https://www.eff.org/nsa-spying). Is there any difference between
spying and tampering?

In the end, I think telephone based assurances are an untrusted
channel. The risk may be acceptable to you based on your data
sensitivity. I choose not to trust them (it's part of my
'infrastruture is insecure' mantra).

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

Re: [cryptography] Client TLS Certificates - why not?

[Michael Rogers]

I don't think most non-programmers would differentiate between a string of hex 
digits and an arbitrary alphanumeric string, so you might as well use base 32. 
But do you really need to encode more bits? With a ZRTPish hash commitment / 
key exchange / confirmation code structure you can detect a MITM attack with 
probability 1 - 1/2^b, where b is the number of bits in the confirmation code. 
A 19-bit code fits into six decimal digits and fails to detect a MITM attack 
with a probability less than one in half a million, which strikes me as a good 
tradeoff between convenience and security.

Cheers,
Michael


ianG  wrote:

>On 6/03/13 14:33 PM, StealthMonger wrote:
>
>> Your only argument is that the key ID is "longer" or more "random".
>
>This of course is the ZT challenge.  The issue isn't that Zooko's 
>Triangle can or can't be squared, but that we the developer have to 
>square it [0].
>
>
>> A
>> solution is redesign of the hash code so it doesn't have to be so long
>> plus maybe merchant generating and discarding lots of keys until
>> stumbling on one with a pronounceable hash.
>
>
>I'm currently working on an invite process from phone to phone.  For now 
>I'm just using 6 char hex codes (24 bits).
>
>There's an easy MITM possibility here, which is fineessed by human 
>processes, time and code space.  But once the invite process is over, 
>assuming no MITM, the phones are locked together (in that the internal 
>addressbooks know each other at 1st class crypto level).
>
>I am musing on whether to go to Base 32, like the airline reservation 
>codes.  That seems to be workable, in that I personally manage to not 
>miss my plane most of the time.
>
>Has anyone got any view as to how complicated a handshake code could be 
>before users start making more mistakes than it is worth?
>
>
>
>iang
>
>
>PS: in stricter metaphorical terms, we are pyramiding the triangle into 
>a 4 sided die, but squaring sounds easier on the ear.
>___
>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] Client TLS Certificates - why not?

[ianG]

On 6/03/13 14:33 PM, StealthMonger wrote:


Your only argument is that the key ID is "longer" or more "random".


This of course is the ZT challenge.  The issue isn't that Zooko's 
Triangle can or can't be squared, but that we the developer have to 
square it [0].




A
solution is redesign of the hash code so it doesn't have to be so long
plus maybe merchant generating and discarding lots of keys until
stumbling on one with a pronounceable hash.



I'm currently working on an invite process from phone to phone.  For now 
I'm just using 6 char hex codes (24 bits).


There's an easy MITM possibility here, which is fineessed by human 
processes, time and code space.  But once the invite process is over, 
assuming no MITM, the phones are locked together (in that the internal 
addressbooks know each other at 1st class crypto level).


I am musing on whether to go to Base 32, like the airline reservation 
codes.  That seems to be workable, in that I personally manage to not 
miss my plane most of the time.


Has anyone got any view as to how complicated a handshake code could be 
before users start making more mistakes than it is worth?




iang


PS: in stricter metaphorical terms, we are pyramiding the triangle into 
a 4 sided die, but squaring sounds easier on the ear.

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

Re: [cryptography] Client TLS Certificates - why not?

[StealthMonger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"James A. Donald"  writes:

> On 2013-03-06 4:41 AM, StealthMonger wrote:
>> 2. Prospective customer verification of merchant: Merchant includes
>> the ID of its signing key in every advertisement and repeatedly
>> admonishes prospects to "Accept No Substitutes".

> The key, and the hash of the key, is a long string of random
> gibberish.  It should not be visible to end users.  Experience
> demonstrates that showing it repels 99% of end users.

Merchant includes its telephone number in every advertisement and
repeatedly admonishes prospects to call.

The telephone number may be a long string of random digits.  Yet end
users understand that they have to use it if they want to follow up.

Your only argument is that the key ID is "longer" or more "random".  A
solution is redesign of the hash code so it doesn't have to be so long
plus maybe merchant generating and discarding lots of keys until
stumbling on one with a pronounceable hash.

These are not easily accomplished, but they would enable slaying the
CA dragon.


- -- 


 -- StealthMonger 
Long, random latency is part of the price of Internet anonymity.

   anonget: Is this anonymous browsing, or what?
   
http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain

   stealthmail: Hide whether you're doing email, or when, or with whom.
   mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iEYEARECAAYFAlE2+ZEACgkQDkU5rhlDCl7YdQCgqjS4QRv3XmyOgRC/Clf4pDHR
V9IAnikryad50gCwnaugi6YOyslXFlNN
=i1I8
-END PGP SIGNATURE-

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

Re: [cryptography] Client TLS Certificates - why not?

[Martin Paljak]

On Wed, Mar 6, 2013 at 10:40 AM, James A. Donald  wrote:
> Can you implement your above design while hiding the keys in urls, rather
> than inflicting them on the suffering user?

There's a saying in Estonian, literally translated: "who wants to eat
sausages is better off not knowing how sausages are made".

Sausages look tasty, meaty and easy to consume. In reality such
products often contain 70% "garbage" instead of  meat. Which also
means that even if some company wants to do a "real meat" sausage
people who know what meat is and care about what they eat are still
suspicious. Those who don't care can easily be fed sausages that
contain "100% artificial taste, coloring, smell and filling materials"
(in small print) and "100% of needed daily vitamins and minerals" in
large print.

Eventually keys, hashes and similar parameters need to be exposed, if
the system is supposed to be used by people who are not sheep.

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

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

On 2013-03-06 4:41 AM, StealthMonger wrote:

What's wrong with the following simple idea:

1. p2p: The parties opportunistically verify out-of-band after
exchanging keys via public key servers or (insecure) email.

2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to "Accept No Substitutes".

3.  Merchant authentication of Customer: Merchants don't deal with
people.  They deal with keys.  It's the key that has the purchasing
power, not some person.  Nobody has the illusion that correlation
between key and person is any stronger than that person's security
habits.

4.  Etc.



Let us suppose we have urls that contain public keys, or hashes of them, 
or shared secrets, and let us suppose that clients and servers know how 
to handle them:  That the client will insist that the server proves 
knowledge of the corresponding secret key, or knowledge of the shared 
secret, without spilling the shared secret to all and sundry.


Can you implement your above design while hiding the keys in urls, 
rather than inflicting them on the suffering user?

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