>Well clearly passwords are bad and near the end of their life-time with
>GPU advances, and even amplified password authenticated key exchanges like
>EKE have a (so far) unavoidable design requirement to have the server
>store something offline grindable, which could be key stretched, but that
On Sun, Sep 29, 2013 at 8:57 AM, Michael Rogers
wrote:
>
> We're also planning to support introductions through mutually trusted
> third parties.
[...]
> Alice and Carol must trust Bob not to MITM the key exchange.
It'd be nice if Alice and Carol could use some additional, out-of-band
channel to
On 2013-09-30, at 10:43 AM, Adam Back wrote:
> On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote:
>> On 30/09/13 10:47, Adam Back wrote:
>>> PBKDF2 + current GPU or ASIC farms = game over for passwords.
>>
>> what about stronger pwd-based key exchange like SRP and JPAKE?
Well SRP most cert
So then, the Sage in the comic is on the right path?
http://tacobell.wikia.com/wiki/7-Layer_Burrito
On Fri, Sep 27, 2013 at 3:02 AM, Peter Gutmann
wrote:
> Paul Bakker writes:
>
>>So you agree we DO need an additional layer of symmetric and public key
>>encryption, don't you? Six layers might n
* Lodewijk andré de la porte:
[OTP assumptions]
> 1. Good source. P[i] must be independent to anything in P nor to the method
> to generate P. "Random", you'd typically say. Fully unpredictable might be
> more clear (given people's unclarity about what's random).
> 2. No leak of P
3. Message int
On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote:
The only attack is on the PBKDF2 stored on the server (or malware to grab
the password on the client)
right. I was think SRP/JPAKE where the server does not store
PBKDF2(salt,pwd) server-side, but rather it stores something like
g^{PBKDF2(
On 30/09/13 19:41, Wasa wrote:
- with no server
i meant "with no password". Arguably we can have decoy password if users
feel more secure with them :-)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinf
On 30/09/13 19:22, Adam Back wrote:
On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote:
Also the PBKDF2 / scrypt happens on the client side - how do you think
your ARM powered smart phone will compare to a 9x 4096 core GPU
monster. Not well :)
How much would it help to delegate PBKDF2 / scr
On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote:
Also the PBKDF2 / scrypt happens on the client side - how do you think
your ARM powered smart phone will compare to a 9x 4096 core GPU monster.
Not well :)
How much would it help to delegate PBKDF2 / scrypt to smartphone GPU to
break this a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/27/2013 09:35 AM, Eugen Leitl wrote:
> I don't see how a ham running a repeater backbone can prevent end
> to end encryption other than sniffing for traffic and actively
> disrupting it. I'm not sure tampering
If enough hams (or one sufficientl
On 30/09/13 16:43, Adam Back wrote:
On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote:
On 30/09/13 10:47, Adam Back wrote:
Well clearly passwords are bad and near the end of their life-time with
GPU advances, and even amplified password authenticated key
exchanges like
EKE have a (so far)
On 09/30/13 17:43, Adam Back wrote:
> Anyway and all that because we are seemingly alergic to using client side
> keys which kill the password problem dead.
Hi Adam,
I wondered about that 'allergy' myself. I have some ideas about that and
I'm curious to learn about other.
Here are mine:
1. T
On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote:
On 30/09/13 10:47, Adam Back wrote:
Well clearly passwords are bad and near the end of their life-time with
GPU advances, and even amplified password authenticated key exchanges like
EKE have a (so far) unavoidable design requirement to have
On 30/09/13 10:47, Adam Back wrote:
Well clearly passwords are bad and near the end of their life-time
with GPU
advances, and even amplified password authenticated key exchanges like
EKE
have a (so far) unavoidable design requirement to have the server store
something offline grindable, which c
Hi,
>> I am not so sure many servers support it, though. My latest data,
>> unfortunately, is not evaluated yet. But in 2011 the difference between
>> switching on SNI and connecting without it, was pretty meagre across the
>> Alexa range. Granted, many of those hosts may not be VHosts.
>>
>> Does
(repost from Crypto with a Kapital C, slightly editted. I think this is
more software engineering than crypto).
On 28/09/13 20:07 PM, Stephen Farrell wrote:
b) is TLS1.3 (hopefully) and maybe some extensions for earlier
versions of TLS as well
SSL/TLS is a history of fiddling around a
On 30 September 2013 07:07, Ralph Holz wrote:
> Hi Ben,
>
>> Boy, are you out of
>> date: http://en.wikipedia.org/wiki/Server_Name_Indication.
>
> I am not so sure many servers support it, though. My latest data,
> unfortunately, is not evaluated yet. But in 2011 the difference between
> switching
Hi Ben,
> Boy, are you out of
> date: http://en.wikipedia.org/wiki/Server_Name_Indication.
I am not so sure many servers support it, though. My latest data,
unfortunately, is not evaluated yet. But in 2011 the difference between
switching on SNI and connecting without it, was pretty meagre across
I am not sure if everyone is aware that there is also an unmoderated crypto
list, because I see old familiar names posting on the moderated crypto list
that I do not see posting on the unmoderated list. The unmoderated list has
been running continuously (new posts in every day with no gaps) since
On 30 September 2013 10:47, Adam Back wrote:
> I think lack of soft-hosting support in TLS was a mistake - its another
> reason not to turn on SSL (IPv4 addresses are scarce and can only host one
> SSL domain per IP#, that means it costs more, or a small hosting company
> can
> only host a limite
On Mon, Sep 30, 2013 at 11:49:49AM +0300, ianG wrote:
On 30/09/13 11:02 AM, Adam Back wrote:
no ASN.1, and no X.509 [...], encrypt and then MAC only, no non-forward
secret ciphersuites, no baked in key length limits [...] support
soft-hosting [...] Add TOFO for self-signed keys.
Personally,
21 matches
Mail list logo