Bruce Schneier talks about a secure, anonymous voting system in "Applied Cryptography". I don't remember exactly how it goes (and don't have the book in front of me), but it involves making it improbable that someone would be able to get away with cheating.
Speed is not an issue any longer. 2D is already about as fast as you're going to get. There are other issues, though.
Support for Multi-Headed: Matroxes do this for sure. Mandrake and Rasterman have posted screenshots of multiheaded X running with Matroxen. I'm pretty sure S3 968 chips do, too. XFree86 should have support for this is the release schedualed for this month.
Color Depth Overlays: Some cards will be able to have an 8 bit buffer running within a 16 or 32 bit buffer. I don't know of any that do, but a little research should find some. This is really useful for using those programs that only run in 8-bit or 16-bit on a 32-bit screen.
Driver Support: Not only X, but SVGALib, GGI, etc.
I'm sure there are more issues, but these are the ones I could come up with off the top of my head.
What do you mean? A message gets encrypted and then cyphertext gets encrypted two mre times?
Yes, more or less. DES is fixed at 56bit strength. It's part of the algorithm. Some attempts have been made to increase DES's bit length, but without much success.
RSA encryption is used to exchange the actual keys.
This is how we do it now. It is virtually bulletproof, but there are associated problems. For instance, what if the symmetric cipher you use to encrypt all the data, once the keys have been exchanged, is weak? This is the case with using DES. Also, public key exchange produces some hairy problems. If I've met you in person, it's no problem. You just give me a disk with the key on it, but then why use public key encryption at all? If I get your key off the Internet, how do I know it's really you and not someone pretending to be you? There are other problems, but this is all off topic. The reason people are claiming that this machine isn't secure is because you use DES to encrypt bulk data, and DES is insecure.
Chances are, the keys used won't be based on a passphrase. Instead, it should gather the keys from a good source of randomness. The keys would be generated automatically and exchanged using RSA or Diffie Hellman.
Um...I don't think a DES encrypter is going to be able to reach out and kill someone who's trying to crack it.
ICE was credited to Tom Maddox, author of Halo (if I remember correctly). He's not as prolific as Sterling or Gibson, but he's a great writer. It also happens that I went to college with his son, so I may be a little biased:)
It is not too difficult to predict when important information is going to be sent. For instance, at the beginning of the day, people will generally be responding to email. Take the hours between 7 and 10 AM and try decrypting all the data. Couple that with the fact that most emails contain similar headers and it's easy to find the messages you need.
Eventually, even if it takes 48 hours (as compared to the 22 hours quoted for cracking DES), you will have that data. It doesn't matter that the key was changed later. Sniffing a network and storing the data on disk is not difficult
It's not script kiddies we're worried about. It's well funded, dedicated attackers. For me, it's the US government, but it may be any number of organizations
Indeed RSA is asymmetric and DES is symmetric. There are more than just 2 asymmetric ciphers. There's RSA, Diffie-Hellman, Elliptical Curves, El Gamal, and probably others I'm missing. RSA is the most common because it's useful for signing and key exchange as well as being the fastest encryptor/decryptor (as compared to key generation, which DH is faster).
Asymmetric isn't used for encryption. It's too slow. Use a symmetric cipher for encryption, but exchange the keys using an asymmetric.
While DES is low security (only 56 bits), this chip allows you to change keys very fast, so Triple-DES (encrypt with one key, decrypt with a second, and reencrypt with the first or a third, depending) is possible.
simply linking/dev/audio to a file won't work./dev/audio is an 8-bit interface, so you really want to use/dev/dsp./dev/dsp does stuff like let you query it's sampling rate, etc. and can not be reproduced by a simple file.
However, apps like vsound and possibly esd will allow you to copy all data sent to/dev/dsp to a file. This is essentially what you're talking about.
So, there isn't really a good, technical, way of enforcing copyrights when you can play the file on a Linux box (and I imagine there can be similar hacks for Windows). The only solution that I can see is what you suggested, use the government.
VC/C++ doesn't have any source control system. Your comparison is inept. Visual Source Safe is the proper comparison. See my other comments on this thread for why not to use VSS.
It's indicative of your quality as a programmer that you don't know what your tools do.
Um... MS VC++ doesn't come with project management. DevStudio uses Visual Source Safe.
VSS works by mapping the filesystem of the server and acting directly on the files. That way, a poorly implemented or malicious client could totally destroy the repository. It also makes it very difficult to use through firewalls and whatnot. The protocol used is NetBEUI, which is archaic.
CVS uses TCP/IP sockets. It works through firewalls nicely. It has a couple GUIs that are at least as nice as VSS, so you aren't stuck in a CLI interface.
I am currently using both systems. VSS at work and CVS at home. I found CVS easy to setup, easy to use, stable, robust and effective. VSS is easy to use and stable enough, but it's setup is difficult and the protocol issue is enough to drive our administrators to drink.
Servers need dedicated hardware crypto. A lot of servers will have pages cached in memory. Run 1000 connections from RAM over a T3 or bigger pipe and software crypto begins to become very slow.
Generally, the sensitive data is sent in small chunks. A normal SSL session, for instance, will contain a whole bunch of images and HTML and maybe a dozen bytes of credit-card info.
It would be an easy thing to find out which chunk of data is important in the SSL e-commerce instance. Changing keys is always a good idea, but it's no sustitute for strong crypto.
I think this is similar to the stuff Precision Insight is doing with their DRI. Not necessarily greyscale fonts, but you can have direct access to the video card to make it faster.
The Proper Way - Support the Engineers
on
Feature:Geek Jobs
·
· Score: 1
Most companies are having a real hard time hiring people. They have given up and relegated the responsibility to other people, namely their own engineers and headhunters.
Both get money for finding you. Headhunters get a lot more. But, the engineers typically get from one to five THOUSAND dollars for every person they find that gets hired.
I've had the best luck by contacting engineers at the company I want to work for. Do some searching. Look through USENET and Slashdot for the company name. Look at the company directory. Find the name of an engineer.
Call the company and request that engineer. Tell him/her that you are thinking about applying to the company and want to know more about it. Offer to buy the engineer lunch. Most of the time, this will end up giving you your first informal interview.
Go to the lunch with your resume. If you like the engineer, give your resume to him/her. If you don't like the engineer, find another company and repeat. You don't want to work with people you don't get along with.
Once the engineer has your resume, he/she is now responsible for dealing with it. Generally this works out well because they have a couple thousand dollars invested in getting this resume to the proper person.
You end up with a good chance of getting seen, the engineer gets the bonus, the company doesn't have to pay a headhunter. Everyone's happy except the headhunters.
Re:What was that focus group smoking? I want some.
on
K7 Renamed "Athlon"
·
· Score: 1
sorry to disagree, but there are plenty worse names. "RISC" comes to mind (who wants to spend a lot of money on a risk? maybe Wall Street). So does "Alpha" (who wants a processor that's not even in Beta yet?). Athlon doesn't touch these!
But, I'll throw in a vote for StrongARM as one of the best!
I always hated Alpha. I keep thinking it's feature complete, but not tested or bug-free (which is what "alpha" means in my company). Seems a better name for the Pentium:)
For people who need that last 5% of performance and can't bear the thought of X11 using it, don't forget to turn off Linux when you start your games either, because it's chewing about 5% in lots of places too (disk, scheduler, buffer copies for the audio, etc). Can you believe I'm actually feeling nostalgic for DOS?:)
Programs that don't use X don't need a direct rendering interface. A DRI allows a program to bypass X and write directly to the graphics card. Anything that doesn't use X doesn't need to bypass it. But, the theory involved and littles bits of code might be useful for, eg., berlin.
Slashdot Mirror
Kingpin appears to be based on Quake2. So, you can run it with software rendering. I'd expect somewhere between .25 and 1 frame per second :)
Seriously...if you don't have gaming hardware, you're going to have trouble playing the latest games.
If your server's dead, how are they going to run rm?
Seriously, though, I doubt Unisys cares about individual users.
I believe these will only decompress LZW. The patent only covers compression.
The voting booths wouldn't be able to handle the strain :)
Reporter: "Mr. Foobar, do you have any comments on why you lost?"
Mr. Foobar: "Well, Rep...the fact is that my district's booths were slashdotted, leading to an improper count."
scary
Bruce Schneier talks about a secure, anonymous voting system in "Applied Cryptography". I don't remember exactly how it goes (and don't have the book in front of me), but it involves making it improbable that someone would be able to get away with cheating.
Um...this is about England.
Speed is not an issue any longer. 2D is already about as fast as you're going to get. There are other issues, though.
Support for Multi-Headed: Matroxes do this for sure. Mandrake and Rasterman have posted screenshots of multiheaded X running with Matroxen. I'm pretty sure S3 968 chips do, too. XFree86 should have support for this is the release schedualed for this month.
Color Depth Overlays: Some cards will be able to have an 8 bit buffer running within a 16 or 32 bit buffer. I don't know of any that do, but a little research should find some. This is really useful for using those programs that only run in 8-bit or 16-bit on a 32-bit screen.
Driver Support: Not only X, but SVGALib, GGI, etc.
I'm sure there are more issues, but these are the ones I could come up with off the top of my head.
What do you mean? A message gets encrypted and then cyphertext gets encrypted two mre times?
Yes, more or less. DES is fixed at 56bit strength. It's part of the algorithm. Some attempts have been made to increase DES's bit length, but without much success.
RSA encryption is used to exchange the actual keys.
This is how we do it now. It is virtually bulletproof, but there are associated problems. For instance, what if the symmetric cipher you use to encrypt all the data, once the keys have been exchanged, is weak? This is the case with using DES. Also, public key exchange produces some hairy problems. If I've met you in person, it's no problem. You just give me a disk with the key on it, but then why use public key encryption at all? If I get your key off the Internet, how do I know it's really you and not someone pretending to be you? There are other problems, but this is all off topic. The reason people are claiming that this machine isn't secure is because you use DES to encrypt bulk data, and DES is insecure.
Chances are, the keys used won't be based on a passphrase. Instead, it should gather the keys from a good source of randomness. The keys would be generated automatically and exchanged using RSA or Diffie Hellman.
Um...I don't think a DES encrypter is going to be able to reach out and kill someone who's trying to crack it.
:)
ICE was credited to Tom Maddox, author of Halo (if I remember correctly). He's not as prolific as Sterling or Gibson, but he's a great writer. It also happens that I went to college with his son, so I may be a little biased
It is not too difficult to predict when important information is going to be sent. For instance, at the beginning of the day, people will generally be responding to email. Take the hours between 7 and 10 AM and try decrypting all the data. Couple that with the fact that most emails contain similar headers and it's easy to find the messages you need.
Eventually, even if it takes 48 hours (as compared to the 22 hours quoted for cracking DES), you will have that data. It doesn't matter that the key was changed later. Sniffing a network and storing the data on disk is not difficult
It's not script kiddies we're worried about. It's well funded, dedicated attackers. For me, it's the US government, but it may be any number of organizations
Indeed RSA is asymmetric and DES is symmetric. There are more than just 2 asymmetric ciphers. There's RSA, Diffie-Hellman, Elliptical Curves, El Gamal, and probably others I'm missing. RSA is the most common because it's useful for signing and key exchange as well as being the fastest encryptor/decryptor (as compared to key generation, which DH is faster).
Asymmetric isn't used for encryption. It's too slow. Use a symmetric cipher for encryption, but exchange the keys using an asymmetric.
While DES is low security (only 56 bits), this chip allows you to change keys very fast, so Triple-DES (encrypt with one key, decrypt with a second, and reencrypt with the first or a third, depending) is possible.
Seems like you use it as a $450 replacement for a $1500 notebook, which makes a lot of sense.
simply linking /dev/audio to a file won't work. /dev/audio is an 8-bit interface, so you really want to use /dev/dsp. /dev/dsp does stuff like let you query it's sampling rate, etc. and can not be reproduced by a simple file.
/dev/dsp to a file. This is essentially what you're talking about.
However, apps like vsound and possibly esd will allow you to copy all data sent to
So, there isn't really a good, technical, way of enforcing copyrights when you can play the file on a Linux box (and I imagine there can be similar hacks for Windows). The only solution that I can see is what you suggested, use the government.
VC/C++ doesn't have any source control system. Your comparison is inept. Visual Source Safe is the proper comparison. See my other comments on this thread for why not to use VSS.
It's indicative of your quality as a programmer that you don't know what your tools do.
Um... MS VC++ doesn't come with project management. DevStudio uses Visual Source Safe.
VSS works by mapping the filesystem of the server and acting directly on the files. That way, a poorly implemented or malicious client could totally destroy the repository. It also makes it very difficult to use through firewalls and whatnot. The protocol used is NetBEUI, which is archaic.
CVS uses TCP/IP sockets. It works through firewalls nicely. It has a couple GUIs that are at least as nice as VSS, so you aren't stuck in a CLI interface.
I am currently using both systems. VSS at work and CVS at home. I found CVS easy to setup, easy to use, stable, robust and effective. VSS is easy to use and stable enough, but it's setup is difficult and the protocol issue is enough to drive our administrators to drink.
"In the future, you're going to get computers as prizes in breakfast cereals. You'll throw them out because your house will be littered with them."
fortune files are ascii text files with "%" on a line by itself to separate. You can use grep to search through them.
Servers need dedicated hardware crypto. A lot of servers will have pages cached in memory. Run 1000 connections from RAM over a T3 or bigger pipe and software crypto begins to become very slow.
Generally, the sensitive data is sent in small chunks. A normal SSL session, for instance, will contain a whole bunch of images and HTML and maybe a dozen bytes of credit-card info.
It would be an easy thing to find out which chunk of data is important in the SSL e-commerce instance. Changing keys is always a good idea, but it's no sustitute for strong crypto.
I think this is similar to the stuff Precision Insight is doing with their DRI. Not necessarily greyscale fonts, but you can have direct access to the video card to make it faster.
Most companies are having a real hard time hiring people. They have given up and relegated the responsibility to other people, namely their own engineers and headhunters.
Both get money for finding you. Headhunters get a lot more. But, the engineers typically get from one to five THOUSAND dollars for every person they find that gets hired.
I've had the best luck by contacting engineers at the company I want to work for. Do some searching. Look through USENET and Slashdot for the company name. Look at the company directory. Find the name of an engineer.
Call the company and request that engineer. Tell him/her that you are thinking about applying to the company and want to know more about it. Offer to buy the engineer lunch. Most of the time, this will end up giving you your first informal interview.
Go to the lunch with your resume. If you like the engineer, give your resume to him/her. If you don't like the engineer, find another company and repeat. You don't want to work with people you don't get along with.
Once the engineer has your resume, he/she is now responsible for dealing with it. Generally this works out well because they have a couple thousand dollars invested in getting this resume to the proper person.
You end up with a good chance of getting seen, the engineer gets the bonus, the company doesn't have to pay a headhunter. Everyone's happy except the headhunters.
sorry to disagree, but there are plenty worse names. "RISC" comes to mind (who wants to spend a lot of money on a risk? maybe Wall Street). So does "Alpha" (who wants a processor that's not even in Beta yet?). Athlon doesn't touch these!
But, I'll throw in a vote for StrongARM as one of the best!
I always hated Alpha. I keep thinking it's feature complete, but not tested or bug-free (which is what "alpha" means in my company). Seems a better name for the Pentium :)
For people who need that last 5% of performance and can't bear the thought of X11 using it, don't forget to turn off Linux when you start your games either, because it's chewing about 5% in lots of places too (disk, scheduler, buffer copies for the audio, etc). Can you believe I'm actually feeling nostalgic for DOS? :)
Programs that don't use X don't need a direct rendering interface. A DRI allows a program to bypass X and write directly to the graphics card. Anything that doesn't use X doesn't need to bypass it. But, the theory involved and littles bits of code might be useful for, eg., berlin.