John R Pierce wrote:
the seed of a algorithm like /dev/urandom is not a single variable, its
a big array of variables. these have to be created with sufficiently
random external events to achieve a reasonable level of entropy, and if
you continue to generate pseudo-random-numbers from this
On 01/03/2014 03:28 AM, Jitse Klomp wrote:
2014/1/3 David Benfell benf...@parts-unknown.org
I was unable to find an associated vulnerability in Linux. I trust the
OpenSSL folks would be on top of this faster than you can blink an eye
if it were a current issue. They have not, from what I've
On 01/03/2014 11:01 AM, Adrian Sevcenco wrote:
i was just blew away by this:
What almost all commentators have missed is
that hidden away in the small print (and subsequently confirmed by our
specific query) is that if you want to be FIPS 140-2 compliant you MUST
use the compromised points.
On 01/03/2014 01:15 PM, Karanbir Singh wrote:
On 01/03/2014 11:01 AM, Adrian Sevcenco wrote:
i was just blew away by this:
What almost all commentators have missed is
that hidden away in the small print (and subsequently confirmed by our
specific query) is that if you want to be FIPS 140-2
One thing you need to understand.
There is a huge difference between asymmetric encryption and
cryptographically secure pseudo-random number generator. EC is secure, the
default random number generator on Linux is /dev/urandom. It does not use
the backdoored NSA PRNG.
On Fri, Jan 3, 2014 at
Adrian Sevcenco wrote:
i was just blew away by this:
What almost all commentators have missed is
that hidden away in the small print (and subsequently confirmed by our
specific query) is that if you want to be FIPS 140-2 compliant you MUST
use the compromised points.
I'm a complete innocent
Ahmed Hassan said the following on 03/01/2014 13:47:
There is a huge difference between asymmetric encryption and
cryptographically secure pseudo-random number generator. EC is secure, the
default random number generator on Linux is /dev/urandom. It does not use
the backdoored NSA PRNG.
Luigi Rosa wrote:
With headless and/or virtual servers the issue is even bigger because
Linux could not be able to collect enough entropy to seed /dev/urandom
Is this a meaningful statement?
How do you measure the entropy of a seed (which I take to be a string)?
And if you can, is it true that
Timothy Murphy said the following on 03/01/2014 14:20:
Is this a meaningful statement? How do you measure the entropy of a seed
(which I take to be a string)? And if you can, is it true that you can
decrypt a string with low entropy?
The mathematic behind a PRNG (or DRNG to use NIST
Luigi Rosa wrote:
Is this a meaningful statement? How do you measure the entropy of a
seed (which I take to be a string)? And if you can, is it true that you
can decrypt a string with low entropy?
You deleted the statement I queried. Here it is
With headless and/or virtual servers the issue
On 1/3/2014 8:37 AM, Timothy Murphy wrote:
I'm asking what you meant by it.
Entropy has a standard meaning in computer science, see
http://en.wikipedia.org/wiki/Information_entropy for an introductory
discussion with various references.
--
john r pierce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/03/2014 03:36 AM, Adrian Sevcenco wrote:
IMHO underlying problem is not
that a cipher/process/code was compromised but that the
supervising _trustworthy_ entity is in fact not trustworthy at
all!
It will be interesting to see how this
John R Pierce wrote:
Entropy has a standard meaning in computer science, see
http://en.wikipedia.org/wiki/Information_entropy for an introductory
discussion with various references.
Shannon entropy only makes sense when applied to a random variable.
It cannot be applied to a single string, as
On 1/3/2014 4:25 PM, Timothy Murphy wrote:
Shannon entropy only makes sense when applied to a random variable.
It cannot be applied to a single string, as in this case.
the seed of a algorithm like /dev/urandom is not a single variable, its
a big array of variables. these have to be created
Hi,
Is there nice way to put back EC encryption on Centos?
RHEL disabled it due patent issues, but is third party providing packages
to EC enabled packages to centos ?
--
Eero
___
CentOS mailing list
CentOS@centos.org
On 02/01/14 04:16 PM, Eero Volotinen wrote:
Hi,
Is there nice way to put back EC encryption on Centos?
RHEL disabled it due patent issues, but is third party providing packages
to EC enabled packages to centos ?
It would have to come from an external repo. The goal of CentOS is to be
Eero Volotinen wrote:
Is there nice way to put back EC encryption on Centos?
RHEL disabled it due patent issues, but is third party providing
packages to EC enabled packages to centos ?
*Which* elliptic curve? I trust you've been reading the revelations from
Snowdon about the NSA putting a
what about update to 6.5 which brings it already back
why do you not keep your system up-to-date at all?
ECHDE with CentOS 6.5 works fine and is one of the 6.5 features
I already noticed it:
https://twitter.com/reaperhulk/status/407384786114596864
So only needed thing is recompile ec enabled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/02/2014 01:22 PM, m.r...@5-cent.us wrote:
Eero Volotinen wrote:
Is there nice way to put back EC encryption on Centos?
RHEL disabled it due patent issues, but is third party
providing packages to EC enabled packages to centos ?
- From what I've been able to find, this is a bit overstated.
There is *one* random number algorithm (Dual_EC_DRBG) associated with
ECC that is believed to have been compromised. That it appeared
is compromised: http://blog.0xbadc0de.be/archives/155
vulnerable has long been known; Bruce
2014/1/3 David Benfell benf...@parts-unknown.org
I was unable to find an associated vulnerability in Linux. I trust the
OpenSSL folks would be on top of this faster than you can blink an eye
if it were a current issue. They have not, from what I've seen,
reacted to the revelations.
On 01/03/2014 10:16 AM, Eero Volotinen wrote:
Hi,
Is there nice way to put back EC encryption on Centos?
Yes, yum update should do it.
RHEL disabled it due patent issues
RedHat no longer disables the EC ciphers as of RHEL6.5
Peter
___
CentOS
22 matches
Mail list logo
