why should I want to make a 256 bit key from hunter2? If you're going to generate a key using an algorithm, it is recommended that you use a 64bit initial key.
Apple seems to have done exactly that. They generated something something starting from a 4 digit number. That's why it only takes 40 minutes to access the information you need to decrypt everything.
No one claimed I mastered it. I study computer science, so they give me the basics for when, someday, I have to implement things like that. I also studied books, articles by people that know way more than me and real use cases. (encrypted communications between USA and Russia, Kerberos, Enigma, etc)
I also learned the only way to make a key 100% secure (unique non repeatable keys), how many times can you guarantee a key to be secure, when to use asymmetric/symmetric cryptography, etc.
No, I did not master anything. But snide comments on how "I have no idea about what I'm talking about" are unfounded and idiotic. Using a simple algorithm to generate (even if salted) keys leaves you open to brute force attacks. That's a fact, and it doesn't matter how much you think I know about cryptography.
First, there are a few almost 100% random generators. I prefer electromagnetic field variations, some use radioactive field decay, but there are more. Google them, I'm not here to teach you.
Second, I had a whole course dedicated almost exclusively to to encryption. I've implemented 3xDES, AES and RSA (C code, mind you, not easymode java). The first way to get your key broken is to make them predictable. It doesn't matter if you use a Password Based Key Derivation or not, if your universe of keys is known (in this case it's based on your phone's ID's, if what I read was true), enough processing power and you'll get there (it's what they seem to be doing).
Third and foremost, who the fuck are you to judge my knowledge based on those 3 lines? I know about salting, about making things slow enough to frustrate brute force attacks, etc. I wonder how you decided I did not, but please, fuck off.
Not as good as a genuine key, but way better than something that can be guessed to some approximation. Assuming, obviously, that "user input" is a strong key to begin with.
Or nevermind. The source where I read this news claimed that, but it seems it relies on a brute force attack, although they do have an algorithm to get a set of valid testing keys.
I'd say that every browser is free to use hardware acceleration to decode images, but I don't think you'd gain anything with it. GPU's are very good at math and stuff like that, but, for example, GIF decompression is the act of running arrays back and forth in order to build an image. I believe your GPU might do it faster (not sure), but if there was any gain it would be very very small.
Remember that some of these images were made to work in computers with 1000 slower (or even more). The processing power they take is residual.
Lossless compression: LZW, LZ77, LZ78 and variants. Most of these have expired by now and/or are free to use (PNG uses a variation of LZ77 and GIF uses LZW)
JPEG's lossy compression patent was invalidated in 2006, so everyone can use it.
Do you need more? Even if it's royalty free, it doesn't matter nowadays and it'll only contribute to make browsers heavy. Just leave it be.
Because you payed them a lot for all the free versions you got (that, I'm sure, are better than your stock rom).
Also, that is a very weak phone. It might "handle" gingerbread, but not well enough (that's what I'm told, i believe that's the same as the htc magic).
2.2 is miles away from the rom that came with that phone, you should thank them for what they done instead of complaining.
This is actually the best attempt at homogenization on the Android platform that I see out there.
This rom kind of works and feels the same on every device. Some minor tweeks here, some extra features due to better hardware there, but very similar overall. It also has the capability of resurrecting some very old phones with primitive hardware.
The reason for 32 developers, I bet, it's because most of them work for the phone(s) they own. If 7 or 8 of them had them all and worked full time on this there'd be no necessity for so many people.
It already existed (an android-arduino "interface"). It only matters because google is behind it now (with an official API), but whoever wanted to do stuff before already could.
If you connect your phone to a computer and start dumping logs, you'll notice that (at least for my Desire) it keeps loading and unloading stuff so it stays around 50-55% of total available resources.
Unless you have a really, really weak device, once you need more ram android will shut down those cached processes by itself in a seamless way.
But having all those processes cached will make the next time you open one of those apps take a lot less time (anything for 2 to 5 seconds less, depending on app). That's better user experience right there.
On a Xoom you don't need to kill those extra processes. Just let them be, it's better for you.
Slashdot Mirror
what I meant by an algorithm was:
X+1 = new key
Day of fabrication = new key
IMEI = new key
if you use that to generate your 256bit key you're failing.
And you misunderstood. Normal users chose nothing. It's apple that choses and no user should have access for to it.
PS: I was under the impression that an HEX 64 bit key was 10 numbers/letters. It's not a key a user should know, but if it was, is 10 that hard?
why should I want to make a 256 bit key from hunter2? If you're going to generate a key using an algorithm, it is recommended that you use a 64bit initial key.
Apple seems to have done exactly that. They generated something something starting from a 4 digit number. That's why it only takes 40 minutes to access the information you need to decrypt everything.
No one claimed I mastered it. I study computer science, so they give me the basics for when, someday, I have to implement things like that. I also studied books, articles by people that know way more than me and real use cases. (encrypted communications between USA and Russia, Kerberos, Enigma, etc)
I also learned the only way to make a key 100% secure (unique non repeatable keys), how many times can you guarantee a key to be secure, when to use asymmetric/symmetric cryptography, etc.
No, I did not master anything. But snide comments on how "I have no idea about what I'm talking about" are unfounded and idiotic. Using a simple algorithm to generate (even if salted) keys leaves you open to brute force attacks. That's a fact, and it doesn't matter how much you think I know about cryptography.
What?
First, there are a few almost 100% random generators. I prefer electromagnetic field variations, some use radioactive field decay, but there are more. Google them, I'm not here to teach you.
Second, I had a whole course dedicated almost exclusively to to encryption. I've implemented 3xDES, AES and RSA (C code, mind you, not easymode java). The first way to get your key broken is to make them predictable. It doesn't matter if you use a Password Based Key Derivation or not, if your universe of keys is known (in this case it's based on your phone's ID's, if what I read was true), enough processing power and you'll get there (it's what they seem to be doing).
Third and foremost, who the fuck are you to judge my knowledge based on those 3 lines? I know about salting, about making things slow enough to frustrate brute force attacks, etc. I wonder how you decided I did not, but please, fuck off.
Not as good as a genuine key, but way better than something that can be guessed to some approximation. Assuming, obviously, that "user input" is a strong key to begin with.
Or nevermind. The source where I read this news claimed that, but it seems it relies on a brute force attack, although they do have an algorithm to get a set of valid testing keys.
They figured the algorithm used to generate the keys...
Security one-o-one is DO NOT USE AN ALGORITHM TO GENERATE YOUR KEYS.
Big big fail, in my opinion.
*..made to run on computers 1000 times slower ..."
I'd say that every browser is free to use hardware acceleration to decode images, but I don't think you'd gain anything with it. GPU's are very good at math and stuff like that, but, for example, GIF decompression is the act of running arrays back and forth in order to build an image. I believe your GPU might do it faster (not sure), but if there was any gain it would be very very small.
Remember that some of these images were made to work in computers with 1000 slower (or even more). The processing power they take is residual.
PNG files can be 10 times bigger than JPG's, and I doubt you always need lossless compression, especially when JPG actually does a good job.
And?
Lossless compression: LZW, LZ77, LZ78 and variants. Most of these have expired by now and/or are free to use (PNG uses a variation of LZ77 and GIF uses LZW)
JPEG's lossy compression patent was invalidated in 2006, so everyone can use it.
Do you need more? Even if it's royalty free, it doesn't matter nowadays and it'll only contribute to make browsers heavy. Just leave it be.
We don't, especially now that most patents related to image compression are past us.
what's the point then? :)
How does the electricity to bitcoin ration pay off? Anyone knows?
Because you payed them a lot for all the free versions you got (that, I'm sure, are better than your stock rom).
Also, that is a very weak phone. It might "handle" gingerbread, but not well enough (that's what I'm told, i believe that's the same as the htc magic).
2.2 is miles away from the rom that came with that phone, you should thank them for what they done instead of complaining.
This is actually the best attempt at homogenization on the Android platform that I see out there.
This rom kind of works and feels the same on every device. Some minor tweeks here, some extra features due to better hardware there, but very similar overall. It also has the capability of resurrecting some very old phones with primitive hardware.
The reason for 32 developers, I bet, it's because most of them work for the phone(s) they own. If 7 or 8 of them had them all and worked full time on this there'd be no necessity for so many people.
But... Don't they already do this everywhere?
It's just that here there is a law saying that they can, but it is already done in almost every civilized country...
*PS: That doesn't mean many won't end up as code monkeys, but they are overqualified to do so
There is a misconception here.
Computer scientists aren't the code-monkeys. They are either the overseers of code monkeys or the guys doing research on various platforms.
Everyone can be a code monkey, but if you want your plane to land, you need experts.
So, Aida but worse? http://www.youtube.com/watch?v=huQLyjwskQo
200$? An arduino costs 20-30$ O_o.
It already existed (an android-arduino "interface"). It only matters because google is behind it now (with an official API), but whoever wanted to do stuff before already could.
So, by that train of thought Max OS X (arguably the "best" OS out there) is just a locked down unix, so you shouldn't bother.
The fact that it is locked down is actually an upside for the laymen. Not everyone wants/cares to tinker with everything,
You beat me to it :P
Damn you!
If you connect your phone to a computer and start dumping logs, you'll notice that (at least for my Desire) it keeps loading and unloading stuff so it stays around 50-55% of total available resources.
Unless you have a really, really weak device, once you need more ram android will shut down those cached processes by itself in a seamless way.
But having all those processes cached will make the next time you open one of those apps take a lot less time (anything for 2 to 5 seconds less, depending on app). That's better user experience right there.
On a Xoom you don't need to kill those extra processes. Just let them be, it's better for you.