dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1616

rexbinary
MOD King
Premium Member
join:2005-01-26
Plano, TX
·Frontier FiberOp..

2 recommendations

rexbinary

Premium Member

We cannot trust Intel and Via's chip-based crypto, FreeBSD developers say

Developers of the FreeBSD operating system will no longer allow users to trust processors manufactured by Intel and Via Technologies as the sole source of random numbers needed to generate cryptographic keys that can't easily be cracked by government spies and other adversaries.
»arstechnica.com/security ··· ers-say/

EUS
Kill cancer
Premium Member
join:2002-09-10
canada

EUS

Premium Member

Interesting. I'm glad someone's writing publicly about potential hardware backdoors.
Nothing mentioned about AMD is also interesting.
GraysonPeddi
Grayson Peddie
join:2010-06-28
Tallahassee, FL

GraysonPeddi

Member

Yeah, I'm curious about AMD.

aefstoggaflm
Open Source Fan
Premium Member
join:2002-03-04
Bethlehem, PA
Linksys E4200
ARRIS SB6141

aefstoggaflm to rexbinary

Premium Member

to rexbinary
#1 Then who can you trust:

a) Some other vendor like: AMD

OR

b) Users must make their own chip(s)

??

#2 If users make their own chips, how will FreeBSD developers know that the users did not made mistakes?

Thank you

InternetsSrs
@199.116.116.x

InternetsSrs to rexbinary

Anon

to rexbinary
I didn't really see anything concrete there other than conjecture-based assumptions. I'm fine with using Yarrow to stir the pool and all, but this strikes me as a little bit of FUD.

Caveat - I use via_rng (Padlock).

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI to aefstoggaflm

MVM

to aefstoggaflm
said by aefstoggaflm:

If users make their own chips, how will FreeBSD developers know that the users did not made mistakes?

This isn't about mistakes. Quite the contrary, it's very much about big budgets to make sure those "dice" are "loaded" a little bit.

aefstoggaflm
Open Source Fan
Premium Member
join:2002-03-04
Bethlehem, PA
Linksys E4200
ARRIS SB6141

aefstoggaflm

Premium Member

said by Bill_MI:

said by aefstoggaflm:

If users make their own chips, how will FreeBSD developers know that the users did not made mistakes?

This isn't about mistakes. Quite the contrary, it's very much about big budgets to make sure those "dice" are "loaded" a little bit.

What do you mean by that?

Thank you

PS. That info that I posted was based upon the info from grc.com -> Services -> Security Now! -> Security Now 2010 -> Episode #246 | 29 Apr 2010 | 89 min. Listener Feedback #91 - Question 6. Summary/Wiki page about that episode see »wiki.twit.tv/wiki/Securi ··· _Now_246

InternetsSrs
@199.116.116.x

InternetsSrs to Bill_MI

Anon

to Bill_MI
said by Bill_MI:

This isn't about mistakes. Quite the contrary, it's very much about big budgets to make sure those "dice" are "loaded" a little bit.

Where is the evidence of this, specially, that VIA's padlock and the via_rng kernel module or Intel's intel_rng has been compromised, tampered with, or designed to provide "predictable entropy" in favourable circumstances?

All that I have seen thus far, no offense intended, is fear-driven conjecture and in some cases implementation of less random solutions, such as say deterministic Yarrow over quantum random solutions like VIA's Padlock which uses frequency instabilities of multiple free running oscillators.

»www.via.com.tw/en/initia ··· .jsp#rng
»www.via.com.tw/en/downlo ··· _rng.pdf

On GNU/Linux, even bad entropy is good entropy, since it stirs the pool.

Da Geek Kid
join:2003-10-11
::1

Da Geek Kid

Member

if it can remotely suggested that a random number of numbers produce a set of random that can be duplicated under a random pattern which than can be put thru to be accessed no matter how remote, it is wise to think another way to create your random number and I think it's a good start for FreeBSD. I am surprised though OpenBSD has not said anything thus far. Also, it means that All iNt3l Apple computers would fall under this backdoor as well.

