Just FYI, you are going to run into the problem of key portability. If the
key is derived from a password, your encrypted copy of the user's data
(which might be subject to subpoena?) could be easily cracked via offline
dictionary attacks. I hope you at least plan to use a salt, many iterations
of
On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich wrote:
> On Mar 18, 2011, at 12:56 PM, Shabsi Walfish wrote:
>
> I'm not convinced that this use case, or any other use case I could think
> of for the web (with the possible exception of DRM/encryption on streaming
> media),
Hi Robert,
I've put some thought into this topic, and I have a few comments for you
(see below).
On Fri, Mar 18, 2011 at 10:09 AM, Robert Accettura wrote:
> I'll prefix this by saying I'm not entirely certain if this should be
> ECMA vs. HTML5 or dual track similar to the "Cryptographically str
On Wed, Feb 16, 2011 at 11:05 AM, David Wagner wrote:
> Shabsi Walfish writes:
> > I think the question is whether or not this can be done in general
> without
> > blocking -- if you block, you can definitely get crypto-quality random
> > numbers, but otherwise its no
On Mon, Feb 14, 2011 at 4:15 PM, Glenn Maynard wrote:
> On Mon, Feb 14, 2011 at 6:43 PM, Shabsi Walfish wrote:
>
>> OpenSSL is not exactly a reliable source of cryptographic best practices.
>> :) In any case, see here http://linux.die.net/man/4/urandom :
>
>
>
On Mon, Feb 14, 2011 at 3:49 PM, Bill Frantz wrote:
> On 2/14/11 at 2:46 PM, sha...@google.com (Shabsi Walfish) wrote:
>
> This depends on what you consider to be the basic use case. Generating
>> long-lived cryptographic keys absolutely requires high quality entropy...
>&g
such an attack may exist. If this is a concern
in your application, use */dev/random* instead.
To be honest, I'm surprised if even OpenSSL reads from /dev/urandom instead
of /dev/random.
Shabsi
On Mon, Feb 14, 2011 at 3:36 PM, Glenn Maynard wrote:
> On Mon, Feb 14, 2011 at 5:46 PM, Shabsi
ony feature-rich take on a
> crypto library.
>
> Adam
>
>
> On Mon, Feb 14, 2011 at 2:37 PM, Shabsi Walfish wrote:
> > It'd be nice if there was at least a way to explicitly detect if you were
> > getting "weaker" entropy... In linux, for example, t
It'd be nice if there was at least a way to explicitly detect if you were
getting "weaker" entropy... In linux, for example, there is a /proc
filesystem entry (/proc/sys/kernel/random/entropy_avail) that indicates how
much entropy is available in the pool.
Shabsi
On Mon, Feb 14, 2011 at 2:30 PM,
On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish wrote:
>
>
> On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth wrote:
>
>> On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller wrote:
>>
>>> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth wrote:
>>>
>>>&g
Re-posting for es-discuss
On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish wrote:
>
>
> On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth wrote:
>
>> On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller wrote:
>>
>>> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth wrote:
&
Re-posting for es-discuss
On Mon, Feb 14, 2011 at 8:30 AM, Shabsi Walfish wrote:
> I think a good source of cryptographically secure entropy is _much_ higher
> priority than any other crypto related APIs you might consider
> standardizing... given a good source of entropy, everythin
12 matches
Mail list logo
