Re: [cryptography] embbeded pw kdf?

On Fri, Aug 5, 2016 at 12:07 PM, stef wrote: > is the best one can do in such situations a naive: > > H0 = password > H_n = hash(H_n-1, device unique salt), 1<=nhttp://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [FORGED] Re: Kernel space vs userspace RNG

On Tue, May 17, 2016 at 11:29 AM, Jaromil wrote: > how about a lavalamp :^) lavalamp is nice. its slow moving blobs generate some dozen or hundred bits per second, i don't know how much, but not too much. it is then gets recorded by a camera that easily generates many kilobytes

Re: [cryptography] Kernel space vs userspace RNG

On Fri, May 13, 2016 at 10:19 AM, Luca Testoni wrote: > Not only time but initial conditions too. > The result of a chaotic system is strongly dependent on intial > conditions too. okay, let me rephrase, because i was not very clear. what i tried to say is: if we assume a

Re: [cryptography] Kernel space vs userspace RNG

d...@deadhat.com (at Saturday, May 7, 2016, 11:35:24 PM): > Well designed entropy sources > on silicon generate between 200Mbits/s and 5Gbits/s per source. I think > most vendors are getting in on the act. We have been pretty open with our > ES designs and I've seen very smart ES papers. I

Re: [cryptography] Kernel space vs userspace RNG

Russell Leidich (at Saturday, May 7, 2016, 8:47:33 PM): > Whatever its absolute value might be, the amount of entropy in the > DMA timing skew has to be higher in practice than that in interrupt > timing. The reason is that, for every interrupt, thousands or even > billions of DMA transactions

Re: [cryptography] Kernel space vs userspace RNG

Russell Leidich (at Friday, May 6, 2016, 10:16:12 PM): > Most of the entropy in a system is manifest in terms of the clock > skew between direct memory access (DMA) transfers from external > devices and the CPU core clocks, which unfortunately does not > traverse the kernel in any directly

Re: [cryptography] Kernel space vs userspace RNG

Russell Leidich (at Friday, May 6, 2016, 7:48:49 PM): > a "real world" situation, userspace is richer because it's active > maybe 2 or 3 orders of magnitude more often than the kernel, and so > can afford to accrue much more timing entropy, some of which is > bound to be physical in origin.

Re: [cryptography] Kernel space vs userspace RNG

On Thu, May 5, 2016 at 11:40 AM, shawn wilson wrote: > Just reflecting on the Linux RNG thread a bit ago, is there any technical > reason to have RNG in kernel space? i think it is worthwhile to separate the topic to entropy collection and prng. prng is the easier part. the

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

On Fri, May 29, 2015 at 12:25 AM, Russell Leidich pke...@gmail.com wrote: I'm the first to admit that I don't understand where the entropy is coming from. knowing where the entropy is coming from and knowing the amount of entropy is the same thing. it is because we don't have a way to measure

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

On Thu, May 28, 2015 at 6:59 AM, James A. Donald jam...@echeque.com wrote: The system can be thought of as pseudorandom number generator that is continually seeded by a small amount of true randomness. beware about seeding. as the wisdom goes, once you seeded your prng with at least 128 bit

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

i call bullshit on this one, just as i called bullshit on havege. a proper hwrng always outputs the raw, unfiltered random bits. and an estimate of the the entropy content. whitening is easy, and can be done various ways, it is not interesting. many times we don't even want whitening, because we

Re: [cryptography] Javascript scrypt performance comparison

coderman (at Saturday, May 9, 2015, 12:49:22 PM): ... use pseudorandom indexing to access the data, also based on the password ... it is essential to the algorithm, and can not be written in a side channel safe way. even paired with a separate pseudo-random sequence? both executed in

Re: [cryptography] Javascript scrypt performance comparison

coderman (at Saturday, May 9, 2015, 3:56:06 AM): The reality is: bcrypt, scrypt, and most PHC finalists use password dependent memory lookups, and thus are not cache-timing safe... In typical scenarios, this does not matter. In some, it does. has there been consideration of a processor

Re: [cryptography] What's the point of using non-NIST ECC Curves?

If the NIST curves are weak in a way that we don't understand, this means that ECC has properties that we don't understand. Thus, if you don't trust the NIST Prime curves, does it make sense to trust any ECC curves at all? All maths has properties we do not understand. the question is not

Re: [cryptography] What's the point of using non-NIST ECC Curves?

On Mon, Oct 13, 2014 at 4:51 PM, Derek Miller dreemkil...@gmail.com wrote: However, considering one of the scenarios where these curves might be compromised (the NSA knew of weaknesses in certain curves, and engineered the NIST Prime curves to be subject to those weaknesses) interestingly,

Re: [cryptography] What's the point of using non-NIST ECC Curves?