InternetsSrs
@199.116.116.x

InternetsSrs

Anon

What? No, OS X/iOS uses Yarrow for it's RNG and system jitter kind of like HAVEGED, not Intel's HWRNG.

»developer.apple.com/libr ··· m.4.html

iOS uses Yarrow and jitter kind of like HAVEGED.

»www.apple.com/ipad/busin ··· ct12.pdf

HAVEGED - »www.issihosts.com/haveged/

I think Yarrow is a great PRNG, but a strong RNG it does not make, and I wouldn't trust it anymore than I would trust a good HWRNG capable of much better non-deterministic output. Not to mention no one has proved, outside of speculative conjecture, that Intel or VIAs HWRNGs have been tampered with.

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI to InternetsSrs

MVM

to InternetsSrs
said by InternetsSrs :

Where is the evidence of this, specially, that VIA's padlock and the via_rng kernel module or Intel's intel_rng has been compromised, tampered with, or designed to provide "predictable entropy" in favourable circumstances?

It doesn't really matter.

If our encryption is to be trusted yet has such vulnerabilities, real, hypothetical, conjectured or even remotely possible, they MUST be closed or trust is violated. This isn't real complicated.

Maxo
Your tax dollars at work.
Premium Member
join:2002-11-04
Tallahassee, FL

Maxo

Premium Member

said by Bill_MI:

If our encryption is to be trusted yet has such vulnerabilities, real, hypothetical, conjectured or even remotely possible, they MUST be closed or trust is violated. This isn't real complicated.

He seems to agree that adding the additional Yarrow is the right thing to do. He is merely arguing that the basis of it seems to come from FUD.

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

said by Maxo:

He seems to agree that adding the additional Yarrow is the right thing to do. He is merely arguing that the basis of it seems to come from FUD.

I hope I didn't misunderstand. Sorry, InternetsSrs, if I did.

Since June 2013, the pendulum has taken quite a swing to the "suspicious" side of things. We're finding out all sorts of well-funded programs exist to thwart encryption using all sorts of techniques and backed by top encryption experts.

But during any such drastic pendulum swing, opinions will polarize to maximum. It's to be expected. Nothing more.

InternetsSrs
@199.116.116.x

InternetsSrs

Anon

No worries Bill, I think if I could convey what I am trying to say concisely -- the egress from a quantum random source of entropy to a deterministic source of entropy is reckless when there is no evidence to support the quantum random source has been engineered to be deterministic.

If I were running a disinformation campaign with the goal of weakening encryption by suggesting moves away from HWRNGs to Yarrow this would be precisely how I'd do it. Until we have supporting evidence that shows these HWRNGs have been compromised any decision tree, especially adoption of less random sources of entropy, are in my eyes choices made around emotion, fear, and speculative conjecture not those made around fact and a data-driven approach. Using a quantum random HWRNG to feed a deterministic PRNG like Yarrow and calling it a "good source of entropy" is misleading.

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI

MVM

Good point, the old reverse psychology trick, especially if Yarrow has been already fully characterized. It is pretty old and ubiquitous in the BSD world.

But then, if the seed/input is truly *perfect*, any software RNG would degrade it - can't be better. Fascinating.

InternetsSrs
@199.116.116.x

InternetsSrs

Anon

said by Bill_MI:

If the seed/input is truly *perfect*, any software RNG would degrade it - can't be better. Fascinating. :-)

Exactly. This move should be titled "How to introduce predictability into unpredictability". I think there are mislead opportunistic folks taking advantage of a clearly polarized community. I am not insinuating any malice from the FreeBSD folks, nor Yarrow itself, however the selection of Yarrow as a deterministic RNG over an HWRNG because the HWRNG "might" be "compromised" seems highly assumptive and active dilution of quality entropy.

Even Bruce himself calls Yarrow a PRNG -- »www.schneier.com/yarrow.html
quote:
Yarrow
A secure pseudorandom number generator line drawing of yarrow leaves and flower

