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,
On 30 September 2013 10:47, Adam Back a...@cypherspace.org 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
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)
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
On 30 September 2013 07:07, Ralph Holz h...@net.in.tum.de 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
(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
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 Google
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
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 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.
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)
-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 sufficiently
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
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 /
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
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
* 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
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
pgut...@cs.auckland.ac.nz wrote:
Paul Bakker p.j.bak...@offspark.com writes:
So you agree we DO need an additional layer of symmetric and public
On 2013-09-30, at 10:43 AM, Adam Back a...@cypherspace.org 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
On Sun, Sep 29, 2013 at 8:57 AM, Michael Rogers
mich...@briarproject.org 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,
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 thats
21 matches
Mail list logo
