If you have to rely on the encryption, then the steganography is useless. The cops will capture your key store, and begin brute forcing the password to that store.
The entire point of the steganography is that it's so obscure that it's unlikely to be noticed in the first place. i.e. An extreme form of security through obscurity.
AKAImBatman I think I might now know where your confusion lies.
It seems to me that you don't understand what is encrypted?
You DON'T insert cleartext into a carrier file with steganography and then encrypt that whole file.
You DO encrypt the cleartext to ciphertext and THEN insert THAT into the carrier file with steganography.
The point here, is that many files contain an element of noise. The ciphertext you just created also should look just like noise. You replace the real noise of the carrier file, with the pseudo noise of the ciphertext. If the noise within the carrier floor does not constitute uniform white noise, then you could distribute the ciphertext (which SHOULD look like white noise), pseudo randomly througout the original noise of the carrier file, so as to not appreciably change the "colour" of the noise.
This is a symbiotic relationship (if people don't mind me applying a biology term to computing). The crypto makes the message hard to decipher and also makes the message look like noise and thus fits in well where noise is expected to be. On the other end, the steganography can exploit this noise like quality by having the ciphertext "noise" replace noise which is expected to be found in many file types and thus hide the fact that there is even a message there at all.
Stego is not as good without crypto and crypto is protected from scrutiny by the stego. Together when done properly, they combine to be greater than the sum of their parts.
BTW, please start thinking for yourself and give up the "security through obscurity" cult chant. Various levels of security can often be gained out of obscurity. Just because some forms are downright terrible does not make them all terrible. You rely on "security through obscurity" and you obviously don't even know it.
By your definition of security through obscurity, nearly every data security method is exactly that. Encryption keys are only useful if you OBSCURE them from the attacker. Usernames and passwords are only useful if they are OBSCURED.
fliplap, thank you. It is nice to see some well thought out reason around here. I have been trying to tell people this for years, yet few people seem to think for themselves and instead vomit out that crusty old "security through obscurity" chestnut over and over like it is a bloody holy commandment from some crazy new religion.
Steganography is more useful when combined with encryption, and encryption is more useful when combined with steganography.
Amen to that! It is amazing how some people will attack a concept because they can think of some implementations which could be bad.
This can be done even through the encryption because the encrypted data still carries the same probability aspects of the original data.
AKAImBatman, please, give up. This is complete and utter nonsense. A properly implemented strong crypto scheme will create output which should be indescernible from uniform white noise. Any crypto scheme which outputs something that is coloured in any way, as in showing some pattern... is BROKEN.
This is a most fundamental feature of strong crypto schemes. Don't believe me? Would you take Bruce Schneier's word for it?
APPLIED CRYPTOGRAPHY, second edition Bruce Schneier Pg. 226 10.6
"If the encryption algorithm is any good, the ciphertext will not be compressible; it will look like random data. (This makes a reasonable test of an encryption algorithm; if the ciphertext can be compressed, then the algorithm probably isn't very good.)
The reason for this, is that real random data should not be compressible by any appreciable amount, nor should cipher text. Bruce cites what he considers to be appreciable in this context as being 1-2%. The purpose of encrypting data is to hide detail or patterns. And that is exactly what good crypto algorithms do. They hide detail, patterns and your "probability aspects".
Before you come back with a response about the fact that crypto is often used with compression, you should realise that the proper procedure in this regard is to compress first and then encrypt. This is good for a few reasons. Firstly, compressing after encrypting is silly, because the gains in compression should be very small or even negative (because the patterns have been REMOVED). Secondly, as Bruce states, "cryptanalysis relies on exploiting redundancies in the plaintext; compressing a file before encryption reduces these redundancies".
Again, it's the encryption that's making the difference. NOT the steganography.
It is a bit hard to attack the encryption when it is hidden amongst thousands of files which have noise floors which look no different to the cipher text. You cannot attack that which you cannot find.
I don't think you really understand just how effective strong encryption can be when combined with a strong steganography process. The stego hides the messages existence and the crypto obscures the message. If you don't encrypt, then stego is useless and conversely if you don't stego, then you flag the target (because it is quite obviously an encrypted message, based on the statistical spread of data alone).
BUT just like you might not be able to encrypted data but you know its encrypted (true encryption is a statiscally even distribution of all characters look it up) you can scan a file and tell if it has been altered by steganography (i think, but dont quote me, because its more random then an image should be) and once you know which are encrypted you can find the algorithim and brute force it.
Yes. Shaped noise versus uniform noise. Or put another way, pink (or maybe green?) noise versus white noise. Especially when the shape of the "pink" noise is expected to have an element of consistency from a given camera for example, or particular audio recording equipment (also there is the 50Hz, 60Hz, etc hum from mains power that can also be expected among other signals we humans might commonly consider "noise"). However, a good crypto algorithm will not create output which is suggestive of the algorithms use. Triple Des cipher text should not look different statistically from AES cipher text, for example.
BTW, I am using the reference here to "Pink" noise loosely merely to seperate from white noise. I do not yet know if I would expect digitized data to exhibit actual pink noise.
even with completly knowledge of the algorithm it should be computationally infeasible to determine a secret message is implanted in the cover text.
That's the most rediculous thing I've ever heard.
If the secret message is first encrypted with a strong algo and key, the output should be indescernible from random noise. If you then insert this "random noise" cipher text into areas of a file where a component of noise is expected to be (Least Significant Bits of a digitized analog signal ie. scanned pictures, recorded audio for example) then it is quite possible to insert a secret message which absolutely cannot be detected. Which "random noise" is the real original random noise and which is the output from the strong crypto?
This assumes that the noise component in the digitized file is expected to have uniform noise. If however the noise component of the digitized file has shaped noise (non uniform), then the presence of uniform noise can alert the investigator that the expected shaped noise has probably been replaced. Regardless, even if they do detect this, if the "replacement noise" is that of a strong cipher text, then they still have the difficult battle of brute force decrypting which may be infeasible to do within a useful timeframe. Also, the "shape" of the original noise could be largely retained if it is interspersed with the secret message and the original noise constitutes enough of the total noise to retain the shape.
He is correct if the secret is encrypted well and inserted in appropriate places in an appropriate file. You could run your stego extracting script on thousands of files, find they all extract to random noise and not be able to determine the "interesting noise" (which holds the cipher text) from the real noise (which holds nothing).
As I have already seen you state elsewhere, encryption prevents a message from becoming known to people you want privacy from and steganography is supposed to hide the fact that a message is even there. Properly implemented, these two hand-in-hand allow both the avoidance of the message being broken in a timely manner and the avoidance of scrutiny. Effectively avoiding scrutiny can provide critical extra time required for your secrets to remain secret for as long as they need to be. It could even avoid scrutiny forever. It is hard to point incredibly powerful resources to a target when you can't find the target to begin with.
The problem is that torture doesn't get you the truth, it gets you exactly what the victim thinks you want to hear. An innocent being tortured will admit to anything to make it stop.
Why do so many people at/. speak in absolutes?
Torture has been used for A VERY LONG TIME because... sometimes it works.
I think the fact that we keep "caputuring" all these "high ranking" al Queda people... but still can't find Osama shows how ineffective torture is at getting real information out of prisoners.
This all comes down to the classic old "need to know" basis. If all those tortured terrorists don't need to know where Osama is, then they should never be informed of that info. They have their immediate trusted person(s) up and down the chain of command and the information passed between them is all they NEED to know.
I think it is silly to expect those terrorists to know where Osama is. I would imagine that only a handful of absolute die hard followers, ready to lay down their lives at any time, could possibly know. They are probably mentally and physically (pistol, poison, etc) prepared at all times to commit suicide to keep his whereabouts secret.
Just because torture does not always work on every person, does not mean it is always useless.
Give us the code or we cut off a toe. Wrong -- cut off another, connect the battery to the genitals, etc.
Because they can immediately test the answers, lying won't save you as it could in open-ended intelligence gathering.
I can take this text:
"Attack the blah building at 9 from the north."
One Time Pad encrypt it. Then One Time Pad encrypt the output of that with this:
"The quick brown fox jumped over the lazy dog."
The output of that can then be used as _an_alternate_One_Time_Pad_. Decrypting the cipher text with this bogus One Time Pad results in:
"The quick brown fox jumped over the lazy dog." Instead of decrypting the SAME cipher text with the REAL One Time Pad which would result in the real plain text of, "Attack the blah building at 9 from the north.".
This can be done for any number of alternate "plain texts" only limited by the number of characters in the text. This is why the One Time Pad is impossible to break if properly implemented with real noise (as opposed to any deterministically generated pseudo random "noise").
Here is a short demo, characters are encoded as ASCII and represented in brackets as the appropriate Hex values:
The intended recipient who hears the cipher text transmitted on the public channel, has the correct One Time Pad at his end, uses it and gets the real plain text message "KILL". The enemy who also captured that same cipher text, tortures the person who may or may not know the real One Time Pad, that poor soul gives them the alternate One Time Pad and the cipher text decrypts to the completely legible "live". This demo is short for demonstration purposes and to ease checking with a calculator, however this can be done with any size plain text.
Generally they try to capture a complete computer containing all the algos used for the steganography. That way they don't have to search for a needle in a haystack.
According to the FBI, they are aware that there are steganographic utilities which can fit on a single floppy, don't require installation and leave no remnants other than the files used to insert data with steganography techniques. Files which contain other more interesting data inserted with steganography are not much good to you if that inserted data were first encrypted in a strong manner. They will be hard to detect, since there should be no pattern in the inserted data (uniform distribution of what looks like noise, exactly where you might expect to find noise) and even if you could detect them (maybe you expect something other than uniform noise?), you still have the problem of de-encrypting data which could have been encrypted with any good algorithm and keys.
It's a bit like the code devices of WWII. It was always easier to capture a code machine than try to brute force the code itself.
Capturing a device or algorithm buys you little if that device or algorithm and usage (strong keys, one time usage of keys, etc) is cryptographically strong. Without the keys you will need to brute force, even if you do have the cipher machine. A good cipher is one which does not need to be secret. Capturing a device or algorithm is only really good at a minimum to align your brute force attacks or in the best case if that device or algorithm is weak then you can find a quicker way to attack the cipher texts.
Earlier today a client came to me, requesting that a FreeBSD 6.0 demo box be set up as a potential replacement for their current OpenBSD mail server. Indeed, 6.0 may be the release we have all been waiting for. The performance is vastly improved, and the stability is fantastic.
When I saw "Score:5, Interesting", I thought it was going to compare some performance metrics of 6.0 against earlier FreeBSD versions. That would have been interesting. Comparing FreeBSD with OpenBSD on performance is not interesting. Nobody who has used the three main free BSD's would think that FreeBSD 6.0 or NetBSD being faster than any version of OpenBSD would be interesting.
If I can get away with it (performance feasibility and money constraints), I would rather use OpenBSD and spend more money on faster hardware when it comes to internet facing hosts.
BTW, I love all the free BSD's, I intend to keep seeding FreeBSD 6.0 for the next couple of days and use FreeBSD on some of my workstations where performance really can matter to me most and security is a small issue. Just my opinion of course.
Life is about socializing, making friends, and sharing ideas.
I'd like to rephrase this to come into line with how I see lots of Uni life...
Uni life is about socializing, making friends, sharing ideas, having lots of sex, doing drugs, failing exams, dropping out, becoming artistic and then forever more claiming it all to be bullshit anyway because you don't have to go to Uni to have lots of sex and do drugs. The nearest pub will suffice.
Meanwhile... the nerds quietly go about equipping themselves with knowledge! Muhahahahahaaaaa....
I agree that that was bad advice. I am 33, have worked in IT for 10 years and electronics/telecommunications since 1989 before that. I don't actually have any degrees or qualifications outside of small courses (Novell, PABX programming, etc). I am almost completely self taught on the IT side and my knowledge seems to get me to some amazing places, but it is still highly fragmented. I often have to learn something new really fast to fill a gap which has suddenly become important.
I want to get a CS degree, simply to fill in any fundamentals which I may be lacking, so that I can have a more complete picture. Just because I often do things differently, faster and/or better does not mean that I did them the best way they could have been done. Education in IT should NEVER just end.
the crickets on this thread....who loves BSD! I still do!
You can hear the crickets, because many of the reasonable people who see the wonderful value in the BSD's, have left/. and are conversing in a positive "common goal" manner in mailing lists, etc.
The in fighting and dick measuring contests which often go on in here are unproductive and unpleasant./. is a urine soaked sand pit.
I love the three main free BSD's./. is still sometimes good for a heads-up though and I still sometimes get caught up in the worst of the bullshit.
Does anybody know if there is a Linux port of this RK? Or will it run on WINE? I would really love to have this RK on my Linux box. I think it's the only thing stopping me from using Linux on the desktop at the moment.
But there are so many Linux rootkits to choose from! Descisions descisions...
You think you have it bad? Spare a thought for us poor OpenBSD users!
In all seriousness, all those years of wearing Linux t-shirts just got me silly looks. But I often get stopped with comments about my OpenBSD shirts, usually by chicks and gay dudes.
Re:One of the most important things
on
OpenBSD 3.8 Released
·
· Score: 2, Informative
Performance is not an OpenBSD priority, but the interviews with OpenBSD developers that have been popping up the last couple of weeks seem to imply that the performance hit of the new malloc() is minimal.
Yes, because from memory, they have been working on it for years, specifically trying to get the performance hit down.
First thing I did was switch to a cheaper phone plan ($18.50/m of gouging from Telstra instead of $27.95 - had to specifically ask for the cheaper one and was told $27.95 was the cheapest available...) and put on ADSL (*not* Telstra).
I did the same. Most of my communications are through email and mobile, so I went with the $18.50 budget line rental and another DSL provider.
It is a pitty the wireless situation sucks, otherwise I could avoid the telstra copper wire tax altogether. I've tried Unwired and iBurst. Unwired sucked baddly no matter where I used it and at various altitudes in the Sydney CBD. iBurst was awesome for a while there, when I was actually getting 1Mbit/s regularly no matter where in the City and no matter what time. But now it too kinda sucks with wildly varying performance from alright to short periods of no connection at all.
While you're at it, why not let First4Internet know that you hate them and hope they burn in Hell for writing malware like this. A few thousand emails will do wonders for these jerks.
And while everyone is at that, why not consider moving the hell away from Microsoft? The software company which is "Insecure by default! Two weeks without a remote hole in the default install!". The company whose ridiculous defaults allow such security problems in the name of ease of use.
now i may be wring in how DRM works but wouldnt making a dupe of the disk in toast/converting to mp3 then burning to a new disk or something along those lines completly override any sort protection at all? especially when some of the ppl that actually buy the cd have macs, in which stuff like that for windows wont work?
Yep. I have never come across a DRM "protected" audio CD which was not very simple to get around. Copying or ripping it on anything that was not Windows was all that was needed. It only takes ONE person to do this and then put the mp3's up for download and ALL of that DRM effort and pissing off real customers was for NOTHING.
Even if they could make a CD DRM mechanism which worked, at the end of the day the CD must produce music at an analog output and it could be copied there as an absolute worst case.
The Copy Protection solution is really simple. Make the works affordable and very easy to obtain for the majority of people and they will buy them. There will always be at least a minority who will illegally copy them anywhere from single copies to bulk copies to be sold. Investigate and prosecute the bulk copiers. As long as the big corporations are hated, many people will continue to feel like it is ok to copy the works they sell. Putting rootkits on audio CD's, which are installed automatically without prompting, is a great way to keep people hating you and making MORE people hate you. Considering that many of the people who will be "infected" with these rootkits, will actually be genuine paying Sony customers.
Slashdot Mirror
If you have to rely on the encryption, then the steganography is useless. The cops will capture your key store, and begin brute forcing the password to that store.
The entire point of the steganography is that it's so obscure that it's unlikely to be noticed in the first place. i.e. An extreme form of security through obscurity.
AKAImBatman I think I might now know where your confusion lies.
It seems to me that you don't understand what is encrypted?
You DON'T insert cleartext into a carrier file with steganography and then encrypt that whole file.
You DO encrypt the cleartext to ciphertext and THEN insert THAT into the carrier file with steganography.
The point here, is that many files contain an element of noise. The ciphertext you just created also should look just like noise. You replace the real noise of the carrier file, with the pseudo noise of the ciphertext. If the noise within the carrier floor does not constitute uniform white noise, then you could distribute the ciphertext (which SHOULD look like white noise), pseudo randomly througout the original noise of the carrier file, so as to not appreciably change the "colour" of the noise.
This is a symbiotic relationship (if people don't mind me applying a biology term to computing). The crypto makes the message hard to decipher and also makes the message look like noise and thus fits in well where noise is expected to be. On the other end, the steganography can exploit this noise like quality by having the ciphertext "noise" replace noise which is expected to be found in many file types and thus hide the fact that there is even a message there at all.
Stego is not as good without crypto and crypto is protected from scrutiny by the stego. Together when done properly, they combine to be greater than the sum of their parts.
BTW, please start thinking for yourself and give up the "security through obscurity" cult chant. Various levels of security can often be gained out of obscurity. Just because some forms are downright terrible does not make them all terrible. You rely on "security through obscurity" and you obviously don't even know it.
By your definition of security through obscurity, nearly every data security method is exactly that. Encryption keys are only useful if you OBSCURE them from the attacker. Usernames and passwords are only useful if they are OBSCURED.
fliplap, thank you. It is nice to see some well thought out reason around here. I have been trying to tell people this for years, yet few people seem to think for themselves and instead vomit out that crusty old "security through obscurity" chestnut over and over like it is a bloody holy commandment from some crazy new religion.
Steganography is more useful when combined with encryption, and encryption is more useful when combined with steganography.
Amen to that! It is amazing how some people will attack a concept because they can think of some implementations which could be bad.
AKAImBatman, please, give up. This is complete and utter nonsense. A properly implemented strong crypto scheme will create output which should be indescernible from uniform white noise. Any crypto scheme which outputs something that is coloured in any way, as in showing some pattern... is BROKEN.
This is a most fundamental feature of strong crypto schemes. Don't believe me? Would you take Bruce Schneier's word for it?
The reason for this, is that real random data should not be compressible by any appreciable amount, nor should cipher text. Bruce cites what he considers to be appreciable in this context as being 1-2%. The purpose of encrypting data is to hide detail or patterns. And that is exactly what good crypto algorithms do. They hide detail, patterns and your "probability aspects".
Before you come back with a response about the fact that crypto is often used with compression, you should realise that the proper procedure in this regard is to compress first and then encrypt. This is good for a few reasons. Firstly, compressing after encrypting is silly, because the gains in compression should be very small or even negative (because the patterns have been REMOVED). Secondly, as Bruce states, "cryptanalysis relies on exploiting redundancies in the plaintext; compressing a file before encryption reduces these redundancies".
Again, it's the encryption that's making the difference. NOT the steganography.
It is a bit hard to attack the encryption when it is hidden amongst thousands of files which have noise floors which look no different to the cipher text. You cannot attack that which you cannot find.
I don't think you really understand just how effective strong encryption can be when combined with a strong steganography process. The stego hides the messages existence and the crypto obscures the message. If you don't encrypt, then stego is useless and conversely if you don't stego, then you flag the target (because it is quite obviously an encrypted message, based on the statistical spread of data alone).
BUT just like you might not be able to encrypted data but you know its encrypted (true encryption is a statiscally even distribution of all characters look it up) you can scan a file and tell if it has been altered by steganography (i think, but dont quote me, because its more random then an image should be) and once you know which are encrypted you can find the algorithim and brute force it.
Yes. Shaped noise versus uniform noise. Or put another way, pink (or maybe green?) noise versus white noise. Especially when the shape of the "pink" noise is expected to have an element of consistency from a given camera for example, or particular audio recording equipment (also there is the 50Hz, 60Hz, etc hum from mains power that can also be expected among other signals we humans might commonly consider "noise"). However, a good crypto algorithm will not create output which is suggestive of the algorithms use. Triple Des cipher text should not look different statistically from AES cipher text, for example.
BTW, I am using the reference here to "Pink" noise loosely merely to seperate from white noise. I do not yet know if I would expect digitized data to exhibit actual pink noise.
even with completly knowledge of the algorithm it should be computationally infeasible to determine a secret message is implanted in the cover text.
That's the most rediculous thing I've ever heard.
If the secret message is first encrypted with a strong algo and key, the output should be indescernible from random noise. If you then insert this "random noise" cipher text into areas of a file where a component of noise is expected to be (Least Significant Bits of a digitized analog signal ie. scanned pictures, recorded audio for example) then it is quite possible to insert a secret message which absolutely cannot be detected. Which "random noise" is the real original random noise and which is the output from the strong crypto?
This assumes that the noise component in the digitized file is expected to have uniform noise. If however the noise component of the digitized file has shaped noise (non uniform), then the presence of uniform noise can alert the investigator that the expected shaped noise has probably been replaced. Regardless, even if they do detect this, if the "replacement noise" is that of a strong cipher text, then they still have the difficult battle of brute force decrypting which may be infeasible to do within a useful timeframe. Also, the "shape" of the original noise could be largely retained if it is interspersed with the secret message and the original noise constitutes enough of the total noise to retain the shape.
He is correct if the secret is encrypted well and inserted in appropriate places in an appropriate file. You could run your stego extracting script on thousands of files, find they all extract to random noise and not be able to determine the "interesting noise" (which holds the cipher text) from the real noise (which holds nothing).
As I have already seen you state elsewhere, encryption prevents a message from becoming known to people you want privacy from and steganography is supposed to hide the fact that a message is even there. Properly implemented, these two hand-in-hand allow both the avoidance of the message being broken in a timely manner and the avoidance of scrutiny. Effectively avoiding scrutiny can provide critical extra time required for your secrets to remain secret for as long as they need to be. It could even avoid scrutiny forever. It is hard to point incredibly powerful resources to a target when you can't find the target to begin with.
The problem is that torture doesn't get you the truth, it gets you exactly what the victim thinks you want to hear. An innocent being tortured will admit to anything to make it stop.
/. speak in absolutes?
Why do so many people at
Torture has been used for A VERY LONG TIME because... sometimes it works.
I think the fact that we keep "caputuring" all these "high ranking" al Queda people ... but still can't find Osama shows how ineffective torture is at getting real information out of prisoners.
This all comes down to the classic old "need to know" basis. If all those tortured terrorists don't need to know where Osama is, then they should never be informed of that info. They have their immediate trusted person(s) up and down the chain of command and the information passed between them is all they NEED to know.
I think it is silly to expect those terrorists to know where Osama is. I would imagine that only a handful of absolute die hard followers, ready to lay down their lives at any time, could possibly know. They are probably mentally and physically (pistol, poison, etc) prepared at all times to commit suicide to keep his whereabouts secret.
Just because torture does not always work on every person, does not mean it is always useless.
Wrong -- cut off another, connect the battery to the genitals, etc.
Because they can immediately test the answers, lying won't save you as it could in open-ended intelligence gathering.
The intended recipient who hears the cipher text transmitted on the public channel, has the correct One Time Pad at his end, uses it and gets the real plain text message "KILL". The enemy who also captured that same cipher text, tortures the person who may or may not know the real One Time Pad, that poor soul gives them the alternate One Time Pad and the cipher text decrypts to the completely legible "live". This demo is short for demonstration purposes and to ease checking with a calculator, however this can be done with any size plain text.I can take this text:
"Attack the blah building at 9 from the north."
One Time Pad encrypt it. Then One Time Pad encrypt the output of that with this:
"The quick brown fox jumped over the lazy dog."
The output of that can then be used as _an_alternate_One_Time_Pad_. Decrypting the cipher text with this bogus One Time Pad results in:
"The quick brown fox jumped over the lazy dog." Instead of decrypting the SAME cipher text with the REAL One Time Pad which would result in the real plain text of, "Attack the blah building at 9 from the north.".
This can be done for any number of alternate "plain texts" only limited by the number of characters in the text. This is why the One Time Pad is impossible to break if properly implemented with real noise (as opposed to any deterministically generated pseudo random "noise").
Here is a short demo, characters are encoded as ASCII and represented in brackets as the appropriate Hex values:
Generally they try to capture a complete computer containing all the algos used for the steganography. That way they don't have to search for a needle in a haystack.
According to the FBI, they are aware that there are steganographic utilities which can fit on a single floppy, don't require installation and leave no remnants other than the files used to insert data with steganography techniques. Files which contain other more interesting data inserted with steganography are not much good to you if that inserted data were first encrypted in a strong manner. They will be hard to detect, since there should be no pattern in the inserted data (uniform distribution of what looks like noise, exactly where you might expect to find noise) and even if you could detect them (maybe you expect something other than uniform noise?), you still have the problem of de-encrypting data which could have been encrypted with any good algorithm and keys.
It's a bit like the code devices of WWII. It was always easier to capture a code machine than try to brute force the code itself.
Capturing a device or algorithm buys you little if that device or algorithm and usage (strong keys, one time usage of keys, etc) is cryptographically strong. Without the keys you will need to brute force, even if you do have the cipher machine. A good cipher is one which does not need to be secret. Capturing a device or algorithm is only really good at a minimum to align your brute force attacks or in the best case if that device or algorithm is weak then you can find a quicker way to attack the cipher texts.
Earlier today a client came to me, requesting that a FreeBSD 6.0 demo box be set up as a potential replacement for their current OpenBSD mail server. Indeed, 6.0 may be the release we have all been waiting for. The performance is vastly improved, and the stability is fantastic.
When I saw "Score:5, Interesting", I thought it was going to compare some performance metrics of 6.0 against earlier FreeBSD versions. That would have been interesting. Comparing FreeBSD with OpenBSD on performance is not interesting. Nobody who has used the three main free BSD's would think that FreeBSD 6.0 or NetBSD being faster than any version of OpenBSD would be interesting.
If I can get away with it (performance feasibility and money constraints), I would rather use OpenBSD and spend more money on faster hardware when it comes to internet facing hosts.
BTW, I love all the free BSD's, I intend to keep seeding FreeBSD 6.0 for the next couple of days and use FreeBSD on some of my workstations where performance really can matter to me most and security is a small issue. Just my opinion of course.
Life is about socializing, making friends, and sharing ideas.
I'd like to rephrase this to come into line with how I see lots of Uni life...
Uni life is about socializing, making friends, sharing ideas, having lots of sex, doing drugs, failing exams, dropping out, becoming artistic and then forever more claiming it all to be bullshit anyway because you don't have to go to Uni to have lots of sex and do drugs. The nearest pub will suffice.
Meanwhile... the nerds quietly go about equipping themselves with knowledge! Muhahahahahaaaaa....
This is really, really bad advice.
I agree that that was bad advice. I am 33, have worked in IT for 10 years and electronics/telecommunications since 1989 before that. I don't actually have any degrees or qualifications outside of small courses (Novell, PABX programming, etc). I am almost completely self taught on the IT side and my knowledge seems to get me to some amazing places, but it is still highly fragmented. I often have to learn something new really fast to fill a gap which has suddenly become important.
I want to get a CS degree, simply to fill in any fundamentals which I may be lacking, so that I can have a more complete picture. Just because I often do things differently, faster and/or better does not mean that I did them the best way they could have been done. Education in IT should NEVER just end.
the crickets on this thread....who loves BSD! I still do!
/. and are conversing in a positive "common goal" manner in mailing lists, etc.
/. is a urine soaked sand pit.
/. is still sometimes good for a heads-up though and I still sometimes get caught up in the worst of the bullshit.
You can hear the crickets, because many of the reasonable people who see the wonderful value in the BSD's, have left
The in fighting and dick measuring contests which often go on in here are unproductive and unpleasant.
I love the three main free BSD's.
Does anybody know if there is a Linux port of this RK? Or will it run on WINE? I would really love to have this RK on my Linux box. I think it's the only thing stopping me from using Linux on the desktop at the moment.
But there are so many Linux rootkits to choose from! Descisions descisions...
You think you have it bad? Spare a thought for us poor OpenBSD users!
Chicks dig OpenBSD
In all seriousness, all those years of wearing Linux t-shirts just got me silly looks. But I often get stopped with comments about my OpenBSD shirts, usually by chicks and gay dudes.
Performance is not an OpenBSD priority, but the interviews with
OpenBSD developers that have been popping up the last couple of
weeks seem to imply that the performance hit of the new malloc()
is minimal.
Yes, because from memory, they have been working on it for years, specifically trying to get the performance hit down.
First thing I did was switch to a cheaper phone plan ($18.50/m of gouging from Telstra instead of $27.95 - had to specifically ask for the cheaper one and was told $27.95 was the cheapest available...) and put on ADSL (*not* Telstra).
I did the same. Most of my communications are through email and mobile, so I went with the $18.50 budget line rental and another DSL provider.
It is a pitty the wireless situation sucks, otherwise I could avoid the telstra copper wire tax altogether. I've tried Unwired and iBurst. Unwired sucked baddly no matter where I used it and at various altitudes in the Sydney CBD. iBurst was awesome for a while there, when I was actually getting 1Mbit/s regularly no matter where in the City and no matter what time. But now it too kinda sucks with wildly varying performance from alright to short periods of no connection at all.
Updates from Apple have been retracted in the past, since they cause more problems than they fixed.
That should probably read:
Some updates from Apple have been retracted in the past, since they caused more problems than they fixed.
Reading it a second time, it sounds like I'm stating this about many updates. Which I'm not.
hall we define "non-application software"?
The bill would actually need a definition of "application software" so that anything that doesn't meet that definition would be automatically covered.
And we might have to watch out for the difference between:
"non-application software"
and
"non application-software"
My mothers hair-curling iron might be considered non application-software.
; )
While you're at it, why not let First4Internet know that you hate them and hope they burn in Hell for writing malware like this. A few thousand emails will do wonders for these jerks.
And while everyone is at that, why not consider moving the hell away from Microsoft? The software company which is "Insecure by default! Two weeks without a remote hole in the default install!". The company whose ridiculous defaults allow such security problems in the name of ease of use.
now i may be wring in how DRM works but wouldnt making a dupe of the disk in toast/converting to mp3 then burning to a new disk or something along those lines completly override any sort protection at all? especially when some of the ppl that actually buy the cd have macs, in which stuff like that for windows wont work?
Yep. I have never come across a DRM "protected" audio CD which was not very simple to get around. Copying or ripping it on anything that was not Windows was all that was needed. It only takes ONE person to do this and then put the mp3's up for download and ALL of that DRM effort and pissing off real customers was for NOTHING.
Even if they could make a CD DRM mechanism which worked, at the end of the day the CD must produce music at an analog output and it could be copied there as an absolute worst case.
The Copy Protection solution is really simple. Make the works affordable and very easy to obtain for the majority of people and they will buy them. There will always be at least a minority who will illegally copy them anywhere from single copies to bulk copies to be sold. Investigate and prosecute the bulk copiers. As long as the big corporations are hated, many people will continue to feel like it is ok to copy the works they sell. Putting rootkits on audio CD's, which are installed automatically without prompting, is a great way to keep people hating you and making MORE people hate you. Considering that many of the people who will be "infected" with these rootkits, will actually be genuine paying Sony customers.
Besides, if Sony didn't know they were grossly negligent.
Yes, it is Sony's responsibility to know what they are shipping.
Years ago, Ron and Valerie Taylor measured the inside temperature of a shark and found it to be a few degrees warmer than the water it was in.
Treat. When was the last time a OS X update broke my machine?
We don't know, it's your machine. You tell us.
Updates from Apple have been retracted in the past, since they cause more problems than they fixed.
I prefer to wait a few days, unless I really have to update.