Vista should have been 64 bit and only 64 bit. There was no need to muddy the waters with 32 bit options. There would be no RAM addressing problem, no 2038 problem, no "do I need a 32 bit or 64 bit driver" problem.
Actually I was arguing from the standpoint that security in online systems comes through reduced complexity in trusted code. Thus affording effective review and analysis. If you structure your online application such that you have to trust the whole codebase, you're screwed. Make sure you only have to trust a tiny bit of code, then polish that turd well.
The two properties I warned against were 'large' and 'immature'. I mentioned neither 'open' nor 'closed'.
Thankyou for educating me. I'll file it with all the other security advice I get on Slashdot.
> perform tasks like bend over and pick up weighty objects
A robot should not bend over and pick up weighty objects. It should squat and pick it up while maintaining it s rear electrical conduit in a straight configuration to prevent getting a herniated servo in the back.
1) Intel builds most of the interfaces in a Thinkpad, since they make the chipsets.
2) Intel wrote much of the Linux driver code for their devices. Even for the stuff they didn't write, they have teams of people making sure the drivers work with their silicon.
3) All Intel employees are issued Thinkpads (except for the few with Macs). They have been for years. So anyone in Intel responsible for driver support for an Intel chip is going to experience it on a Thinkpad first and get it fixed if its broke.
802.1X (It's a capital X) is not an authentication protocol. It's an architecture (1X) and a protocol protocol (EAPoL) to carry a protocol (EAP) that carries authentication protocols (EAP methods).
What you said is akin to recommending a purchaser of a computer use the box it came in.
800-56 was around at the time. It was not so much withdrawn, as snuck away, destoyed and the remains buried in a shallow grave somewhere in Maryland. NIST won't admit to its existence these days.
I decided to go back and look at the spec so I could respond with the specific requirement. Rather than dig in my files I went to google to find the document. I put in "nist SP800-56" and up pops the message I posted two steps earlier in this thread.
That's some quick indexing.
Note to Google. When I put in "nist SP800-56" I want you to take me to the NIST spec.
When hashing a data set larger than the resulting digest, it cannot be reversed at all. However you can find collisions which is handy if you want to subvert the PKI hierarchy that protects web transactions.
Slashdot Mirror
The article said *non rechargeable* lithium batteries.
Your rechargeables don't count for this particular ban.
Don't tell them that it is the rechargable LiIon batteries installed in laptops that have been exploding.
Vista should have been 64 bit and only 64 bit. There was no need to muddy the waters with 32 bit options. There would be no RAM addressing problem, no 2038 problem, no "do I need a 32 bit or 64 bit driver" problem.
Actually I was arguing from the standpoint that security in online systems comes through reduced complexity in trusted code. Thus affording effective review and analysis. If you structure your online application such that you have to trust the whole codebase, you're screwed. Make sure you only have to trust a tiny bit of code, then polish that turd well.
The two properties I warned against were 'large' and 'immature'. I mentioned neither 'open' nor 'closed'.
Thankyou for educating me. I'll file it with all the other security advice I get on Slashdot.
Fresh Meat, full of bugs, for the hackers to hack.
If you desire a secure system, do not place a large, immature body of code in the line of fire on the internet.
It was supposed to be funny. It's funnier that people thought it was insightful.
> perform tasks like bend over and pick up weighty objects
A robot should not bend over and pick up weighty objects. It should squat and pick it up while maintaining it s rear electrical conduit in a straight configuration to prevent getting a herniated servo in the back.
Unlike the robot, the server seems to have been unable to cope with the kicking it got after getting a good hard slashdotting.
> Thinkpads, they are quite Linux-friendly.
1) Intel builds most of the interfaces in a Thinkpad, since they make the chipsets.
2) Intel wrote much of the Linux driver code for their devices. Even for the stuff they didn't write, they have teams of people making sure the drivers work with their silicon.
3) All Intel employees are issued Thinkpads (except for the few with Macs). They have been for years. So anyone in Intel responsible for driver support for an Intel chip is going to experience it on a Thinkpad first and get it fixed if its broke.
That's why Linux works well on Thinkpads.
802.1X (It's a capital X) is not an authentication protocol. It's an architecture (1X) and a protocol protocol (EAPoL) to carry a protocol (EAP) that carries authentication protocols (EAP methods).
What you said is akin to recommending a purchaser of a computer use the box it came in.
Certification to a security consultant usually means X.509, RFC3280bis and a sprinkling of ESP methods.
I figured dot1 would be enjoying your presence.
That's what I told the person from NIST.
I was more thinking of getting a beer than discussing crypto
Are you going to be in Atlanta next week?
Not *exactly* the same..
I'm still hunting for the document saying it's deprecated for hashing but it's fine as a PRNG. It's in there somewhere.
Yes, but the traffic at the library for the 50% of voters who left it to the last minute was hell.
He was phonetically correct. What do you expect in a country where phonics is pushed as a way of teaching a non phonetic written language?
You're reading 800-56A. Not 800-56.
800-56 was around at the time. It was not so much withdrawn, as snuck away, destoyed and the remains buried in a shallow grave somewhere in Maryland. NIST won't admit to its existence these days.
I decided to go back and look at the spec so I could respond with the specific requirement. Rather than dig in my files I went to google to find the document. I put in "nist SP800-56" and up pops the message I posted two steps earlier in this thread.
That's some quick indexing.
Note to Google. When I put in "nist SP800-56" I want you to take me to the NIST spec.
I'm not disagreeing. A hash algorithm can cover a sensible range of widths would be useful for situations not needing bigger hashes.
AES has this property in the key length. Its parent spec Reignwatchamacallit has it in block size also.
Someone with a lowly ARM should design their chip so the crypto can run at the needed rate. If RTL is needed, go design the RTL. It's not hard.
I was thinking of the 1600 byte cert it forms the digest in.
>Personally I think anything over 256 is overkill. But that's just me...
It's moot in certs. It's going to be padded out to 2048 bits anyway.
> It should probably be based on http://en.wikipedia.org/wiki/Elliptic_curve_cryptography . Unless they want something that only they can break. :O
That would be for signatures, not hashes.
When hashing a data set larger than the resulting digest, it cannot be reversed at all. However you can find collisions which is handy if you want to subvert the PKI hierarchy that protects web transactions.
I put a SHA-1 based KDF in 802.16 because NIST SP800-56 told me to.
Argh.