Maybe, but surely you could implement a sort of low resolution cipher chaining so that you used the chaining on only a small number of blocks. Enough to cover up any entropy analysis of what you were encrypting. Doing this on a small number of blocks would reduce the computation an add to security... I think*
* This isn't my area any more, I've been out of the electronic crypto game for several years.
Completely agree, I thought the same although I have seen ECB used a lot simply out of ignorance and/or laziness.
Something like counter ( CTR ) mode is very very very easy to implement and increases the security immeasurably.
Like in most crypto solutions, there is no point having a strong cipher like AES when the protocol you use it within is a pile of plops, such as here.
I agree, the original book 'I am Legend' is vastly superior to any of the film adaptions and none follow the story properly, well perhaps apart from the Vincent Price version.
Controversial one here but, and it hurts me to say this, Will Smith is a much better actor than Heston was. I watched The Omega Man again about three months ago and was shocked at the acting which is quite crude and unbelievable.
All too often when people talk about their security solution they talk only about the cipher they are using, the length of keys and the time required to crack it.
Nowadays this is moot.
Security is in the protocol, how you exchange keys amongst parties and more importantly how you store the keys locally on the client and server.
I don't give a shit how strong your cipher is if your keys are negotiated in an in-appropriate fashion or stored in the clear on your machine. I'll do a dump of your memory and analyse the result for random looking data runs, chances are it's crypto related. Knowing the key and block lengths of your cipher getting past your security will not present a tremendous difficulty.
Unfortunately with security, you are not making something that will either work or it will not, you are adding protection to something that works. Hence it's pretty easy to hack together something that works but fail stands up to even basic analysis.
Real security lies in trusted platforms ( here we go...! ) and data hiding techniques using obfuscation. Unfortunately this sort of thing, data obfuscation in particular is difficult to explain to Joe public and can't be used to advertise you product.
Oh well, and Bruce, if you're reading this, how about a 2nd ed. of Practical Cryptography.
Honestly, have we learnt nothing from Jerry Bruckheimer's excellent film Armageddon.
Refuelling in orbit is dangerous!
Next they'll be suggesting we man these orbital filling stations with drunken Russians. I only hope Ben and Bruce are there to sort things out when matters go awry.
Look at this as the addition of another comms layer. In GSM your voice is sampled, and encoded ( for GSM this is GSM 06.10 RPE-LTP at 13kB/s ) into raw data which is sent over the channel. If this data is encrypted is irrelevant.
Reading the comments made me cringe, so here goes....
Some points;
- 128 bit keys are probably good enough, depending on the nature of the conversation. Diffiehellman generates a per-session master secret. To this you would then apply a KDF ( Key Derivation Function ) in order to produce your session key for use with your symmetric cipher, most likely AES or 3DES, maybe even TwoFish. A new master secret is generated every time you make a call, hence the session key changes per call, this is UNLIKE your WEP key, which is constant or one value selected from a set. The consequence of this is that although it is practical to break an 128 bit symmetric key, it is NOT practical to do so in the time interval in which the call is taking place. Hence the encryption applied is strong enough for protecting calls in the short term, although if someone captured the call they could possibly decrypt it at a later date.
- GSM does feature limited cryptography. Unfortunately, and rather amusingly this encrypting is only carried out on radio traffic. Once the data reaches the base station / cell, it is sent in the clear around the cable cellular netork's backbone infrastructure.
While the other two are busy trying to out do each other with hardware oneupmanship Nintendo is bringing us a console that is shock horror, fun to play and has games people want to play.
I don't own a console. I'm an electronics engineer, I spend all day on my ass in front of a computer thinking. When I come home I want to switch off, play a quick 30 mins of computer games that are fun. I DON'T want to play a game that takes hours to get into and that I must devote my life to.
I want a game like chess.... anyone can learn to play in a short while, but it takes ages to master.
When i was younger I grew up programming my Sinclair ZX81 and playing with Lego Technic. This sort of stuff set me on the path to a degree in EEE at university and now a job as an Electronics Engineer.
What do kids have today, the XBox 360 and Playstation, where are the engineers of the future going to come from? But wait there's hope, thank you Lego, thank you for still having the guts to create a great educational 'toy'* that will not only entertain the masses but also teach them as well.
* a 'toy' I might add, that I will be buying for me... a 25 year old big kid.
The 770 was developed by the same team who put out the 7710 so it probably inherited some of the design problems in that first device.
Personally I think the whole form factor of the 77x(x) series is just wrong. I worked as electronics engineer for the big N in Southwood England a couple of years ago and I remember getting to play with the un-released 7700. All I can say is thank goodness they didn't release it, the software wasn't that bad but the design of the thing was like a kids toy. I actually originally though it was a proto and was somewhat shocked when I was told it was a soon to be released product.
It is the wrong size, yes you get screen real estate but it is too bulky to pocket and not big enough to act as a laptop replacement ( bit like UMPCs in that respect ). This is not even beginning to mention it's shortcomings with regards to user input.
It is interesting that Nokia is pursing this route when the rest of the industry seems to be moving from stylus based entry to small thumb boards ( Treo 650, HW6915 etc. )
Presently people trumpet crypto algorithms, AES is better than Twofish, 3DES is crap etc etc etc. All of this is moot though when the greatest vulnerablility in the system is the attacker scanning memory for keys and ciphertext. This isn't all that difficult when you consider that most keys will resemble random byte arrays, and good ciphertext should effectively be pseudo random. .
What this technology does is make sure that what you find in memory is not the key, or the data, but rather an un-transformed version of it which must have a hardware alogorithm applied to it in addition to the base cipher. NB: Many of these techniques are already applied through software cipher and data obfuscation.
If the user can change the keys, what's the point? Yes they should be able to change some keys, there own for example, but not the trusted signing authority. It's back to the big PKI nutshell. How the hell do you share and authenticate keys! At the end of the day there has to be a trusted source, TPMs seem the best way of doing this to me.
And to the person who said 'this will be hell to debug'.... That's the point!
Tilden's work is impressive but extremely limited in scope. It has found much use in Toy manufacture but it is not useful in controlling complex systems.
The 'nervous nets' are the best example of this. He paints the picture that they are intelligent adaptive networks while in truth they are nothing more that a chain of self-stabilising bi-stables.
What annoys me the most about him though is the way that he overly trumpets his own work as being much more important than it actually is. In the past he has compared his Robosapien, which walks with a static shuffling gait, to Sony's QRIO and Honda's Asimo which walk dynamically using limbs with multiple DOFs similar to other bipeds in nature like human beings.
From my own experience the following usually happens.
The development cycle usually consists of sitting in meetings while the architects and project managers hmmm and hah over what features to scope and de-scope for this particular release. This usually achieves nothing, at the very last minute they'll tell us to design something which has a set of features that don't interact well and require others that have been de-scoped. We now have exactly one week to code and module test the thing.
After many late nights the code is finished and the next few weeks are frought with Integration nightmares that the managers failed to take account of in their initial high level design. This isn't usually as bad as it should be as those of us doing the actual coding can often identify issues at the implementation stage and fix them there. When we tell the managers about this it usually offends them.
Integration complete, there is now about 5% of the work left to do in tidying up loose ends and streamlining code. The powers that be deem this to be un-necessary and my name appears on the Gantt chart of another project. Because I didn't get a chance to complete this final 5% of the work I will probably face a Bugzilla email deluge in the next month.
The answer, short development cycles, Extreme programming, unified process etc.>
Design, code, test and integrate in 3 -4 week cycles. Design decisions can't be drawn out and must be made quickly, coding and testing is done in manageable amounts and integration no longer presents a nightmare. Code is good the first time around for the small number of features implemented in that cycle, and far less buggy.
Unfortunately people are too stuck in their ways to change.
With Microsoft and other third-parties offering push email Blackberry need to diversify.
They need to get back to what the internet is all about, what increased 3G bandwidth is all about, hell, what am I talking about? High definition porn direct to your hand... ( just where you need it )
And the name of this new product, the RIM BlueBerry .
Tweaking your autoexec.bat and config.sys so that you had enough of the first base 640k of RAM to actually get any games to run on your power beast 486. That's were the fun really was!
Himem.sys and emm386.exe, I had nearly forgotten all about you guys, ahhhh those were the days.
For those who want more of this jovial tweakfest go here
But... have you looked at what's in your laptop or cell-phone battery? The answer is a rather unpleasant mix of corrosive substances and reactive metals.
Good design abstracts the user from the dangers of using such materials while allowing them to garner the benefits of doing so. It's an immature technology, give it a chance.
Slashdot Mirror
Ah ha, sorry, must learn to read!
Maybe, but surely you could implement a sort of low resolution cipher chaining so that you used the chaining on only a small number of blocks. Enough to cover up any entropy analysis of what you were encrypting. Doing this on a small number of blocks would reduce the computation an add to security... I think* * This isn't my area any more, I've been out of the electronic crypto game for several years.
Completely agree, I thought the same although I have seen ECB used a lot simply out of ignorance and/or laziness. Something like counter ( CTR ) mode is very very very easy to implement and increases the security immeasurably. Like in most crypto solutions, there is no point having a strong cipher like AES when the protocol you use it within is a pile of plops, such as here.
I agree, the original book 'I am Legend' is vastly superior to any of the film adaptions and none follow the story properly, well perhaps apart from the Vincent Price version. Controversial one here but, and it hurts me to say this, Will Smith is a much better actor than Heston was. I watched The Omega Man again about three months ago and was shocked at the acting which is quite crude and unbelievable.
it's what happens when I fart.
Who says wind power doesn't harm the environment.
All too often when people talk about their security solution they talk only about the cipher they are using, the length of keys and the time required to crack it.
Nowadays this is moot.
Security is in the protocol, how you exchange keys amongst parties and more importantly how you store the keys locally on the client and server.
I don't give a shit how strong your cipher is if your keys are negotiated in an in-appropriate fashion or stored in the clear on your machine. I'll do a dump of your memory and analyse the result for random looking data runs, chances are it's crypto related. Knowing the key and block lengths of your cipher getting past your security will not present a tremendous difficulty.
Unfortunately with security, you are not making something that will either work or it will not, you are adding protection to something that works. Hence it's pretty easy to hack together something that works but fail stands up to even basic analysis.
Real security lies in trusted platforms ( here we go...! ) and data hiding techniques using obfuscation. Unfortunately this sort of thing, data obfuscation in particular is difficult to explain to Joe public and can't be used to advertise you product.
Oh well, and Bruce, if you're reading this, how about a 2nd ed. of Practical Cryptography.
Honestly, have we learnt nothing from Jerry Bruckheimer's excellent film Armageddon.
Refuelling in orbit is dangerous!
Next they'll be suggesting we man these orbital filling stations with drunken Russians. I only hope Ben and Bruce are there to sort things out when matters go awry.
You are quite correct, but I say practical to break a '128 bit symmetric key' which does not necessarily imply AES.
;)
Or maybe I just made a slip of the tongue and and am now trying to not look embarassed.
Not really,
Look at this as the addition of another comms layer. In GSM your voice is sampled, and encoded ( for GSM this is GSM 06.10 RPE-LTP at 13kB/s ) into raw data which is sent over the channel. If this data is encrypted is irrelevant.
Read one of Bruce's books, then come back when you can make a reasoned and sensible comment.
Reading the comments made me cringe, so here goes....
Some points;
- 128 bit keys are probably good enough, depending on the nature of the conversation. Diffiehellman generates a per-session master secret. To this you would then apply a KDF ( Key Derivation Function ) in order to produce your session key for use with your symmetric cipher, most likely AES or 3DES, maybe even TwoFish. A new master secret is generated every time you make a call, hence the session key changes per call, this is UNLIKE your WEP key, which is constant or one value selected from a set. The consequence of this is that although it is practical to break an 128 bit symmetric key, it is NOT practical to do so in the time interval in which the call is taking place. Hence the encryption applied is strong enough for protecting calls in the short term, although if someone captured the call they could possibly decrypt it at a later date.
- GSM does feature limited cryptography. Unfortunately, and rather amusingly this encrypting is only carried out on radio traffic. Once the data reaches the base station / cell, it is sent in the clear around the cable cellular netork's backbone infrastructure.
You listen, you notice, you innovate!
While the other two are busy trying to out do each other with hardware oneupmanship Nintendo is bringing us a console that is shock horror, fun to play and has games people want to play.
I don't own a console. I'm an electronics engineer, I spend all day on my ass in front of a computer thinking. When I come home I want to switch off, play a quick 30 mins of computer games that are fun. I DON'T want to play a game that takes hours to get into and that I must devote my life to.
I want a game like chess.... anyone can learn to play in a short while, but it takes ages to master.
Altogether now, Wiiiiiiiiiiiiiiiiiii!
When i was younger I grew up programming my Sinclair ZX81 and playing with Lego Technic. This sort of stuff set me on the path to a degree in EEE at university and now a job as an Electronics Engineer.
What do kids have today, the XBox 360 and Playstation, where are the engineers of the future going to come from? But wait there's hope, thank you Lego, thank you for still having the guts to create a great educational 'toy'* that will not only entertain the masses but also teach them as well.
* a 'toy' I might add, that I will be buying for me... a 25 year old big kid.
The 770 was developed by the same team who put out the 7710 so it probably inherited some of the design problems in that first device.
Personally I think the whole form factor of the 77x(x) series is just wrong. I worked as electronics engineer for the big N in Southwood England a couple of years ago and I remember getting to play with the un-released 7700. All I can say is thank goodness they didn't release it, the software wasn't that bad but the design of the thing was like a kids toy. I actually originally though it was a proto and was somewhat shocked when I was told it was a soon to be released product.
It is the wrong size, yes you get screen real estate but it is too bulky to pocket and not big enough to act as a laptop replacement ( bit like UMPCs in that respect ). This is not even beginning to mention it's shortcomings with regards to user input.
It is interesting that Nokia is pursing this route when the rest of the industry seems to be moving from stylus based entry to small thumb boards ( Treo 650, HW6915 etc. )
Is Steve Balmer really a monkey?
A tool, only in the derogatory sense of the word
Both,
Presently people trumpet crypto algorithms, AES is better than Twofish, 3DES is crap etc etc etc. All of this is moot though when the greatest vulnerablility in the system is the attacker scanning memory for keys and ciphertext. This isn't all that difficult when you consider that most keys will resemble random byte arrays, and good ciphertext should effectively be pseudo random. .
What this technology does is make sure that what you find in memory is not the key, or the data, but rather an un-transformed version of it which must have a hardware alogorithm applied to it in addition to the base cipher. NB: Many of these techniques are already applied through software cipher and data obfuscation.
If the user can change the keys, what's the point? Yes they should be able to change some keys, there own for example, but not the trusted signing authority. It's back to the big PKI nutshell. How the hell do you share and authenticate keys! At the end of the day there has to be a trusted source, TPMs seem the best way of doing this to me.
And to the person who said 'this will be hell to debug'.... That's the point!
I completely concur,
Tilden's work is impressive but extremely limited in scope. It has found much use in Toy manufacture but it is not useful in controlling complex systems.
The 'nervous nets' are the best example of this. He paints the picture that they are intelligent adaptive networks while in truth they are nothing more that a chain of self-stabilising bi-stables.
What annoys me the most about him though is the way that he overly trumpets his own work as being much more important than it actually is. In the past he has compared his Robosapien, which walks with a static shuffling gait, to Sony's QRIO and Honda's Asimo which walk dynamically using limbs with multiple DOFs similar to other bipeds in nature like human beings.
Becoming forgetful and posting dupe articles to /.
void main( void )
{
bool aprilFool = FALSE;
int tireSome = 0;
char * slashdotStory = NULL;
while ( PATIENCE_LIMIT > tireSome )
{
slashdotStory = readStory();
aprilFool = isAprilFool ( slashdotStory );
if ( TRUE == aprilFool )
{
tireSome++;
}
}
visitOtherWebsites();
}
The development cycle usually consists of sitting in meetings while the architects and project managers hmmm and hah over what features to scope and de-scope for this particular release. This usually achieves nothing, at the very last minute they'll tell us to design something which has a set of features that don't interact well and require others that have been de-scoped. We now have exactly one week to code and module test the thing.
After many late nights the code is finished and the next few weeks are frought with Integration nightmares that the managers failed to take account of in their initial high level design. This isn't usually as bad as it should be as those of us doing the actual coding can often identify issues at the implementation stage and fix them there. When we tell the managers about this it usually offends them.
Integration complete, there is now about 5% of the work left to do in tidying up loose ends and streamlining code. The powers that be deem this to be un-necessary and my name appears on the Gantt chart of another project. Because I didn't get a chance to complete this final 5% of the work I will probably face a Bugzilla email deluge in the next month.
The answer, short development cycles, Extreme programming, unified process etc.>
Design, code, test and integrate in 3 -4 week cycles. Design decisions can't be drawn out and must be made quickly, coding and testing is done in manageable amounts and integration no longer presents a nightmare. Code is good the first time around for the small number of features implemented in that cycle, and far less buggy.
Unfortunately people are too stuck in their ways to change.
They need to get back to what the internet is all about, what increased 3G bandwidth is all about, hell, what am I talking about? High definition porn direct to your hand... ( just where you need it )
And the name of this new product, the RIM BlueBerry .
Himem.sys and emm386.exe, I had nearly forgotten all about you guys, ahhhh those were the days.
For those who want more of this jovial tweakfest go here
I was hoping for a bookshelf. I wanted a somewhere to store my books and all I got was this lousy online file store.
But... have you looked at what's in your laptop or cell-phone battery? The answer is a rather unpleasant mix of corrosive substances and reactive metals.
Good design abstracts the user from the dangers of using such materials while allowing them to garner the benefits of doing so. It's an immature technology, give it a chance.