When will you learn a Wi-Fi enable Tea Kettle is a horrible Idea. Oh I just got a message from my Wi-Fi enabled coffee machine that my coffee is done.
But an electric tea kettle is a great idea. Most of the USA hasn't caught on to the electric tea kettle yet. Something that astounds people from the rest of the world when visiting the US. If the iCandy is the gateway drug to get electric kettles into the USA, I'm all for it.
No. You can get taps that deliver not-boiling water. It's hot and steamy, but certainly not boiling, resulting in substandard tea. You also need a sink. An electric kettle can go anywhere there's a plug.
Oddly people in the US don't typically have an electric kettle. Yet once they've spent a week with one, they can't live without it. The bummer is the slow rate they boil relative to UK kettles. UK: 250V*13A = 3250W. US: 115V*15A = 1725W. So it takes roughly twice as long.
The worst knock-on effect of this is that people seem happy to get tea from restaurants in the form of not-boiling water in a cup, with a tea-bag on a string for the customer to dunk. If you've never tasted tea infused at the proper temperature, you don't know what you're missing.
I wish for the pre-storage kettle. Put a bunch of low ESR batteries in the base and charge them while not boiling. When someone boils water, combine energy from the mains and the batteries to deliver heat energy to the water.
For T-shirts yes. $15 for a small bit of fabric. But for most products if you want to import a full shipping container, have it filled at the source, shipped to the dock, shipped on a ship, have a paid shipping person help it through customs (where a lot of corruption and back handing happens in US ports) have it trucked to you business and unloaded, The shipping will cost thousands of dollars.
It doesn't matter anymore where you produce something now, because transport costs aren't important.
The is utter bullshit. The cost of shipping is decidedly important if you're trying to move goods from China to the US, unless the goods have an enormous cost per unit volume. In the case of the t-shirts, the shipping was probably most of the 1 cent.
The next time we do a big import for our distribution business, we'll try telling the shippers that we don't need to pay them and we'll see how far that gets us.
Yep. Get Curve25519 ECDH deployed. It's a good option for O(2**128) bit security bounds. And yes, the short term TLS solution is to move to bigger prime fields for DH.
Sorry if this is a dumb question, but I use openssl dhparam to generate a 4096-bit DH parameter file. Does that make a difference?
It would help mitigate that attack by increasing the workload to build the number field sieve. But it would increase the load at both ends. Switching to Curve25519 ECDH or Goldilocks or some other good elliptic curve would reduce the load at both ends and prevent the logjam attack.
The recommendation to web site hosts to address the beast attack was to go back to RC4 because the browsers supported it and the servers supported it. The right thing would be to go forward to a decent mode like CCM or GCM, but that would require the browsers to support them and they don't universally support those modes. E.G. https://blogs.gnome.org/mcatan... https://community.qualys.com/b...
Can you offer a reason to prefer it over a better algorithm with better properties that takes less compute power and has been subject to a rigorous standardization process? E.G. Shake128. I can't.
There are existing deployments by the millions. But wherever there is a choice for new deployments, going with the old thing is the behavior that has led us to where we are today with TLS.
The AES256 key schedule is not confidence inspiring. I won't be surprised if the attacks on it improve to the point where AES256 is actually worse that AES128, rather than theoretically.
AES256 is only theoretically worse because you can't brute force O(2^128) and you can't brute force O(2^112). So it's a wash.
The attacks on the key schedule are limited to certain uses. But it's a slippery slope.
Pretty silly comment since TLS is designed to give you control over what ciphers you allow in your implementation.
But it fails in practice because both ends have to agree on something and the required ciphers are determined by the worst best case algorithm out there on the interwebs. Software libraries react accordingly and support RC4, SHA-1, RSA1024 etc. and users have no clue how to select their ciphers.
The spec writers need to step up and define in the standard and protocols how old mechanisms don't just get deprecated, but how they actually go away.
Unfortunately, web sites haven't kept up. If you want to be able to communicate over TLS with the usual crop of web sites, dropping SHA-1 and RC4 is not an option.
And by them being obnoxious we remember who NOT to buy from. I, like the guy above, have never clicked an ad but i have refused to do business or buy products from many obnoxious advertised products. And yes Ive seen plenty of storys about poor click through also. so ya they cry about everything. whatever happened to that camera/webcam obnoxious ad years ago? Poof gone no longer in business.
I've clicked on ads many times. Not because I wanted to, but because the ad resized during the page load and I was trying to click on something else, but it jumped under my mouse. IBM, take note.. I only clicked on Ken Jennings twice this week on the Slashdot as because it resized after loading. Consequently I harbour negative attitudes towards Ken Jennings, Watson and IBM.
The problem is that newer is not necessarily better. I don't trust NIST much at the moment thanks to the NSA plants in it, nor do I trust anything with the words "elliptic curve" in it (especially any with "magic" constants). The old algorithms like RSA and DH are simple in concept, and have withstood the test of time algorithmically. Sure key lengths had to get longer due to Moore's law and some computational improvements, but no serious attacks are exist against them. It's unwise to ditch these methods any sooner than we have to.
I'm afraid in asymmetric signatures and Diffie Hellman, newer certainly is better.
The security of RSA is steadily being chipped away by improvements in index calculus. That is why RSA keys need to be so much longer than ECC keys.
The issue of magic constants is termed 'rigidity' by crypto nerds. I.E. Did the algorithm designer get to choose being multiple possible versions? Or did they have to follow a defined procedure to get to the values in the spec. Rigidity is one of the safecurves criteria and the only sane thing to do with elliptic curves is go with the safecurve compliant algorithms.
Five years ago I was arguing strongly (and successfully) against the adoption of ECC in certain standards because there were a number of uncertainties. Events have since shown that be correct. The death of binary fields, the NIST curve constants, the twist insecurity of P-224, etc. Now the tables have turned between RSA and ECC. We have a much better understanding of the security of ECC and how to build good ECC curves. We know NIST curves are untrustworthy. We know the sidechannel properties of hardware implementations of group multiplication over different prime group orders over ECC curves. RSA is getting weaker steadily, mostly through better cryptanalysis and sidechannel issues. If you're deployment RSA-2048 in a product that has to last 20 years, you're making a big gamble. If you deploy RSA-1024, you're not taking the problem seriously.
The LogJam attack that was doing the rounds yesterday highlighted the folly of doing Diffie Hellman in prime fields, rather than elliptic curves. The paper didn't adequately address the issue that fixing a prime in a spec is something you really want to do for a number of reasons but they got the recommendations right - move to ECC. Moore's law caught up with the practice (of fixing primes for prime fields over which to the DH) . Don't make the mistake of inventing complex prime negotiation protocols. Move to ECC.
So, in short, they're not breaking crypto, they are breaking shitty implementations of crypto.
No. They are estimating the cost of breaking standardized crypto and pointing out that it is within reach of state agencies. There are standards that don't suffer these problems and other problems and yet still use pre-defined static primes.
How is this news? Sounds like they are just describing the logjam attack which was published earlier this year
They are estimating the computation effort to build a number field seive to efficiently compute logs over the 1024 bit prime groups in common use for plain old Diffie Hellman. They recommend elliptic curves and not the NIST curves. From TFP:
"Transition to elliptic curves. Transitioning to elliptic curve Diffie-Hellman (ECDH) key exchange with appropriate parameters avoids all known feasible cryptanalytic attacks. Current elliptic curve discrete log algorithms for strong curves do not gain as much of an advantage from precomputation. In addition, ECDH keys are shorter than in “mod p” Diffie-Hellman, and shared-secret computations are faster. Unfortunately, the most widely supported ECDH parameters, those specified by NIST, are now viewed with suspicion due to NSA influence on their design, despite no known or suspected weaknesses. These curves are undergoing scrutiny, and new curves, such as Curve25519, are being standardized by the IRTF for use in Internet protocols. We recommend transitioning to elliptic curves where possible; this is the most effective long-term solution to the vulnerabilities described in this paper."
You are wrong. Precalculating the primes is not simple and it wouldn't help. The authors of the paper are pre-calculating the number field sieve for the prime group. This allows them to efficiently compute discrete logs over the group.
We've long past the point where we knew RSA, simple Diffie Hellman, Sha-1 and NIST curves need to go in the bin. This is one more nail in the coffin. The standards I'm working in have gone Ed25519, Curve25519 ECDH, Shake128, AES, etc. 128 bits, sane curves, modern hashes. Rearranging the TLS deck chairs won't help.
The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?
Take yourself out of the loop. Give it to the engineer. He/she wants to push it. Let him/her. Make the engineer responsible for pushing it, training people, documenting the procedures. Provide room to enable it to happen.
This is how the engineer grows and an engineer and how you grow as a manager, learning to trust the technical opinion of those doing to technical work.
And the ones that don't look ugly are either shoddy quality, or sold at stupidly high prices, way more than the price it'd take to make it with said materials, simply because said companies know they don't really have any competition.
Computers haven't been ugly for a long time. Beige mini-towers with oddly-designed front panels were pretty ugly. Modern stuff is black and silver. If one is smart one buys a 17" wide desktop case so that it stacks in the AV cabinet along with the stereo and blu-ray player.
Slashdot Mirror
When will you learn a Wi-Fi enable Tea Kettle is a horrible Idea.
Oh I just got a message from my Wi-Fi enabled coffee machine that my coffee is done.
But an electric tea kettle is a great idea. Most of the USA hasn't caught on to the electric tea kettle yet. Something that astounds people from the rest of the world when visiting the US. If the iCandy is the gateway drug to get electric kettles into the USA, I'm all for it.
Your coffee maker doesn't produce boiling water. Tea requires boiling water. Coffee doesn't.
Talk about solving First World problems - geesh.
I live in the first world. I have first world problems. I have no shame in solving them.
No. You can get taps that deliver not-boiling water. It's hot and steamy, but certainly not boiling, resulting in substandard tea. You also need a sink. An electric kettle can go anywhere there's a plug.
5 extra minutes in bed per day sounds good to me.
Oddly people in the US don't typically have an electric kettle. Yet once they've spent a week with one, they can't live without it. The bummer is the slow rate they boil relative to UK kettles. UK: 250V*13A = 3250W. US: 115V*15A = 1725W. So it takes roughly twice as long.
The worst knock-on effect of this is that people seem happy to get tea from restaurants in the form of not-boiling water in a cup, with a tea-bag on a string for the customer to dunk. If you've never tasted tea infused at the proper temperature, you don't know what you're missing.
I wish for the pre-storage kettle. Put a bunch of low ESR batteries in the base and charge them while not boiling. When someone boils water, combine energy from the mains and the batteries to deliver heat energy to the water.
For T-shirts yes. $15 for a small bit of fabric. But for most products if you want to import a full shipping container, have it filled at the source, shipped to the dock, shipped on a ship, have a paid shipping person help it through customs (where a lot of corruption and back handing happens in US ports) have it trucked to you business and unloaded, The shipping will cost thousands of dollars.
It doesn't matter anymore where you produce something now, because transport costs aren't important.
The is utter bullshit. The cost of shipping is decidedly important if you're trying to move goods from China to the US, unless the goods have an enormous cost per unit volume. In the case of the t-shirts, the shipping was probably most of the 1 cent.
The next time we do a big import for our distribution business, we'll try telling the shippers that we don't need to pay them and we'll see how far that gets us.
Yep. Get Curve25519 ECDH deployed. It's a good option for O(2**128) bit security bounds. And yes, the short term TLS solution is to move to bigger prime fields for DH.
Sorry if this is a dumb question, but I use openssl dhparam to generate a 4096-bit DH parameter file. Does that make a difference?
It would help mitigate that attack by increasing the workload to build the number field sieve. But it would increase the load at both ends. Switching to Curve25519 ECDH or Goldilocks or some other good elliptic curve would reduce the load at both ends and prevent the logjam attack.
The recommendation to web site hosts to address the beast attack was to go back to RC4 because the browsers supported it and the servers supported it. The right thing would be to go forward to a decent mode like CCM or GCM, but that would require the browsers to support them and they don't universally support those modes.
E.G.
https://blogs.gnome.org/mcatan...
https://community.qualys.com/b...
Can you offer a reason to prefer it over a better algorithm with better properties that takes less compute power and has been subject to a rigorous standardization process? E.G. Shake128. I can't.
There are existing deployments by the millions. But wherever there is a choice for new deployments, going with the old thing is the behavior that has led us to where we are today with TLS.
The AES256 key schedule is not confidence inspiring. I won't be surprised if the attacks on it improve to the point where AES256 is actually worse that AES128, rather than theoretically.
AES256 is only theoretically worse because you can't brute force O(2^128) and you can't brute force O(2^112). So it's a wash.
The attacks on the key schedule are limited to certain uses. But it's a slippery slope.
Pretty silly comment since TLS is designed to give you control over what ciphers you allow in your implementation.
But it fails in practice because both ends have to agree on something and the required ciphers are determined by the worst best case algorithm out there on the interwebs. Software libraries react accordingly and support RC4, SHA-1, RSA1024 etc. and users have no clue how to select their ciphers.
The spec writers need to step up and define in the standard and protocols how old mechanisms don't just get deprecated, but how they actually go away.
Unfortunately, web sites haven't kept up. If you want to be able to communicate over TLS with the usual crop of web sites, dropping SHA-1 and RC4 is not an option.
It's grim out there in TLS land.
And by them being obnoxious we remember who NOT to buy from. I, like the guy above, have never clicked an ad but i have refused to do business or buy products from many obnoxious advertised products. And yes Ive seen plenty of storys about poor click through also. so ya they cry about everything. whatever happened to that camera/webcam obnoxious ad years ago? Poof gone no longer in business.
I've clicked on ads many times. Not because I wanted to, but because the ad resized during the page load and I was trying to click on something else, but it jumped under my mouse. IBM, take note.. I only clicked on Ken Jennings twice this week on the Slashdot as because it resized after loading. Consequently I harbour negative attitudes towards Ken Jennings, Watson and IBM.
How are they misogynistic? I'm not disputing it, I just haven't seen a Carl's Jr ad in a long time.
The problem is that newer is not necessarily better. I don't trust NIST much at the moment thanks to the NSA plants in it, nor do I trust anything with the words "elliptic curve" in it (especially any with "magic" constants).
The old algorithms like RSA and DH are simple in concept, and have withstood the test of time algorithmically. Sure key lengths had to get longer due to Moore's law and some computational improvements, but no serious attacks are exist against them. It's unwise to ditch these methods any sooner than we have to.
I'm afraid in asymmetric signatures and Diffie Hellman, newer certainly is better.
The security of RSA is steadily being chipped away by improvements in index calculus. That is why RSA keys need to be so much longer than ECC keys.
The issue of magic constants is termed 'rigidity' by crypto nerds. I.E. Did the algorithm designer get to choose being multiple possible versions? Or did they have to follow a defined procedure to get to the values in the spec. Rigidity is one of the safecurves criteria and the only sane thing to do with elliptic curves is go with the safecurve compliant algorithms.
Five years ago I was arguing strongly (and successfully) against the adoption of ECC in certain standards because there were a number of uncertainties. Events have since shown that be correct. The death of binary fields, the NIST curve constants, the twist insecurity of P-224, etc. Now the tables have turned between RSA and ECC. We have a much better understanding of the security of ECC and how to build good ECC curves. We know NIST curves are untrustworthy. We know the sidechannel properties of hardware implementations of group multiplication over different prime group orders over ECC curves. RSA is getting weaker steadily, mostly through better cryptanalysis and sidechannel issues. If you're deployment RSA-2048 in a product that has to last 20 years, you're making a big gamble. If you deploy RSA-1024, you're not taking the problem seriously.
The LogJam attack that was doing the rounds yesterday highlighted the folly of doing Diffie Hellman in prime fields, rather than elliptic curves. The paper didn't adequately address the issue that fixing a prime in a spec is something you really want to do for a number of reasons but they got the recommendations right - move to ECC. Moore's law caught up with the practice (of fixing primes for prime fields over which to the DH) . Don't make the mistake of inventing complex prime negotiation protocols. Move to ECC.
So, in short, they're not breaking crypto, they are breaking shitty implementations of crypto.
No. They are estimating the cost of breaking standardized crypto and pointing out that it is within reach of state agencies.
There are standards that don't suffer these problems and other problems and yet still use pre-defined static primes.
How is this news? Sounds like they are just describing the logjam attack which was published earlier this year
They are estimating the computation effort to build a number field seive to efficiently compute logs over the 1024 bit prime groups in common use for plain old Diffie Hellman.
They recommend elliptic curves and not the NIST curves. From TFP:
"Transition to elliptic curves. Transitioning to elliptic
curve Diffie-Hellman (ECDH) key exchange with appropriate
parameters avoids all known feasible cryptanalytic
attacks. Current elliptic curve discrete log algorithms for
strong curves do not gain as much of an advantage from
precomputation. In addition, ECDH keys are shorter than
in “mod p” Diffie-Hellman, and shared-secret computations
are faster. Unfortunately, the most widely supported ECDH
parameters, those specified by NIST, are now viewed with
suspicion due to NSA influence on their design, despite no
known or suspected weaknesses. These curves are undergoing
scrutiny, and new curves, such as Curve25519, are
being standardized by the IRTF for use in Internet protocols.
We recommend transitioning to elliptic curves where
possible; this is the most effective long-term solution to the
vulnerabilities described in this paper."
You are wrong. Precalculating the primes is not simple and it wouldn't help.
The authors of the paper are pre-calculating the number field sieve for the prime group. This allows them to efficiently compute discrete logs over the group.
We've long past the point where we knew RSA, simple Diffie Hellman, Sha-1 and NIST curves need to go in the bin. This is one more nail in the coffin.
The standards I'm working in have gone Ed25519, Curve25519 ECDH, Shake128, AES, etc. 128 bits, sane curves, modern hashes. Rearranging the TLS deck chairs won't help.
The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?
Take yourself out of the loop. Give it to the engineer. He/she wants to push it. Let him/her. Make the engineer responsible for pushing it, training people, documenting the procedures. Provide room to enable it to happen.
This is how the engineer grows and an engineer and how you grow as a manager, learning to trust the technical opinion of those doing to technical work.
>This in turn is in part because of the transaction fees that the credit card companies charge.
This.
If we had overhead-free micropayments, there would be no issue. "This article costs $0.01. Buy? Y/N"
Let's face it, PCs are ugly as high-hell.
And the ones that don't look ugly are either shoddy quality, or sold at stupidly high prices, way more than the price it'd take to make it with said materials, simply because said companies know they don't really have any competition.
Computers haven't been ugly for a long time. Beige mini-towers with oddly-designed front panels were pretty ugly. Modern stuff is black and silver. If one is smart one buys a 17" wide desktop case so that it stacks in the AV cabinet along with the stereo and blu-ray player.
Mine is butt ugly. Lots of space for the NVIDIAs though.. http://www.newegg.com/Product/...