Rijndael is a variable key length, variable block length cipher. The keys and blocks can be 128, 192 or 256 bits long. This gives a total of 9 different variants that could be specified to use the particular algorithm.
The AES has selected the variable key lengths of 128, 192, 256 to be used with a 128 bit block
BouncyCastle has had a full implementation of Rijndael since 1.0 beta 4 (now at 1.10)
Disclaimer: I'm a BouncyCastle author.
Re:My freedom of choice is most important.
on
Freedom or Power?
·
· Score: 1
You seem to have missed the point of Free Software and the GPL entirely.
No I haven't. I know exactly what the GPL and free software is all about. I have produced more publicly available software that 90% of people who post to slashdot have.
Also, re-read the article that was posted. The essential statement is that any license that isn't the GNU approved licence reduces the freedoms for others.
In case you didn't read my response, I wasn't particularly disagreeing with that, but pointing out what a mind-boggingly stupid assertion that is was, and that holding true to that philosophy would be of detriment to those who really care about producing code for others to use.
All of my code is not released under the GPL because it restricts the freedoms of people to use my code to earn a living.
There's nothing in the GPL or GNU or the Free Software movement that says you can 't sell code
Stop trumpeting the party line. Sheesh. At least read a bit about me before you go and blather about stuff. It's like talking to a 14yo about sex. They've got plenty of repeated opinions, but none of them have done anything about it.
My freedom of choice is most important.
on
Freedom or Power?
·
· Score: 1, Insightful
If I don't have the freedom of choice, then I can't choose to sell software to eat, which enables me to write software for the benefits of others. I can't contribute to the freedom of others unless I have the freedom to choose to feed myself.
I have special skills (as do many here), I can transform code into working, useful applications, libraries, patches, whatever. It's what I do to sustain myself in an employment capacity.
So, if I write some code at home, for myself, I can't even decide to keep it a secret. I have to release it and it has to be released under the GNU license because otherwise I'll be infringing on the freedoms of others in my power hungry quest for world domination. Yeah, right.
Where's my freedom now ? It's strange that I might want to sell some of my software and give others away, and even write some just for my own pleasure. That's freedom, the freedom of choice, and quite frankly, RMS's infringing my rights to choose far more than Bill Gates has ever tried to do.
So RMS, what do I do to live ? Sweep streets during the day, and write code all night so I preserve the freedom of others.
Underneath all those spiffy RC mechanisms are
raw sockets/pipes calls. Testing fundamental
mechanisms like this is quite relevant as COM
isn't going to go any faster if you've got a
crappy underlying data shuffling mechanism.
If the TCP/IP stack is crap, then remote comms
is going to be crap. Nobody I know writes
raw IP packets to the interface, but everybody
who wants to communicate over a wire is going
to use that stack.
Don't CS classes teach people anything these
days. The number of/. readers that obviously
don't have the faintest clue about how IPC
mechanisms work just stagger me.
Sheesh, I wouldn't let half of you guys turn
on my computer, let alone program it.
It may not be teleportation, but it's certainly
the ultimate key exchange. Here let me generate
a secret key at my end. Now, with my QE I twizzle
the magic at this end. Bingo ! Instantly reproduceable at the other.
As somebody who's spent some time over the last 2 years creating Java implementations of a number of the popular algorithms with BouncyCastle being the latest version. (Open Source and all that).
The choice for what algorithm to use depends on a number of factors%2C and in my experience, it certainly helps to understand where it is going to be deployed (in hardware, small device like a Palm or a general purpose computer) and what is going to be protected (passwords, documents, streaming media).
As a great example, Blowfish is a mighty fine algorithm, but the key schedule setup takes the equivalent time of encrypting about 5k of data. If you're going to be encrypting lots of small things with different keys then Blowfish probably isn't all that suitable. Blowfish's key schedule arrays are quite large, so in devices with limited memory (like the Palm) it isn't suitable.
Twofish on the other hand has been designed to overcome a number of those limitations (pretty much because of the AES requirements).
So, understand what problems the alrithms were designed to solve, and find one that matches yours.
As has been stated many times, encrypting the data is only one link in the chain. If your key generation or exchange is weak, then you may as well not bother encrypting at all.
It's the Web industry, not all computing
on
Too Old To Code?
·
· Score: 1
It's the glitz and glam of the screaming dotcoms that are perpetuating this myth of the young super-programmer. And basically, it's just crap.
I'm a 33 year old core-nerd with skills in software engineering. That means I know how to write code that keeps on keeping on. That's something the young and enthusiastic just don't know how to do.
They can't keep their hands off the keyboard long enough to do a proper analysis of the problem before diving in and solving some other problem that might be vaguely related.
I'm in a position now where I'm working with one of the more well known web development and design companies and I'll be in a position to help influence hiring, and I'll certainly want to have a group of young and enthusiastic people, but you can be that I'll be pushing for people in their late 20s to early 30s with maturity and experience to keep tight control on the loose cannons.
You may consider this a flame, but it's not, people need to recognise with the greater amount of business-to-business and technology integration that is occurring on the web at the moment that we need to learn from other disciplines and pay more attention to the design of the system.
How much more bad press does this industry need from hiring young hot-shots who leave gaping security holes and couldn't manage performance analysis while they develop "kewl" sites.
Maturity is an undervalued asset at present, and what people need to understand is that old war-horses have fought in lots of battles and understand how to win.
I am seeing the tide turning, and that's a good sign for companies and their customers.
Great comment, but I felt that the article did attempt to compare apples with apples. In the sense that probably you, or I, could apply patches to the busted-ass application that was causing the security hole, but generally speaking most system administrators are experts at system administration (running the network, routing, etc, etc) and not necessarily ruthless code hackers of Kung Fu level.
As a case in point, where I worked previously, we used OpenBSD and we had security patches installed in the order of hours generally after they were identified and fixes released. In some cases we were capable of making the changes directly to the source based on the bug report.
I would say that scenario is probably rare, and we (the Penguinista) don't really want to imply that to effectively use Open Source you need a bunch of trained uber-hackers who can modify the source faster than a spinning shuriken. We need to show that, even if you have NO additional resources the Open Source model is a big win because there are all these other people out there who can identify fixes and make them available for you.
So, I felt that the use of Red Hat was a great example of an Open Source system because it's how the majority of the target audience (new Penguinista) will use, or be introduced to Open Source.
If you happen to have, or to be, an uber-hacker then you just win more.
When the encrypted media, the decryption keys and the device that does the decryption is in the hands of the consumer.
At some stage, the encrypted stream becomes plain text, and the information then can be trivially copied.
It doesn't matter how much effort is put into the encryption algorithms.
At some stage at least one key is read off the disk and used in plain text, so it can be identified and located.
At some stage the algorithm is used/executed so the steps can be seen. With the algorithm and one key, the remainder of the keys can be trivially found by brute force.
What people need to understand is that there cannot be anything really secret here, it's just "hard" to identify. (or in this case, relatively easy). Everything this encryption scheme has, is there for people to watch as it goes through it's paces. You just need to invest the time and effort to perform the observation.
Encryption of the media was NEVER going to work. It didn't protect anything. It gave the ILLUSION of protecting things. The MPAA just WANTED it to work, and now, because it never did, they are trying to litigate a solution.
The bad news for them is that technology doesn't understand law, and it doesn't matter how much they don't want their busted protection scheme to work, it never has, it never will. In some ways I feel sorry for them, because they've invested all this time and effort into a scheme that doesn't work.
I wonder how the "technical" advisor who identified this scheme is feeling now ? Who'd like to be a fly on the wall in their next "performance review" ?;-)
Wow, two topics that I actually know about, in a space of days. Wonders will never cease.
SET is completely unworkable. It requires an infrastructure (PKI) that somebody has to provide and that infrastructure is costly. The other issue was that it required the processing performed at the merchant site (real world, not electronic). This is also unworkable because most merchants don't have the capacity to run the technology required.
I was involved in investigating SET for operation in the "real world" not some mickey-mouse VISA/BANK setup that "prooved" it worked. Ack!
What the banks should be doing is enforcing their TOS which (in Australia) state that credit card numbers cannot be recorded for any purpose other than for the duration of the transaction. So, you can take down the CC# and use it to process the transaction, and then it must not be kept for any other reason. None at all. As for the USA ? YMMV.
As you state, transfer the money, not the card. That's pretty much how it should be. If you encrypt the card details and the decrypted card details is only used to approve the availability of funds, the "window of opportunity" can be kept to a minimum. With appropriate encryption, the decryption of the CC# can be done at the bank, and the cc# is never, ever in the clear outside the banking network. That's how it should be done. Oh, did I forget to mention that's why we did when I was involved in developing a credit card authorisation system.;-)
Why don't the banks care ? Well, it doesn't cost them any money, now does it ? The merchant and the consumer always lose. (Mostly the merchant) Cheers,
The bank protocols are open. At least here in Australia. They are governed by a standard called AS2805. (There is a variant called AS2805F used by FDR-A). It describes the protocol messages used by the banking network to communicate things.
I could go into long and boring detail about what each of the messages do, but to preserve sanity, I will refrain.
What is "closed" is who the banks will talk to with this protocol. This is a "good thing" (tm). You are required to have your product certified by the bank by a test regime that they require to be performed.
So, you can get a copy of AS2805, write a gateway (open or closed source, your choice) and talk to your local bank about getting an expensive X.25 connection to them, and you can pass financial transactions (in my case credit card transactions) to the banking network.
How do I know ? Well, I've done it.
The company previously known as ABA (now eSec) built a real-time credit-card transaction system all in Java. I was one of 6 programmers involved in the development.
Offtopic rant: There is some desperate need for many of the Slashdotters to do some research or thinking _before_ posting. The editors posting stories should also be a lot more responsible in their editorial comments. Slashdot has recently become a very "bandwagoneer" production which is starting to mimic the popular press.
What a great deal of the posters have appeared to have missed is that development of Open Source products contribute to advertising your skills.
The most important thing about this form of advertising is that you are telling potential employers/investors that, given a completely free reign, I can create high quality, groundbreaking software
Posters have noted that you'll get a job, if you've got a good resume, open source or not. While that is true, if you're stuck doing VB hacking in Microsoft hell, contributing to other projects can show potential employers that you've got more strings to your bow.
Besides, it's fun. And that's the most important reason to me.
Unfortunately, username/password are nothing like a lock and key. With a physical key, there is a physical object that is required, with a username/password there are no physical objects required.
(lets not start the analogy wars here, but) Username/password is more like a combination lock and knowing the number. To access to item secured by the combination lock, you only need to know the combination.
"Something owned, and something known" is a useful phrase when assessing the relative security of schemes. If you only have to "know" things, and not "own" things, then IMNSHO it's less secure that "something known" only.
Hence (as you mentioned) owning a certificate is a very useful security mechanism.
I am not a lawyer, nor do I play one on TV, the internet or as a book character. This is my opinion and worth exactly what you paid me for it
As somebody who has developed Crypto software outside the USA, I can say that in my opinion if you tried that game, you'd get to have a very close association with Bubba, who'd want to make you his own personal friend.
There is a key part in the US laws regarding "giving aid to foreign nationals" which doesn't necessarily mean that it's actually doing the work, but merely assisting in that work being performed.
Remember, these fall under the jurisdiction of munitions, and if I tell you how to make a nuke, even if I'm not physically present, then helping them make the nuke is (according to the laws) bad.
I was involved in the development of one of the JCE's that are now available outside the USA, to do this, we had to reverse engineer how the code must work, by looking at the interfaces provided by Sun. There's not even any crypto algorithm code in the JCE.
There's a document on Sun's web site relating to the implementation of a cryptographic provider (which is where all the crypto algorithms actually exist) and how it interacts with the JCE. If you are outside the USA, you aren't allowed to download this document because it will assist you in developing cryptography (read munitions).
In summary. I wouldn't do this if you value being able to walk around outside wherever you want, whenever you want.
Slashdot Mirror
The AES has selected the variable key lengths of 128, 192, 256 to be used with a 128 bit block
BouncyCastle has had a full implementation of Rijndael since 1.0 beta 4 (now at 1.10)
Disclaimer: I'm a BouncyCastle author.
No I haven't. I know exactly what the GPL and free software is all about. I have produced more publicly available software that 90% of people who post to slashdot have.
Also, re-read the article that was posted. The essential statement is that any license that isn't the GNU approved licence reduces the freedoms for others. In case you didn't read my response, I wasn't particularly disagreeing with that, but pointing out what a mind-boggingly stupid assertion that is was, and that holding true to that philosophy would be of detriment to those who really care about producing code for others to use.
All of my code is not released under the GPL because it restricts the freedoms of people to use my code to earn a living.
There's nothing in the GPL or GNU or the Free Software movement that says you can 't sell code
Stop trumpeting the party line. Sheesh. At least read a bit about me before you go and blather about stuff. It's like talking to a 14yo about sex. They've got plenty of repeated opinions, but none of them have done anything about it.
I have special skills (as do many here), I can transform code into working, useful applications, libraries, patches, whatever. It's what I do to sustain myself in an employment capacity.
So, if I write some code at home, for myself, I can't even decide to keep it a secret. I have to release it and it has to be released under the GNU license because otherwise I'll be infringing on the freedoms of others in my power hungry quest for world domination. Yeah, right.
Where's my freedom now ? It's strange that I might want to sell some of my software and give others away, and even write some just for my own pleasure. That's freedom, the freedom of choice, and quite frankly, RMS's infringing my rights to choose far more than Bill Gates has ever tried to do.
So RMS, what do I do to live ? Sweep streets during the day, and write code all night so I preserve the freedom of others.
You've lost the plot buddy. Give the game away.
Dang, I meant DCOM, not COM. Mea culpa.
Microsoft driving the industry. Sheesh, more like :
Microsoft booked for drink driving.
HTH. HAND.
How do you think that COM actually communicates ?
/. readers that obviously
Magic ? Waving little hands in the air. ?
Underneath all those spiffy RC mechanisms are
raw sockets/pipes calls. Testing fundamental
mechanisms like this is quite relevant as COM
isn't going to go any faster if you've got a
crappy underlying data shuffling mechanism.
If the TCP/IP stack is crap, then remote comms
is going to be crap. Nobody I know writes
raw IP packets to the interface, but everybody
who wants to communicate over a wire is going
to use that stack.
Don't CS classes teach people anything these
days. The number of
don't have the faintest clue about how IPC
mechanisms work just stagger me.
Sheesh, I wouldn't let half of you guys turn
on my computer, let alone program it.
It may not be teleportation, but it's certainly
the ultimate key exchange. Here let me generate
a secret key at my end. Now, with my QE I twizzle
the magic at this end. Bingo ! Instantly reproduceable at the other.
Better not let the terrorists get hold of this.
Cheers,
-- jon
Slashdot Poll
The outcome I'd most like to see with Rocket Man is:
Cheers,
-- jon
The choice for what algorithm to use depends on a number of factors%2C and in my experience, it certainly helps to understand where it is going to be deployed (in hardware, small device like a Palm or a general purpose computer) and what is going to be protected (passwords, documents, streaming media).
As a great example, Blowfish is a mighty fine algorithm, but the key schedule setup takes the equivalent time of encrypting about 5k of data. If you're going to be encrypting lots of small things with different keys then Blowfish probably isn't all that suitable. Blowfish's key schedule arrays are quite large, so in devices with limited memory (like the Palm) it isn't suitable.
Twofish on the other hand has been designed to overcome a number of those limitations (pretty much because of the AES requirements).
So, understand what problems the alrithms were designed to solve, and find one that matches yours.
As has been stated many times, encrypting the data is only one link in the chain. If your key generation or exchange is weak, then you may as well not bother encrypting at all.
I'm a 33 year old core-nerd with skills in software engineering. That means I know how to write code that keeps on keeping on. That's something the young and enthusiastic just don't know how to do.
They can't keep their hands off the keyboard long enough to do a proper analysis of the problem before diving in and solving some other problem that might be vaguely related.
I'm in a position now where I'm working with one of the more well known web development and design companies and I'll be in a position to help influence hiring, and I'll certainly want to have a group of young and enthusiastic people, but you can be that I'll be pushing for people in their late 20s to early 30s with maturity and experience to keep tight control on the loose cannons.
You may consider this a flame, but it's not, people need to recognise with the greater amount of business-to-business and technology integration that is occurring on the web at the moment that we need to learn from other disciplines and pay more attention to the design of the system.
How much more bad press does this industry need from hiring young hot-shots who leave gaping security holes and couldn't manage performance analysis while they develop "kewl" sites.
Maturity is an undervalued asset at present, and what people need to understand is that old war-horses have fought in lots of battles and understand how to win.
I am seeing the tide turning, and that's a good sign for companies and their customers.
As a case in point, where I worked previously, we used OpenBSD and we had security patches installed in the order of hours generally after they were identified and fixes released. In some cases we were capable of making the changes directly to the source based on the bug report.
I would say that scenario is probably rare, and we (the Penguinista) don't really want to imply that to effectively use Open Source you need a bunch of trained uber-hackers who can modify the source faster than a spinning shuriken. We need to show that, even if you have NO additional resources the Open Source model is a big win because there are all these other people out there who can identify fixes and make them available for you.
So, I felt that the use of Red Hat was a great example of an Open Source system because it's how the majority of the target audience (new Penguinista) will use, or be introduced to Open Source.
If you happen to have, or to be, an uber-hacker then you just win more.
Cheers,
I didn't say it wouldn't take a long time, it's just that there is no intelligence involved.
Cheers,
At some stage, the encrypted stream becomes plain text, and the information then can be trivially copied.
It doesn't matter how much effort is put into the encryption algorithms.
At some stage at least one key is read off the disk and used in plain text, so it can be identified and located.
At some stage the algorithm is used/executed so the steps can be seen. With the algorithm and one key, the remainder of the keys can be trivially found by brute force.
What people need to understand is that there cannot be anything really secret here, it's just "hard" to identify. (or in this case, relatively easy). Everything this encryption scheme has, is there for people to watch as it goes through it's paces. You just need to invest the time and effort to perform the observation.
Encryption of the media was NEVER going to work. It didn't protect anything. It gave the ILLUSION of protecting things. The MPAA just WANTED it to work, and now, because it never did, they are trying to litigate a solution.
The bad news for them is that technology doesn't understand law, and it doesn't matter how much they don't want their busted protection scheme to work, it never has, it never will. In some ways I feel sorry for them, because they've invested all this time and effort into a scheme that doesn't work.
I wonder how the "technical" advisor who identified this scheme is feeling now ? Who'd like to be a fly on the wall in their next "performance review" ? ;-)
Cheers,
SET is completely unworkable. It requires an infrastructure (PKI) that somebody has to provide and that infrastructure is costly. The other issue was that it required the processing performed at the merchant site (real world, not electronic). This is also unworkable because most merchants don't have the capacity to run the technology required.
I was involved in investigating SET for operation in the "real world" not some mickey-mouse VISA/BANK setup that "prooved" it worked. Ack!
What the banks should be doing is enforcing their TOS which (in Australia) state that credit card numbers cannot be recorded for any purpose other than for the duration of the transaction. So, you can take down the CC# and use it to process the transaction, and then it must not be kept for any other reason. None at all. As for the USA ? YMMV.
As you state, transfer the money, not the card. That's pretty much how it should be. If you encrypt the card details and the decrypted card details is only used to approve the availability of funds, the "window of opportunity" can be kept to a minimum. With appropriate encryption, the decryption of the CC# can be done at the bank, and the cc# is never, ever in the clear outside the banking network. That's how it should be done. Oh, did I forget to mention that's why we did when I was involved in developing a credit card authorisation system. ;-)
Why don't the banks care ? Well, it doesn't cost them any money, now does it ? The merchant and the consumer always lose. (Mostly the merchant) Cheers,
I could go into long and boring detail about what each of the messages do, but to preserve sanity, I will refrain.
What is "closed" is who the banks will talk to with this protocol. This is a "good thing" (tm). You are required to have your product certified by the bank by a test regime that they require to be performed.
So, you can get a copy of AS2805, write a gateway (open or closed source, your choice) and talk to your local bank about getting an expensive X.25 connection to them, and you can pass financial transactions (in my case credit card transactions) to the banking network.
How do I know ? Well, I've done it.
The company previously known as ABA (now eSec) built a real-time credit-card transaction system all in Java. I was one of 6 programmers involved in the development.
Offtopic rant: There is some desperate need for many of the Slashdotters to do some research or thinking _before_ posting. The editors posting stories should also be a lot more responsible in their editorial comments. Slashdot has recently become a very "bandwagoneer" production which is starting to mimic the popular press.
Lift your game, or lose your readers.
The most important thing about this form of advertising is that you are telling potential employers/investors that, given a completely free reign, I can create high quality, groundbreaking software
Posters have noted that you'll get a job, if you've got a good resume, open source or not. While that is true, if you're stuck doing VB hacking in Microsoft hell, contributing to other projects can show potential employers that you've got more strings to your bow.
Besides, it's fun. And that's the most important reason to me.
Unfortunately, username/password are nothing like a lock and key. With a physical key, there is a physical object that is required, with a username/password there are no physical objects required.
(lets not start the analogy wars here, but) Username/password is more like a combination lock and knowing the number. To access to item secured by the combination lock, you only need to know the combination.
"Something owned, and something known" is a useful phrase when assessing the relative security of schemes. If you only have to "know" things, and not "own" things, then IMNSHO it's less secure that "something known" only.
Hence (as you mentioned) owning a certificate is a very useful security mechanism.
Cheers,
-- jon
As somebody who has developed Crypto software outside the USA, I can say that in my opinion if you tried that game, you'd get to have a very close association with Bubba, who'd want to make you his own personal friend.
There is a key part in the US laws regarding "giving aid to foreign nationals" which doesn't necessarily mean that it's actually doing the work, but merely assisting in that work being performed.
Remember, these fall under the jurisdiction of munitions, and if I tell you how to make a nuke, even if I'm not physically present, then helping them make the nuke is (according to the laws) bad.
I was involved in the development of one of the JCE's that are now available outside the USA, to do this, we had to reverse engineer how the code must work, by looking at the interfaces provided by Sun. There's not even any crypto algorithm code in the JCE.
There's a document on Sun's web site relating to the implementation of a cryptographic provider (which is where all the crypto algorithms actually exist) and how it interacts with the JCE. If you are outside the USA, you aren't allowed to download this document because it will assist you in developing cryptography (read munitions).
In summary. I wouldn't do this if you value
being able to walk around outside wherever you want, whenever you want.