That's the simulation of climate rather than weather, which is a substantially different problem. It's a problem that's still hard and is still plagued by chaos-theory effects on numerical modeling. Not to worry, though: scientists have understood this problem and its implications for about 7 orders of magnitude longer than you've heard about it.
Problem discovered decades ago. Called "chaos theory". Turns out that for iterated feedback systems, even arbitrarily-large stored numbers cause round-off errors eventually. Usually more quickly than people anticipate.
People continue not to understand this admittedly subtle point, proceed to suggest known-bad solutions.
I highly doubt you need any more precision than that.
People doubting that you "need any more precision than that" is, roughly speaking, the origin of problems like this in the first place and, more generally, the origin of our understanding of chaos theory.
It turns out you, ultimately, need more precision than you can get. Always.
Everything up until the Lightning redesign has been the exact same connector. (Which, despite it being evil and proprietary, is better than USB and comes with the device. It just sucks if you need a second one.)
you know what would work out? if the tables are really all reserved all the fucking time, make a reservation cost. then increase cost until you hit a spot. the restaurant should just charge more, if people want to pay a months rent to eat there then so be it.
It's easier to auction off reservations rather than continually adjust the price until you find a level that works. And this was suggested by many people on Twitter early this morning already.
While that's technically true, from the perspective of both the server and the protocol in general, the password is not actually involved in the protocol at all. The server has no knowledge that you're actually using a password to secure the private key. (The point was that, cryptographically, SSH keys are not some implementation of password authentication where you don't need to send the password. They're an entirely different scheme that is also usable for authentication that has the useful property that you don't need to send the secrets.)
It's really only one-factor authentication, because only one factor is "visible" to the server. It's just that the one factor is secured independently, which makes it more reliable than a one-factor authentication secured by nothing (e.g., a password).
You could theoretically do that. SSH keys are specifically public-private keypairs, so they don't work like that. There are certainly alternate authentication systems that have similar properties that aren't key pairs, but they tend to be less usable in real systems -- hence the love of secret keys, hashed passwords, and key pairs as the major authentication mechanisms.
The way salt works, there is no reason to keep it secret. You don't need to secure it from disclosure at all.
What you're describing is simply a shared secret. (That is, the same piece of data is held by both parties.) This is fundamentally no better than having a password and storing the password itself (in which case the password is a shared secret) -- the only difference is that it's not provided by the user, so it can be high-entropy.
Generally having a shared secret for authentication isn't nearly as secure as having a secret that you know but the other party can verify without storing that secret. For instance, the other party storing a hash of your password.
Incidentally, if you want to establish a shared secret between two parties, the way to do this is the Diffie-Hellman key-agreement protocol. It results in both parties ending up with the same shared secret by transmitting messages that are publicly-readable without giving anyone reading the messages enough information to construct the secret.
Yes, it existed in the spec, but it wasn't an industry standard for personal electronics to charge over USB at that time. (Mercifully, that time is past.)
Yes, the fancy Android connections that are electrically compatible with USB are better.:-)
You can only do this if the Tor traffic rate is fairly low or through fairly sophisticated correlated-timing attacks. Each layer of indirection wraps the TCP stream in a layer of encryption, so you cannot, in fact, see the same message transit between nodes in a Tor network.
Yes, Apple should have used the connector redesign opportunity to make something that was completely compatible with micro-USB rather than the Lightning connector.
Prior to that redesign, it was the same design since the first-generation iPod.
It doesn't carry the current until the current has somewhere to flow. Namely, through you. Sure, the cable will melt in a matter of seconds, but that's a few seconds of electric shock, which is plenty.
It's possible by having the charger fail in such a way that it's not 5 volts any more -- or that the 5-volt pair is at a substantial voltage relative to earth ground.
Not that I particularly like the cable, but some reasons are: It predates USB being a standard for charging devices. It used to need to support FireWire in addition to USB. It still supports running audio and video over the wire in a "raw" form (rather than as some USB data device), which is actually a fairly useful feature.
Only the last of these is really useful any more. If that feature happens to be useful, the iPhone implementation is actually fairly good. Using Android phones as video sources tends to suck. A few phones have mini HDMI connections (note that the iPhone connector predates HDMI, too), but not many. A few have stupid proprietary HDMI + USB ports that at least are compatible with conventional USB-only cables. Some phones support screencasting or video sourcing through DLNA or proprietary solutions, but those require a network.
It wasn't popular because it was cheaper, it's popular because it's more effective. The state of the art in vaccine preservation and distribute has improved since them such that many vaccines don't need to use it any more. However, a few do (I think the injected flu does) because they are harder to keep stable. It's still more effective than the alternatives.
You cannot give your guests your WiFi password (or access to a password-secured WiFi network) without giving them the ability to leak it to anyone and everyone. That's the nature of a shared-secret system: everyone you've shared the secret with can share it freely with anyone else.
Set up separate SSIDs for internal and guest and periodically change the guest password. Separate networks is better anyway.
Both AES and 3DES were first published 15 years ago.
Neither of them can be cracked today. Certainly not by tools available to script kiddies.
The weakness in security systems is everywhere but the encryption (okay, and also in shoddy implementations of encryption) -- particularly, how the key is stored or derived (e.g., deriving the key from a low-entropy password).
So, yes, it is actually quite reasonable to bargain that encryption used today will be uncrackable 10 years from now.
You only mentioned "reversible encryption", which is redundant. I added the bit about hashes because people are constantly confusing hashes with encryption.
I specifically used the term "secret" because your password isn't necessarily your secret. In the case of WPA, for example, it's that generated hash that is the real secret. You could store that instead of the original password and it would be just fine. However, the secret is the piece of information that's used to access the network anyway. The fact that user interface components ask for your password is no barrier -- if the system stored the ssid+password hash, an attacker could recover that and join the network just as easily. In this sense, that hash is your "real" password. The only benefit of not storing that password is that an attacker couldn't benefit if you happen to use the same password in many places. (But then, if you use your wireless password for any other purpose, you've got bigger problems.)
Slashdot Mirror
That's true, because it's much harder. I know symbolic math covers calculus -- I've used plenty of such packages.
By non-algebraic I mean numerical-only. Unable to be computed using symbolic mathematics.
That's the simulation of climate rather than weather, which is a substantially different problem. It's a problem that's still hard and is still plagued by chaos-theory effects on numerical modeling. Not to worry, though: scientists have understood this problem and its implications for about 7 orders of magnitude longer than you've heard about it.
These are non-algebraic simulations. Even symbolic math libraries -- which there are no shortage of -- cannot do better.
Problem discovered decades ago. Called "chaos theory". Turns out that for iterated feedback systems, even arbitrarily-large stored numbers cause round-off errors eventually. Usually more quickly than people anticipate.
People continue not to understand this admittedly subtle point, proceed to suggest known-bad solutions.
I highly doubt you need any more precision than that.
People doubting that you "need any more precision than that" is, roughly speaking, the origin of problems like this in the first place and, more generally, the origin of our understanding of chaos theory.
It turns out you, ultimately, need more precision than you can get. Always.
Everything up until the Lightning redesign has been the exact same connector. (Which, despite it being evil and proprietary, is better than USB and comes with the device. It just sucks if you need a second one.)
you know what would work out? if the tables are really all reserved all the fucking time, make a reservation cost.
then increase cost until you hit a spot. the restaurant should just charge more, if people want to pay a months rent to eat there then so be it.
It's easier to auction off reservations rather than continually adjust the price until you find a level that works. And this was suggested by many people on Twitter early this morning already.
While that's technically true, from the perspective of both the server and the protocol in general, the password is not actually involved in the protocol at all. The server has no knowledge that you're actually using a password to secure the private key. (The point was that, cryptographically, SSH keys are not some implementation of password authentication where you don't need to send the password. They're an entirely different scheme that is also usable for authentication that has the useful property that you don't need to send the secrets.)
It's really only one-factor authentication, because only one factor is "visible" to the server. It's just that the one factor is secured independently, which makes it more reliable than a one-factor authentication secured by nothing (e.g., a password).
You could theoretically do that. SSH keys are specifically public-private keypairs, so they don't work like that. There are certainly alternate authentication systems that have similar properties that aren't key pairs, but they tend to be less usable in real systems -- hence the love of secret keys, hashed passwords, and key pairs as the major authentication mechanisms.
That's not a password, it's a public-private keypair. It's a completely different authentication mechanism.
The way salt works, there is no reason to keep it secret. You don't need to secure it from disclosure at all.
What you're describing is simply a shared secret. (That is, the same piece of data is held by both parties.) This is fundamentally no better than having a password and storing the password itself (in which case the password is a shared secret) -- the only difference is that it's not provided by the user, so it can be high-entropy.
Generally having a shared secret for authentication isn't nearly as secure as having a secret that you know but the other party can verify without storing that secret. For instance, the other party storing a hash of your password.
Incidentally, if you want to establish a shared secret between two parties, the way to do this is the Diffie-Hellman key-agreement protocol. It results in both parties ending up with the same shared secret by transmitting messages that are publicly-readable without giving anyone reading the messages enough information to construct the secret.
Yes, it existed in the spec, but it wasn't an industry standard for personal electronics to charge over USB at that time. (Mercifully, that time is past.)
Yes, the fancy Android connections that are electrically compatible with USB are better. :-)
You can only do this if the Tor traffic rate is fairly low or through fairly sophisticated correlated-timing attacks. Each layer of indirection wraps the TCP stream in a layer of encryption, so you cannot, in fact, see the same message transit between nodes in a Tor network.
One device using it doesn't make it a "standard", and the iPhone cable is from 2001 (it debuted with the first-generation iPod).
Yes, Apple should have used the connector redesign opportunity to make something that was completely compatible with micro-USB rather than the Lightning connector.
Prior to that redesign, it was the same design since the first-generation iPod.
It doesn't carry the current until the current has somewhere to flow. Namely, through you. Sure, the cable will melt in a matter of seconds, but that's a few seconds of electric shock, which is plenty.
It's possible by having the charger fail in such a way that it's not 5 volts any more -- or that the 5-volt pair is at a substantial voltage relative to earth ground.
Not that I particularly like the cable, but some reasons are: It predates USB being a standard for charging devices. It used to need to support FireWire in addition to USB. It still supports running audio and video over the wire in a "raw" form (rather than as some USB data device), which is actually a fairly useful feature.
Only the last of these is really useful any more. If that feature happens to be useful, the iPhone implementation is actually fairly good. Using Android phones as video sources tends to suck. A few phones have mini HDMI connections (note that the iPhone connector predates HDMI, too), but not many. A few have stupid proprietary HDMI + USB ports that at least are compatible with conventional USB-only cables. Some phones support screencasting or video sourcing through DLNA or proprietary solutions, but those require a network.
About the same way that we don't know the reporter or their source simply made up the statement.
We have a serious epidemic which no one is reporting or talking about.
What alternate-reality rock do you live under where nobody is reporting or talking about autism?
It wasn't popular because it was cheaper, it's popular because it's more effective. The state of the art in vaccine preservation and distribute has improved since them such that many vaccines don't need to use it any more. However, a few do (I think the injected flu does) because they are harder to keep stable. It's still more effective than the alternatives.
It's a childhood rite of passage for the people that live. It's something different for the small but significant fraction that don't.
Check out an old graveyard some time. Look for the small headstones that have cause-of-death listed.
You cannot give your guests your WiFi password (or access to a password-secured WiFi network) without giving them the ability to leak it to anyone and everyone. That's the nature of a shared-secret system: everyone you've shared the secret with can share it freely with anyone else.
Set up separate SSIDs for internal and guest and periodically change the guest password. Separate networks is better anyway.
Both AES and 3DES were first published 15 years ago.
Neither of them can be cracked today. Certainly not by tools available to script kiddies.
The weakness in security systems is everywhere but the encryption (okay, and also in shoddy implementations of encryption) -- particularly, how the key is stored or derived (e.g., deriving the key from a low-entropy password).
So, yes, it is actually quite reasonable to bargain that encryption used today will be uncrackable 10 years from now.
You only mentioned "reversible encryption", which is redundant. I added the bit about hashes because people are constantly confusing hashes with encryption.
I specifically used the term "secret" because your password isn't necessarily your secret. In the case of WPA, for example, it's that generated hash that is the real secret. You could store that instead of the original password and it would be just fine. However, the secret is the piece of information that's used to access the network anyway. The fact that user interface components ask for your password is no barrier -- if the system stored the ssid+password hash, an attacker could recover that and join the network just as easily. In this sense, that hash is your "real" password. The only benefit of not storing that password is that an attacker couldn't benefit if you happen to use the same password in many places. (But then, if you use your wireless password for any other purpose, you've got bigger problems.)