Derek Miller (at Monday, October 13, 2014, 6:19:07 PM): However, both scenarios (NSA engineered them to be bad, NSA engineered them to be good) mean that the NSA knows a great deal more about weaknesses in Elliptic Curve Cryptography than we do. Doesn't that give you great pause in using the

Re: [cryptography] Email encryption for the wider public

On Thu, Sep 18, 2014 at 10:57 AM, stef s...@ctrlc.hu wrote: let me summarize (and ask you to reread and understand) grapamps response to you: email is dead. email is not dead, it is a zombie that walks around for at least 20 years. btw do you guys aware of IM2000? http://cr.yp.to/im2000.html

Re: [cryptography] ECC curves that are safe safecurves.cr.yp.to

D. J. Bernstein (at Monday, January 20, 2014, 8:01:20 PM): Brainpool, in particular, generated curves using a method with _some_ details that are not explained anywhere in the Brainpool documents. let me add that nothing prevents the authors from publishing their design rationale, especially

Re: [cryptography] SafeCurves evaluation of secp256k1 - side channels

Michael Rogers (at Monday, January 13, 2014, 12:13:44 PM): unlucky curves lead to an implementation nightmare If I'm stuck with an 'unlucky' curve for reasons of compatibility, can you give me any advice about checking the implementation for the problems you mention absolutely not, because

Re: [cryptography] SafeCurves evaluation of secp256k1 - side channels

Ondrej Mikle (at Monday, January 13, 2014, 4:55:36 PM): Could you elaborate what you mean by other, worse problems with NIST curves? - the points and coefficients used in NIST and SEC2 curves could be possibly cooked well, it is of course up to opinion, but in my view, lack of rigidity is

Re: [cryptography] SafeCurves evaluation of secp256k1 - side channels

Ondrej Mikle (at Saturday, January 11, 2014, 11:19:30 PM): a) Ladders Does this mean that an implementation of secp256k1 is likely to have timing side-channel attacks? likely might be a strong word. for some curves, an implementor must choose between a safe and a fast and simple

Re: [cryptography] European report says many crypto protocols have problems

Peter Gutmann (at Monday, November 4, 2013, 1:40:26 AM): Then it deprecates PKCS #1 v1.5 (which pretty much the entire planet uses) because it doesn't have a security proof, while recommending a bunch of exotic alternatives that more or less nothing uses. what is the purpose of academic

Re: [cryptography] Passwords13 Bergen

hi, any chance to have a looksie on what happened in vegas? slides or talks online? this is to advertize an event associated to the Password Hashing Competition (PHC, https://password-hashing.net/): Passwords13 Bergen, the latest conference in the Passwords^ series,

Re: [cryptography] Dual_EC_DRBG was cooked, but not AES?

Ed Stone t...@synernet.com at Sunday, September 22, 2013, 3:05:06 PM: Why has AES escaped general suspicion? because it was not created by NIST, nor NSA nor any other US gov org. it was created by the academia, namely two guys, daemen and rijmen (neither of them are americans). the

Re: [cryptography] Fatal flaw in Taiwanese smart card RNG

no. you can't test a rng by looking at the output. only the algorithm and the actual code can be analyzed and reviewed. it is because it is extremely easy to create a crappy rng that fools the smartest analytical tool on the planet. it is not that easy to fool an attacker that reverse

[cryptography] no-keyring public

hi list, i had an epiphany today, and i wonder if such a thing already exists or not. so the usual thing is to create a key pair, store the private key encripted with a password. we automatically get a two factor authentication, we have a know and a have. okay, but what if we don't want this,

Re: [cryptography] no-keyring public

adjisten :) 1. In your system the KDF for creating the seed to PRNG can’t be salted. nope, it can't be. And so two people with the same password will end up with the same key pair. for this reason, and others, a really strong key phrase is needed for that reason. this is definitely a

Re: [cryptography] no-keyring public

Can it not? A distributed store for salts seems possible... but then distributed keyring is also possible, is it not? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] no-keyring public

aha, i'm not that original after all. my attention was called to Dan Kaminsky's Phidelius too. It's very similar (as Greg Rose noted) to IBE, and thus pretty much what I did in: http://middleware.internet2.edu/pki05/proceedings/callas-conventional_ibe.pdf

[cryptography] authentication protocol proposal

hello, admittedly, i got a little bit hyped about Keccak, especially its versatility. so i thought why not devise an authenitcation / key stretching / key derivation / secure storage protocol that uses solely Keccak to achieve all of its goals? i put together a brief (5 page) document describing

[cryptography] random extractor hobby algorithm

dear list, if you want to send me to hell, please first read the disclaimers on the bottom please. now let's just dive in. i propose an algorithm for smoothing a weak random stream of bytes. it is a combined-cycle rc4, that is, we continually feed the rc4 with the random input stream as