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 ever
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 tar
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 ever
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 M
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
-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 Su
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 a
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 s
