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 ?
18 thoughts on - Elliptic Curve On CentOS 6.x
It would have to come from an external repo. The goal of CentOS is to be binary compatible with RHEL, warts and all. So if you know of someone with a repo that has packaged it, it’s best to use that, I would think.
Eero Volotinen wrote:
*Which* elliptic curve? I trust you’ve been reading the revelations from Snowdon about the NSA putting a backdoor in the common ones, esp. the POSIX ones.
mark
what about update to 6.5 which brings it already back
Apache uses it on some rare cases like ‘apache2 uses NID_X9_62_prime256v1
for the ECDH exchange’
My idea is to enable EC on CentOS due to PFS and better encryption levels
RedHat no longer disables the EC ciphers as of RHEL6.5
Peter
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 even don’t have words to comment on this!!!
Adrian
I tweeted about this exact point a few minutes ago; given the way and what is compromised in what manner, and then work back to what FIPS is, it helps dilute the shock. a bit. but then who’s got the funds and resources to re-work the fips process with a new codebase ? Will Red Hat ?
– KB
at this point i am thinking: why bother (with re-certification)? because of this (among other things) the trust in “fips process” or other
“official” processes is in free fall.. 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!
Adrian
Adrian Sevcenco wrote:
I’m a complete innocent in this area, but is it necessary to be
“FIPS 140-2 compliant” if you are not dealing the US (or other?) government?
Ahmed Hassan said the following on 03/01/2014 13:47:
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?
Nb What you say may be perfectly valid, I’d just like to know exactly what it means, if indeed it has a mathematical meaning.
Timothy Murphy said the following on 03/01/2014 14:20:
The mathematic behind a PRNG (or DRNG to use NIST terminolgy) + Elliptic Curve falls beyond my comprehension, so I have to take for granted what experts say.
The link to PDF I qoted in my previous message goes deep in detail, you can refer to that paper if you need more informations.
In essence it means that if an algorythm that builds its foundations on the fact that each new number of a sequence is not predictable, when that sequence generates predictable numbers, the algorythm fails.
You deleted the statement I queried. Here it is
“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”
I don’t believe in “proof by expertise”. You used the work “entropy”. I’m asking what you mean by it.
You used the word. I’m asking what you meant by it.
The nearest this comes to a definition of “empirical” entropy is
“Accumulate the nearest predecessor distance between byte values in a 256000 + 2560 bit sequence and calculate the empirical entropy”
On this basis the digits of pi are random, in which case it would be easy to supply random numbers.
Shannon entropy only makes sense when applied to a random variable. It cannot be applied to a single string, as in this case.
Algorithmic entropy (Kolmogorov complexity) can be applied to a single string, but it cannot be measured directly.
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 when those random external events aren’t ongoing at a high enough rate relative to your requirements for new random numbers, eventually the ‘entropy’ runs out, and the sequence becomes increasingly predictable.
John R Pierce wrote:
According to Wikipedia
“A random seed (or seed state, or just seed) is a number (or vector) used to initialize a pseudorandom number generator.”
It is impossible to measure the entropy of a single number, or vector. If you think it is, tell me how you measure it.
18 thoughts on - Elliptic Curve On CentOS 6.x
It would have to come from an external repo. The goal of CentOS is to be binary compatible with RHEL, warts and all. So if you know of someone with a repo that has packaged it, it’s best to use that, I would think.
Eero Volotinen wrote:
*Which* elliptic curve? I trust you’ve been reading the revelations from Snowdon about the NSA putting a backdoor in the common ones, esp. the POSIX ones.
mark
what about update to 6.5 which brings it already back
I already noticed it:
https://twitter.com/reaperhulk/status/407384786114596864
So only needed thing is recompile ec enabled packages (like httpd) for CentOS?
is compromised: http://blog.0xbadc0de.be/archives/155
Apache uses it on some rare cases like ‘apache2 uses NID_X9_62_prime256v1
for the ECDH exchange’
My idea is to enable EC on CentOS due to PFS and better encryption levels
2014/1/3 David Benfell
Interesting read on the openssl-announce list:
http://www.mail-archive.com/openssl-announce@openssl.org/msg00127.html Turns out the openssl implementation of Dual_EC_DRBG was broken anyway…
– Jitse
Yes, yum update should do it.
RedHat no longer disables the EC ciphers as of RHEL6.5
Peter
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 even don’t have words to comment on this!!!
Adrian
I tweeted about this exact point a few minutes ago; given the way and what is compromised in what manner, and then work back to what FIPS is, it helps dilute the shock. a bit. but then who’s got the funds and resources to re-work the fips process with a new codebase ? Will Red Hat ?
– KB
at this point i am thinking: why bother (with re-certification)? because of this (among other things) the trust in “fips process” or other
“official” processes is in free fall.. 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!
Adrian
Adrian Sevcenco wrote:
I’m a complete innocent in this area, but is it necessary to be
“FIPS 140-2 compliant” if you are not dealing the US (or other?) government?
Ahmed Hassan said the following on 03/01/2014 13:47:
The algorythm behind /dev/urandom is not robust
(http://eprint.iacr.org/2013/338.pdf)
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
Some entropy generator daemon such as timer_entropyd
(http://www.vanheusden.com/te/), haveged (http://www.issihosts.com/haveged/)
or randomsound (http://www.digital-scurf.org/software/randomsound) can be used to generate more entropy
Ciao, luigi
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?
Nb What you say may be perfectly valid, I’d just like to know exactly what it means, if indeed it has a mathematical meaning.
Timothy Murphy said the following on 03/01/2014 14:20:
The mathematic behind a PRNG (or DRNG to use NIST terminolgy) + Elliptic Curve falls beyond my comprehension, so I have to take for granted what experts say.
The link to PDF I qoted in my previous message goes deep in detail, you can refer to that paper if you need more informations.
In essence it means that if an algorythm that builds its foundations on the fact that each new number of a sequence is not predictable, when that sequence generates predictable numbers, the algorythm fails.
There are some models that define or analyze if a sequence is “randomic” you can google around or take a look at http://www.issihosts.com/haveged/ais31.html
Mind that you can end up with a big headache :)
Ciao, luigi
Luigi Rosa wrote:
You deleted the statement I queried. Here it is
“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”
I don’t believe in “proof by expertise”. You used the work “entropy”. I’m asking what you mean by it.
You used the word. I’m asking what you meant by it.
The nearest this comes to a definition of “empirical” entropy is
“Accumulate the nearest predecessor distance between byte values in a 256000 + 2560 bit sequence and calculate the empirical entropy”
On this basis the digits of pi are random, in which case it would be easy to supply random numbers.
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 wrote:
Shannon entropy only makes sense when applied to a random variable. It cannot be applied to a single string, as in this case.
Algorithmic entropy (Kolmogorov complexity) can be applied to a single string, but it cannot be measured directly.
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 when those random external events aren’t ongoing at a high enough rate relative to your requirements for new random numbers, eventually the ‘entropy’ runs out, and the sequence becomes increasingly predictable.
John R Pierce wrote:
According to Wikipedia
“A random seed (or seed state, or just seed) is a number (or vector) used to initialize a pseudorandom number generator.”
It is impossible to measure the entropy of a single number, or vector. If you think it is, tell me how you measure it.