It if was a deterministic PRNG for the purpose of producing deterministic sequences, then it would be fine. But it is not that and it is not fine. It is the random service in the crypto library and you want this to provide numbers that meet the necessary properties of cryptographically secure random numbers.
If you fork a process and each process call my RNG, you'll get a different result, subject to the normal binomial collision distribution. This is how it should be.
When you respond to a call for comments from a federal agency, don't say it sucks. Say what's wrong and provide solutions. Solutions should come in the form of exact text changes that the editor can copy and paste into the document. People are lazy. Text talks.
In my comments, each comment comes with a resolution.. E.G.
The diagram shows inputs to functions including entropy, personalization string, nonce and Additional input. However the text calls out only the nonce input as being optional. By omission it leaves the optionality of the other inputs ambiguous. In a specification, where there is a list of items, some optional, some mandatory, it is necessary to identify the optional or mandatory nature of every item. Also, “depending on the implementation” is redundant and adds no meaning. Proposed resolution: Replace Figure 1 provides a functional model of a DRBG (i.e., one type of RBG). A DRBG uses a DRBG mechanism and a source of entropy input, and may, depending on the implementation of the DRBG mechanism, include a nonce source. The components of this model are discussed in the following subsections. With Figure 1 provides a functional model of a DRBG (i.e., one type of RBG). A DRBG shall implement an approved DRBG algorithm and at least one approved source of entropy input, and may include additional optional sources including a nonce source, personalization string, and additional input. The components of this model are discussed in the following subsections.
This "Theo de Raadt and developer Bob Beck, however, countered saying that the issue is "overblown" because Ayer's test program is unrealistic." Is why it is bad. Bugs are allowed. But in security, RNGs are special and you do them right or you fail. They failed. Then they tried to claim it wasn't a biggie.
>You should be outraged that the heartbleed bug remain exposed for years due to awful coding practices Who says I'm not. But that is a symptom of a bigger problem of using transport security to protect things in higher layers. This is wrong.
Some years ago I described "The Paranoid Entropy Trap". The tendency to get no entropy because you trusted none of your sources and turned them all off.
This is just such an example. If that computer he ran it on was less than a couple of years old, the hardware was almost certainly providing lots of entropy and the library was actively choosing to ignore it in the name of security.
I'm shocked that they acted like it was no biggie. They should have thanked Andrew Ayer profusely and acknowledged that a good RNG would not be vulnerable to state duplicate through fork().
In this case, the same seed was provided. Two copies of the same PRNG are supposed to provide exact same output, I don't see any issue here.
Two calls to two different PRNGs provided the same output. That is the problem.
Well designed PRNG algorithms have procedures to prevent this. Whatever you think of SP800-90A, the update procedure allowed for additional entropy in each update and would have prevented this.
That was the goal from the vey beginning: make the code less horrible to get people involved and correct as much as possible.
So, yes, they will find more problems. They expect that.
But in the RNG? FFS! Pay attention. It's always the RNG to fall first. Friends don't let friend write crypto libraries without doing a competent job on the RNG. In fact putting an RNG in a library in that way is just stupid and they all do it.
Putting the RNG in place that enables state duplication is stupid beyond belief. A single RNG service serving all comers is able to separate state between them. The sensible consumer will source multiple sources of entropy and mix them if they have a trust problem in the platform. A good OS will do this for you. A linked library will not.
I've spent the past 5 years of my life fully employed in the design, creation, testing, and deployment of secure RNGs.
The world is full of bad PRNGs, NRNGs, CSPRNGs, DRBGs, TRNGs and any other form of RNG.
LibreSSL doesn't have a leg to stand on. A good secure RNG will return unpredictable output. A good PRNG will return data indistinguishable from random. A good CSPRNG will do that with guarantees on the computational complexity of predicting the output.
We know how to do these things. It isn't trivial, but it isn't hard either. Allowing someone to extract predictable behavior from the service end of a security library is a gross failure and an exposition of incompetence.
If the user opens a record and waits 3 seconds then spends 30 seconds staring at the record or typing in it or talking to a customer, then the UI is messed up. The computer is pretty idle in the subsequent 30 seconds and can be loading the next form in the background.
The people who use my PoS like it not because of it's neato use of python and ncurses. They like it because it responds instantly, is very non modal and never required more than two or three keystrokes to complete a transaction. If you are paying 1000 people to use your badly designed UI, you need to fix the UI first.
No, you are wrong. This kind of analysis was debunked before I got to college 30 years ago.
Just because something on the computer takes more or less time doesn't mean the user isn't adapting and overlapping other behaviors during those 3 seconds. Do a controlled experiment and come back when you have real data.
If your analysis is so great why aren't you advocating moving to technologies that take less time to bring up a record? Or pre-loading the next record, or anything to save your oh-so precious 300 seconds per worker. I'm glad I don't work in your sweatshop.
I used a travel agent last week to work out a complex trip across three countries in Asia. But in order to exist, they do need to add value. Car dealerships do not.
A sane local politician changing the laws to allow direct sales would be freeing him or herself from the shackled of this powerful lobby and would not be losing any revenue.
Most states, prodded perhaps by dealer associations, have forbidden auto manufacturers from selling directly to the public.
There is no "perhaps" about it. Auto dealer associations are entirely the reason - no need to qualify your statement. They are parasitic middlemen and they know they have a good deal going. They cost both customers and the automakers money. They should have to compete and provide value just like any other business. There should be no legal prohibition against me buying a car directly from Tesla, GM, Toyota or any other car maker if I want. If the dealer can provide me extra value then fine but if they cannot (and most cannot) then they should disappear like the obsolete businesses they are. There is no rational justification I have heard for protecting their business model at my expense. Perhaps you know of a good reason but frankly for me if auto dealers disappear tomorrow it won't be too soon.
Yup. It rather like being required to head to your nearest brick-and-mortar travel agency to book a flight and hotel and pay them their middleman fee, rather than going to united.com and tripadvisor,com (or whatever your preferred vendor is).
Outside of a browser, with a separate-from-the-browser password keeper like KeePass I see three primary malware attack vectors
1) Keyboard Logging 2) Snarfing the clipboard as you copy and paste the password 3) Privilege escalation and attacking the keeper directly
But #1 and #2 are pretty universal, whereas #3 is software version specific.
I would much prefer a hardware solution, where the plaintext password never existed on the primary computer, but instead existed in separate hardware (like a USB device or smart card) and a secure password authentication exchange, key agreement and key binding takes place between the device and the web site (or whatever).
The hardware would be easy. The hard bit would be getting the IETF to write such a scheme into the http protocol and get the browser makers to adopt it. The IETF have lots of key exchange schemes to play with, but none that seem to make sense at the http level.
>You're telling us not to trust a web based service, but then tell us you keep your data shared like google drive or dropbox? I see no appreciable difference in practice there. Lastpass is essentially Keepass + a specialized dropbox-type service. Your advice is especially ironic given the spotty security dropbox is known for [zdnet.com].
The problem is not in the remote storage. It's in the local client that does the work to turn your clicks and typing into a secured file that doesn't need to trust the storage medium to do anything except store.
The 'web integration' puts your password manager in a really bad place - in the browser. What could possibly go wrong? Surely no one attacks web browsers.
My wife tried the elephant one on her mac (I forgot the name, but there's an elephant in the logo). It was awful. This was a while ago. There may be better now.
I couldn't find a good Android one. I don't know if that has changed either, since I switched to KeePass.
Slashdot Mirror
I know what the attack does.
It if was a deterministic PRNG for the purpose of producing deterministic sequences, then it would be fine. But it is not that and it is not fine. It is the random service in the crypto library and you want this to provide numbers that meet the necessary properties of cryptographically secure random numbers.
If you fork a process and each process call my RNG, you'll get a different result, subject to the normal binomial collision distribution. This is how it should be.
When you respond to a call for comments from a federal agency, don't say it sucks. Say what's wrong and provide solutions.
Solutions should come in the form of exact text changes that the editor can copy and paste into the document. People are lazy. Text talks.
See this: http://csrc.nist.gov/publicati...
In my comments, each comment comes with a resolution..
E.G.
The diagram shows inputs to functions including entropy, personalization string, nonce and Additional input. However the text calls out only the
nonce input as being optional. By omission it leaves the optionality of the other inputs ambiguous. In a specification, where there is a list of items,
some optional, some mandatory, it is necessary to identify the optional or mandatory nature of every item.
Also, “depending on the implementation” is redundant and adds no meaning.
Proposed resolution:
Replace
Figure 1 provides a functional model of a DRBG (i.e., one type of RBG). A DRBG uses a DRBG mechanism and a source of entropy
input, and may, depending on the implementation of the DRBG mechanism, include a nonce source. The components of this model are
discussed in the following subsections.
With
Figure 1 provides a functional model of a DRBG (i.e., one type of RBG). A DRBG shall implement an approved DRBG algorithm and at
least one approved source of entropy input, and may include additional optional sources including a nonce source, personalization string,
and additional input. The components of this model are discussed in the following subsections.
This "Theo de Raadt and developer Bob Beck, however, countered saying that the issue is "overblown" because Ayer's test program is unrealistic."
Is why it is bad. Bugs are allowed. But in security, RNGs are special and you do them right or you fail. They failed. Then they tried to claim it wasn't a biggie.
>You should be outraged that the heartbleed bug remain exposed for years due to awful coding practices
Who says I'm not. But that is a symptom of a bigger problem of using transport security to protect things in higher layers. This is wrong.
I'm completely serious.
Some years ago I described "The Paranoid Entropy Trap". The tendency to get no entropy because you trusted none of your sources and turned them all off.
This is just such an example. If that computer he ran it on was less than a couple of years old, the hardware was almost certainly providing lots of entropy and the library was actively choosing to ignore it in the name of security.
I'm shocked that they acted like it was no biggie.
They should have thanked Andrew Ayer profusely and acknowledged that a good RNG would not be vulnerable to state duplicate through fork().
In this case, the same seed was provided. Two copies of the same PRNG are supposed to provide exact same output, I don't see any issue here.
Two calls to two different PRNGs provided the same output. That is the problem.
Well designed PRNG algorithms have procedures to prevent this. Whatever you think of SP800-90A, the update procedure allowed for additional entropy in each update and would have prevented this.
in 3....2.......1............
That was the goal from the vey beginning: make the code less horrible to get people involved and correct as much as possible.
So, yes, they will find more problems. They expect that.
But in the RNG? FFS! Pay attention. It's always the RNG to fall first. Friends don't let friend write crypto libraries without doing a competent job on the RNG. In fact putting an RNG in a library in that way is just stupid and they all do it.
Putting the RNG in place that enables state duplication is stupid beyond belief. A single RNG service serving all comers is able to separate state between them. The sensible consumer will source multiple sources of entropy and mix them if they have a trust problem in the platform. A good OS will do this for you. A linked library will not.
I've spent the past 5 years of my life fully employed in the design, creation, testing, and deployment of secure RNGs.
The world is full of bad PRNGs, NRNGs, CSPRNGs, DRBGs, TRNGs and any other form of RNG.
LibreSSL doesn't have a leg to stand on. A good secure RNG will return unpredictable output. A good PRNG will return data indistinguishable from random. A good CSPRNG will do that with guarantees on the computational complexity of predicting the output.
We know how to do these things. It isn't trivial, but it isn't hard either. Allowing someone to extract predictable behavior from the service end of a security library is a gross failure and an exposition of incompetence.
If the user opens a record and waits 3 seconds then spends 30 seconds staring at the record or typing in it or talking to a customer, then the UI is messed up.
The computer is pretty idle in the subsequent 30 seconds and can be loading the next form in the background.
The people who use my PoS like it not because of it's neato use of python and ncurses. They like it because it responds instantly, is very non modal and never required more than two or three keystrokes to complete a transaction. If you are paying 1000 people to use your badly designed UI, you need to fix the UI first.
Luckily we don't care, because we're right.
No, you are wrong. This kind of analysis was debunked before I got to college 30 years ago.
Just because something on the computer takes more or less time doesn't mean the user isn't adapting and overlapping other behaviors during those 3 seconds. Do a controlled experiment and come back when you have real data.
If your analysis is so great why aren't you advocating moving to technologies that take less time to bring up a record? Or pre-loading the next record, or anything to save your oh-so precious 300 seconds per worker. I'm glad I don't work in your sweatshop.
Umm, yes. That was my point.
I used a travel agent last week to work out a complex trip across three countries in Asia.
But in order to exist, they do need to add value. Car dealerships do not.
Clearly Verilog users suck at basic rounding.
Verilog users do however know that the binary inverse of a non-explicit width integer N is 32'dN xor 32'b1. I.E. 0xFFFFFFD3 or in decimal -45.
"...reinserts it back into your searches"...at the top of the page. ...should read:
"...reinserts it into your searches..."
Sorry, you don't need to be redundant to be specific.
Sorry, you don't need to be apologetic to be redundant.
Sales tax would still come from direct sales.
A sane local politician changing the laws to allow direct sales would be freeing him or herself from the shackled of this powerful lobby and would not be losing any revenue.
Most states, prodded perhaps by dealer associations, have forbidden auto manufacturers from selling directly to the public.
There is no "perhaps" about it. Auto dealer associations are entirely the reason - no need to qualify your statement. They are parasitic middlemen and they know they have a good deal going. They cost both customers and the automakers money. They should have to compete and provide value just like any other business. There should be no legal prohibition against me buying a car directly from Tesla, GM, Toyota or any other car maker if I want. If the dealer can provide me extra value then fine but if they cannot (and most cannot) then they should disappear like the obsolete businesses they are. There is no rational justification I have heard for protecting their business model at my expense. Perhaps you know of a good reason but frankly for me if auto dealers disappear tomorrow it won't be too soon.
Yup. It rather like being required to head to your nearest brick-and-mortar travel agency to book a flight and hotel and pay them their middleman fee, rather than going to united.com and tripadvisor,com (or whatever your preferred vendor is).
> so in a couple years we don't have to order our Tesla-E via Amazon Prime?
Why not? The shipping is free (or at least unmetered)
>Fact is people in the South of England have already started growing grapes in order to produce wine.
Well they were doing that when I was a kid in the UK 40 years ago.
Outside of a browser, with a separate-from-the-browser password keeper like KeePass I see three primary malware attack vectors
1) Keyboard Logging
2) Snarfing the clipboard as you copy and paste the password
3) Privilege escalation and attacking the keeper directly
But #1 and #2 are pretty universal, whereas #3 is software version specific.
I would much prefer a hardware solution, where the plaintext password never existed on the primary computer, but instead existed in separate hardware (like a USB device or smart card) and a secure password authentication exchange, key agreement and key binding takes place between the device and the web site (or whatever).
The hardware would be easy. The hard bit would be getting the IETF to write such a scheme into the http protocol and get the browser makers to adopt it. The IETF have lots of key exchange schemes to play with, but none that seem to make sense at the http level.
"...reinserts it back into your searches"...at the top of the page.
Sorry but you have to be pedantic when gathering requirements.
Sorry, but you have to be pernickety when you're aiming for specificity.
Heathrow airport had a 4 hour transit time long before Pluto.
>You're telling us not to trust a web based service, but then tell us you keep your data shared like google drive or dropbox? I see no appreciable difference in practice there. Lastpass is essentially Keepass + a specialized dropbox-type service. Your advice is especially ironic given the spotty security dropbox is known for [zdnet.com].
The problem is not in the remote storage. It's in the local client that does the work to turn your clicks and typing into a secured file that doesn't need to trust the storage medium to do anything except store.
The 'web integration' puts your password manager in a really bad place - in the browser. What could possibly go wrong? Surely no one attacks web browsers.
You mean ~44 Kelvin.
Any Verilog user would disagree.
My wife tried the elephant one on her mac (I forgot the name, but there's an elephant in the logo). It was awful.
This was a while ago. There may be better now.
I couldn't find a good Android one. I don't know if that has changed either, since I switched to KeePass.
Scientists will never send probes to Uranus.
But the TSA will.
It takes 4 hours for any signal to reach Pluto regardless of bitrate. Light only has 1 speed.
Maybe in your universe. In my universe, the speed of light varies with the medium.