Note: Yarrow is no longer being supported.

Designed by Bruce Schneier and John Kelsey - Result of several years' research - Renders information security systems far less vulnerable - Unpatented and royalty-free - No license required
quote:
Yarrow is a PRNG; it generates cryptographically secure pseudorandom numbers on a computer.
I'm sorry folks, I'll stick with VIAs Padlock via via_rng, a true quantom random source of entropy and not a deterministic PRNG. Bill et al, thank you for this discussion I've really enjoyed the exchange. Best wishes friends.

Here's my seasonal gift you to, 512 bytes of quantum random entropy:

$ cat /proc/sys/kernel/random/entropy_avail; dd if=/dev/random of=/dev/stdout bs=512 count=1 2>/dev/null|xxd
3968
0000000: b192 99ad 0091 0a2a e065 efd4 82db dbb8  .......*.e......
0000010: 3400 b099 0171 dc76 9dc8 a31d 0e5e 169b  4....q.v.....^..
0000020: 995b a633 d622 e852 ed9a d714 8d67 db4f  .[.3.".R.....g.O
0000030: a514 b418 eed4 0a81 97bd 7efb ba64 ba10  ..........~..d..
0000040: bf56 5630 befd 890f be72 5b01 44be 86dd  .VV0.....r[.D...
0000050: d510 94fd f5a1 5f76 5448 ebb2 8088 7240  ......_vTH....r@
0000060: 1017 1d04 1aa2 1416 e8b3 d064 8416 496e  ...........d..In
0000070: 2d3a a859 289d 3a1e 4501 372e 03b1 94ac  -:.Y(.:.E.7.....
 

rolfp
no-shill zone
Premium Member
join:2011-03-27
Oakland, CA

rolfp

Premium Member

$ cat /proc/sys/kernel/random/entropy_avail; dd if=/dev/random of=/dev/stdout bs=512 count=1 2>/dev/null|xxd
176
0000000: 5a67 1fb5 f513 18da 53a9 15d1 6c89 0b04  Zg......S...l...
 

Bummer! Your entropy's bigger than mine. :(

Bill_MI
Bill In Michigan
MVM
join:2001-01-03
Royal Oak, MI
TP-Link Archer C7
Linksys WRT54GS
Linksys WRT54G v4

Bill_MI to InternetsSrs

MVM

to InternetsSrs
While berserken has his crisis , I'd like to add my thoughts on this...

Yes, it would be a perfect ploy, if quantum randomness was bad for the decrypters, removing years of characterization work on other RNGs. What better way than to spread distrust?

When someone calculates 1,000,000 centuries to crack some crypto by brute force, this usually assumes perfect entropy. I've always figured it wouldn't take much bias to get that down to 100 years AND such a bias would take a comparable amount of time to prove. Randomness is full of estimates and approximations but the big numbers makes it a nasty thing to really prove.

Then, high-dollar equipment takes 100 years down to just a week or so. Especially if you know the exact nature of that teeny tiny bias, or plant a mathematically known hidden bias that makes it through all the standard tests. THAT is where a lot of fear is, for sure.

I'd love to ask a crypto expert if a RNG had significant bias based on, say, time of day, if that would get past most the tests if the long-term bias was gone? Everyone thinks of analyzing trillions of results for randomness but could a time-of-day bias hide in plain sight?

And thanks for the entropy. I'm running low and the holidays are coming up...

InternetsSrs
@199.116.116.x

InternetsSrs to rolfp

Anon

to rolfp
said by rolfp:

Bummer! Your entropy's bigger than mine. :(

Your system is pretty entropy starved, I've been really happy with VIAs Padlock implementation, it's quite a high bandwidth HWRNG -- I'm using it for OpenSSL/OpenVPN acceleration as well as an entropy broker for about six other systems.

Consider the below, from my laptop, which gets it's entropy from the entropy server I setup:

$ cat /proc/sys/kernel/random/entropy_avail; time dd if=/dev/random of=/dev/null bs=512k count=10 iflag=fullblock; cat /proc/sys/kernel/random/entropy_avail
3968
10+0 records in
10+0 records out
5242880 bytes (5.2 MB) copied, 33.7078 s, 156 kB/s
 
real    0m33.711s
user    0m0.000s
sys     0m2.868s
3360
 

5.2 MB of quantum random entropy from the HWRNG-fed entropy pool in 33 seconds. I can generate a 4096 RSA keypair in about ~2 seconds:

$ time openssl genrsa -out /tmp/key 4096
Generating RSA private key, 4096 bit long modulus
...............................................................++
.............................................++
e is 65537 (0x10001)
 
real    0m1.340s
user    0m1.296s
sys     0m0.008s
 

rolfp
no-shill zone
Premium Member
join:2011-03-27
Oakland, CA

rolfp

Premium Member

said by InternetsSrs :

Your system is pretty entropy starved

So, is the amount of system entropy a matter of hardware, software, configuration file content....?

InternetsSrs
@199.116.116.x

InternetsSrs

Anon

said by rolfp:

said by InternetsSrs :

Your system is pretty entropy starved

So, is the amount of system entropy a matter of hardware, software, configuration file content....?

This article explains it well - »blog.cloudflare.com/ensu ··· enerator

Without another source of entropy your system is filling the pool with keyboard, mouse, network, and disk activity (which likely explains why you are entropy starved)

rolfp
no-shill zone
Premium Member
join:2011-03-27
Oakland, CA

rolfp

Premium Member

Before:

$ cat /proc/sys/kernel/random/entropy_avail
184
 

after

$ ps aux|grep have
root     23409  0.1  0.0   9404  3516 ?        Ss   18:08   0:00 haveged -r 0
[..]
 
$ cat /proc/sys/kernel/random/entropy_avail
2408
 
$ cat /proc/sys/kernel/random/entropy_avail; dd if=/dev/random of=/dev/stdout bs=512 count=1 2>/dev/null|xxd
184
0000000: e54a 60fd 7ec8 cc63 f2d0 88fb 35ab 0fc2  .J`.~..c....5...
0000010: 0054 53c9 96b9 bf                        .TS....
 

After reading the blog, I have some concerns about system performance with low entropy. It seems haveged makes some difference, idk. Thanks.

rexbinary
MOD King
Premium Member
join:2005-01-26
Plano, TX
·Frontier FiberOp..

1 recommendation

rexbinary

Premium Member

Crypto: FreeBSD playing catch-up, says De Raadt
"FreeBSD has caught up to what OpenBSD has been doing for over 10 years," De Raadt told iTWire. "I see nothing new in their changes." "Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone."
»www.itwire.com/business- ··· de-raadt

InternetsSrs
@199.116.116.x

InternetsSrs

Anon

quote:
"Like I say, it was using the same method of passing entropy into the bottom of the smoothing subsystem. We don't consider it better than mouse movements. Linux is also using an un-biasable method like us."
I find this comforting as well.
InternetsSrs

InternetsSrs

Anon

I went ahead and added haveged to my entropy brokering system to avoid any bias. Reading into this more, it looks like FreeBSD is talking about mixing HWRNGs into Yarrow RPNG output and use a Linux-like/OpenBSD-like method for stirring and avoiding entropy bias NOT using HWRNGs as the initial seed for a Yarrow-only fed /dev/random like I initially thought.

Either way, great thread, lots of opportunities for self-education. Plus, now I've got "more bits = better" heh.

/usr/local/sbin/rngd -b -B 6 --hrng=viapadlock -t 1 -W 4096 --pidfile=/var/run/rngd_viapadlock.pid 2>&1
/usr/local/sbin/haveged --file - -F -n 0 2>/dev/null|/usr/local/sbin/rngd -f -r /dev/stdin -W 4096 -B 6 -t 1 -R stream --pidfile=/var/run/rngd_havege.pid > /dev/null 2>&1 &