There's a whole music scene out there would love this. What would YA DJ pay to have a multi-tracked version of his favorites? Imagine the beat-mixing that could happen.
One of the things the article says is that music, once digitized, becomes malleable (''liquid''). This isn't yet true, except in the crudest sense.
The current music formats (mp3, ogg, wma, etc.) are finished products. You can't add your own lyrics to an mp3, or do karaoke to a rip of (say) B.Spears latest.
If there was a digital format that was multi-tracked, i.e. the form in which the producer mixes music, then you'd see people take the lyrics of one tune, the bass from another, etc., and create something other. But we don't have that, and what's more, the way things are going, we probably never will.
In the SE Linux built against 2.2, PSIDS were stored at the inode level, which meant that a security resolution below the filesystem level was only possible using ext2.
The latest versions use the Linux Security Module (lsm), like LIDS, that hooks in at the VFS layer. so far, ext2 and ReiserFS have been confirmed to work. The only requirement the fs is persistent inode labelling(?-my terminology is off-?), but (IIRC) ext3 and xfs have also been tested.
If you've read The Hacker Crackdown you'll know that part of their job is to trawl through all the threats made on the presidents/VPs' life - visiting mental institutes, crims in jail, and even the people who post threats on public forums.
The real squalor in Service work is drudgery such as "the quarterlies," traipsing out four times a year, year in, year out, to interview the various pathetic wretches, many of them in prisons and asylums, who have seen fit to threaten the President's life
...
If you ever state that you intend to kill the President, the Secret Service will want to know and record who you are, where you are, what you are, and what you're up to. If you're a serious threat - if you're officially considered "of protective interest" - then the Secret Service may well keep tabs on you for the rest of your natural life.
So it was nothing personal, just doing their job. Understand I'm not making judgments on you, them, their job, your post...
SDMI is about water-marking, and MP3 players (and memory sticks, etc.) refusing to do certain things with SDMI-watermarked music.
The reason that it's difficult to find MP3 players that will cat mp3 > hd[a-z] is the court case between Rio (one of the first MP3 player manufacturers) and the RIAA.
The RIAA alleged that because the Rio allowed you to copy music from PC to PC via the flash, it was guilty of contributory copyright infringement (or something).
Rio (IIRC) either lost the case, or settled out of court to not allow player > HD shifting of mp3s. Most of the other manufacturers took this as a warning sign, and now they don't allow player>HD copying either.
If you're interested in an HD-based player, this "Personal MP3 Jukebox" comes in 10, 20 and (I think) 30 gig models, <gloat>they have fantastic sound, open API's, easter-eggs(minesweeper:-) in the firmware and I haven't had any problems with mine</gloat>, other than the fact that it looks like it was made in Russia.
I think the firmware supports uploading of MP3's, but it's only actually implimented in un-official software (pjbExploder, I think), which is functional enough - in windows.
Um. HDCP is actually a standard being pushed by Intel, among others. It's the standard protection for DVI, which is used for digital cameras, etc. IIRC, they're also pushing it to be the standard video IO for PCs and as well as set-top boxes, there was a big thing on/. (here) about it when the HDCP details were first leaked. So it's about more than digiTV.
...is the moon. Now, IIRC, most of the problems with getting a fusion reactor (smashing atoms together) to work are solved by using Helium-3, He-3. But it's rare enough that minute quantities are sold by Us.Gov at fantastically high prices - they get it from old nuclear bombs, because a component (tritium gas) decays into He-3 (tritium has a half-life of aprox. 13 years).
The surface of the moon is rich in He-3.
To hear some tell it, the answer to all our energy problems is strip-mining the surface of the moon...
I think we can thank our lucky stars that MS wasn't at all involved in the hardware side of things:-)
To elaborate, when the first IBM PC came out, there was a choice of some UNIX-alike, which was bundled at price+x, and there was DOS, which was at price+x-y, where y was enough to make most people choose DOS. On top of that, MS courted developers, and (I think) ended up with the Lotus 1-2-3 spreadsheet app.
You're right - hypothetically, other companies could have taken the place of MS - but they didn't:-)
[BillG said:]
"Really, the reason you see open source there at all is because we came in and said there should be a platform that's identical with millions and millions of machines,"
So wat he's saying is that the mass adoption of their inflexible software has driven people to create open products that will meet their needs, or am I misinterpreting him ?;)
Yes, you are misinterpreting him. What he is referring to is the wide availability of standards-based hardware due to the Microsoft-Intel alliance that, like it or not, brought computing out of the hobbyist and into the business world. They accomplished this despite their crappy software (compare: Macintosh), and probably because IBM fudged the attempted hardware-monopoly thing.
The emergence of Linux as a (cool)UNIX-like OS that runs on consumer hardware then lead to the explosion of interest in all things Open Source. Of course, the FSF and the GPL was around way before Open Source, so Gates knows his terminology here.
So, despite the contempt people have for Microsoft, you have them (and Intel, and IBM(for fucking up)) to thank for the cheap (relatively speaking) x86 hardware that Linux runs so happily on.
Bingo. I tried it on the MS DRM demonstrations (specifically, the two-play limited one) and it didn't do anything - either the MS demos are version one, or it's broken. The error message is:
C:\WINDOWS\Desktop\FreeMe>FreeMe -v OhNo_DRM.wma
Found DRMv2 header object.
Found KID (EBqWe20fOki1LarX5Whk/Q==)
Found DRMv1 header object.
Starting to look for license.
License file full path: C:\WINDOWS\All Users\DRM\drmv2.lic
BlackBox library to use: BlackBox.dll
Keystore to use: C:\WINDOWS\All Users\DRM\v2ks.bla
Created BlackBox instance - extracting key pairs
Public key 1 x: 617957d5a0753d597ddea298a29f6ed9c62fdb2d
Public key 1 y: 152334862ad65d4a3a44d1abbfe0b10330bd9e74
Private key 1: 056e8dbe98aa3ecac820f624917cd7892724104a
Checking license with PUBKEY 2ab1612cdc32afd8136ca30e03e432b5aa61d49d
Checking license with PUBKEY 2ab1612cdc32afd8136ca30e03e432b5aa61d49d
Checking license with PUBKEY 2ab1612cdc32afd8136ca30e03e432b5aa61d49d
Couldn't find a valid license for this content.
It looks like he might have hard-coded $WINDIR\All users\DRM instead of $WINDIR\Profiles\$USER\$DRM_PATH\, which would be a pretty annoying mistake if everything else is correct.
IIRC (assumming the technical documentation he released is correct), MPlayer spawns indivualised versions of blackbox.dll, and in this case, he would be looking at the untouched version, not the one with the license. (and s/he said he tested it on win98 - probably not network configured).
If this is a hoax, in which case/., TheReg, Cryptome etc. would look pretty fuckin' stupid, then x^n geeks ran an untrusted executable posted anonymously on USENET - including me...
There are other alternatives - maybe he's not as cluefull as he sounds, and he'd got his hands on some demo app or something.
The more Microsoft makes it's own crypto, the higher the chances the crypto will be cracked.
Microsoft didn't use their own crypto. Read Technical - they used DES, RC4, SHA-1, and ECC, all tried and tested algorithms, although we don't know about their implimentations.
The only 'innovations' they had were a bad MAC algorithm and a broken BASE64 implimentation.
That said, it doesn't matter what crypto they use. It's being implimented on so-called "trusted" software, on an untrusted OS using untrusted hardware in an untrusted environment, with key material in the same location as the ciphertext. A recipe for disaster.
OTOH, s/crypto/cryptosystems, and you're makin' sense. The closed culture (i.e. "you customer, me sales") isn't suited to cryptosystem or cipher design.
Even Microsoft doesn't trust Microsoft for protocol design - which is why they used Kerberos.
...comparatively speaking. For those of you who didn't read it, one of their objections is that while anyone involved in making the standard might potentially be forced to declare RF licensing, someone who keeps quiet during the standard's formulation but owns a patent on essential parts of the standard, can license under RAND or whatever else, as they didn't take part in the process.
While that is a problem, it doesn't negate the idea of RF. There were three other objections - but they're half legalese, and IANAL...:-)
The people who found the.IDA expoit (eEye security) told MS, and waited until a patch was available before making the press release.
Not only that, but Microsoft thanked eEye in their own press release.
Not only that, but it has been proven beyond all doubt that Code Red, + CRII were based on old exploit code, NOT eEye sample code.
Not only that but the old exploit code that Code Red etc. re-hashed, exploited a hole that was fixed by MS in the traditional manner, i.e. with no exploit sample code published, etc. If the original exploit code that Code Red built on was made public in the same way as the.IDA vulnerability was, the f**kin' thing would never have happened, because every competent IDS system out there would have caught Code Red before it even got off the ground.
The whole thing makes me sick. I can't believe that after Microsoft blitzing^W attempting to blitz the media with it's "renewed security efforts" that they let this slip past marketing. If this is what happened, then before they can even think about 'locking down' IIS, they need to examine their own attitude, and consider abandoning the tried-and-tested-and-FAILED 'security through obscurity' route.
Crimony. Writing viruses is not a crime. It is a crime to knowingly propagate a virus, and destroy other people's data.
Anyone can tell you that most cutting edge viruses never see the wild, they just get sent straight to the AV companies. Of the enormous lists they impress people with, maybe twenty percent or less have been found in the wild. How do you think companies like Symantec develop software to detect polymorphic viruses(polymorphic != encrypting) without studying them, and their evolutions?
In addition to Carnage4Life's comments, I should point out that the first SELinux release was a direct patch.
It was presented at a Kernel summit (I can't remember which) and one of the suggestions made was that the various people who were interested in increasing the security of Linux get together and work on a common set of hooks for SELinux, LIDS, etc. The hooks are the result of that.
Actually, a quick google
returns an interesting point - what if you have partially encrypted data seized and the clear-text used againt you? In the K.M trial it was argued that because the US.gov couldn't access them, neither should Mitnick be able to.
The US.gov's argument (which is admittedly scaremongering) is that they could be plans for bringing down the power grid. The defence argued that surrendering the key would violate the Fifth (self incrimination), and that it could aid defense.
A legal bear-trap, I think, but the prosecution is going to have to come up with better answers in future:-)
The official said the e-mails were in English and Arabic, that there were hundreds of communications, and the e-mails were not just limited to the United States. The hijackers did not use encryption techniques, the official said.
The whole encryption thing is opportunist scaremongering. People will communicate in secret even if ROT13 is outlawed. For example: "I'm going to the mall, we need beer" where "mall" = "airport" and "beer" = "identification".
The bandwith belongs to those who pay for it and that is the customer
The customer doesn't pay for the bandwidth, unless the customer has hired a leased line. The customer pays for the services of the ISP. And in most cases, when it comes to DSL, the ISP undersubscribes on bandwidth, and banks on the vast majority of users not downloading ISO's form ftp sites as a nightly cron job:-)
Here is a significant innovation which was created in hopes that it would be protectable and thus profitable.
They said:
The patent covers real-time interrupt handling using a software emulation layer for interrupt masking, so that interrupts can be prioritized.
There is significant prior art for this.
(Emphasis mine). It is clear even to me that the patent, of which the abstract is:
A general purpose computer operating system is run using a real time operating system. A real time operating system is provided for running real time tasks. A general purpose operating system is provided as one of the real time tasks. The general purpose operating system is preempted as needed for the real time tasks and is prevented from blocking preemption of the non-real time tasks.
, and bearing in mind that the patent was granted on November 30, 1999, it seems that it is a 'one-click' patent.
IHBT, IHL, bla bla bla, I've had a horrible day and I'm going to bed.
It's not your field. But then it's not mine either:-) But...
Person A logs into the client, using a username/password pair. The client then generates an RSA keypair, using hashes of the username and the password as seeds for the random number generator.
I assume you add a nonce/timestamp into your PRNG seed. Otherwise you'll be using the same seed each time for each user. Bad. Maybe confusing 'random' with 'unpredictable'? Or does the password change over time?
The client then contacts a key exchange server. snip
Except as the client doesn't have knowledge of the server public key (or if it does, it's not said here), the protocol is vulnerable to a man-in-the-middle attack from the word go. All this stops when the Kerberos server gets involved, but it's an effective service denial attack, as the client/server never get to exchange key material.
You are (if I've got this right) basically generating another key pair for key exchange (see below). Except that this time it's the server doing it, so you're trusting the server, and all the client has demonstrated (in terms of trust) is the ability to create a key pair. How does the server confirm the key-pair<->user match?
This establishes the link between the client and the server.
But you've already done this. Now, however, the server has the client private key, and you have to trust the server not to misuse it and not to get compromised, whereas before you were trusting the network to point the client at the server and not at a malicous proxy:-)
Each then generates a secret key, using one of a selection of algorithms. (I used Serpent and Rijndael). The secret keys are then exchanged, using the public keys.
The key's are for the Serpent/Rijndael ciphers? Or Serpent/Rijndael is used to generate the keys? Excuse my lack of clue:-)
The client then uses the original username and password to connect to a Kerberos server, for a ticket.
It would seem in this situation, that having brought a Kerberos server into the picture, the previous messages were a mere formality. I take it they were intended to secure the pipeline between the client and the server, but as I said above, you can have an MITM on the server as the client has no foreknowledge of the servers' public key.
I take it that refreshing the key material/key-exchange key pair regularly is to limit damage if anyone discovers them.
The reason for this amazingly convoluted system? I wanted a system that could run on an untrusted network, with an untrusted client AND an untrusted server.
Unless I'm wrong, you're trusting the client to generate the initial key pair. You're trusting the server to generate the key pair used to exchange keying material, and you're trusting the transport not to MITM the server in the second paragraph.
The challange was to devise a system that provided sufficient checks that a compromise at ANY point would not yield useful information.
Excluding the Kerberos server:-) And assuming that the server doesn't retain the private key it generated for the client.
In practice, that's very hard to do. Compromise the database, and you have the data. There's not a lot you can do about that. Compromise the front-end server, and you can mimic anything. Again, there's not a lot you can do to stop that.
I think that someone wishing to compromise your network would use other means than protocol/cipher attacks. I know I would:-) so your soak-off is effective in this case, because you have things like physical security, social engineering, etcetera which are an equally great threat to your network/data.
was to insist on all data, at both ends, being encrypted as far back in the system as possible, using keys with very limited lifespans.
I assume you also use other primitives (digests, etc.), along with some form of authentication before all this even starts, because while you cover interception pretty well, there's still invalidation, impersonation, and service denial, among other things.
The other question is, if you're on an untrusted netork, how can you rely on the availability of any parties? E.g. someone could SYN flood the kerberos server.
Wargaming and computer security, IMHO, are very closely related.
Which is probably because of the similarities of both fields to actual warfare (albeit guerilla warfare):-). Schneier has covered this recently
Excuse me I've missed something, misunderstood something, or made an assumption, seeing as it's not my field:-) Your comments appreciated.
IIRC, the main reason for the RIAA wanting the SDMI paper shushed is that one of the watermarking technologies (by Verance, I think) was already being used in DVD-Audio. The paper explained how to circumvent the watermark.
It's being done. Professor Felten (who wrote the paper on SDMI for an Information Hiding workshop) and the EFF are suing the RIAA. The RIAA are trying to get this dismissed, as it is exactly the kind of lawsuit they don't want. It's all very well to sue members of the "evil Open Source movement", or for that matter nasty hackers, but a professor at
MIT is a different matter.
One thing which stands out about this is that the FBI guys didn't get a wiretap order. This is obviously not a good thing. IIRC, they got a search warrant, and assummed (wrongly IMHO) that the warrant included the right to search his computer, which necesitated something like this.
However, which would you rather have: a targeted bug/sniffer program which can only be used selectively (as in this case), or carnivore, which has the capability of dredging through large amounts of email regardless of who it's from?
I would rather that the FBI stick with keyboard bugs and trojans (nap the sub7 guys and 'turn' them:-), than have them install something upstream of whoever they're targeting that has the capability to do far more damage to many people's privacy.
Slashdot Mirror
There's a whole music scene out there would love this. What would YA DJ pay to have a multi-tracked version of his favorites? Imagine the beat-mixing that could happen.
. /. buttons are different from k5's :-)
I also meant to say that even if there were such a format, none of the big 5 would use it for publishing music.
One of the things the article says is that music, once digitized, becomes malleable (''liquid''). This isn't yet true, except in the crudest sense.
The current music formats (mp3, ogg, wma, etc.) are finished products. You can't add your own lyrics to an mp3, or do karaoke to a rip of (say) B.Spears latest.
If there was a digital format that was multi-tracked, i.e. the form in which the producer mixes music, then you'd see people take the lyrics of one tune, the bass from another, etc., and create something other. But we don't have that, and what's more, the way things are going, we probably never will.
In the SE Linux built against 2.2, PSIDS were stored at the inode level, which meant that a security resolution below the filesystem level was only possible using ext2.
The latest versions use the Linux Security Module (lsm), like LIDS, that hooks in at the VFS layer. so far, ext2 and ReiserFS have been confirmed to work. The only requirement the fs is persistent inode labelling(?-my terminology is off-?), but (IIRC) ext3 and xfs have also been tested.
Check the mailing list for details.
Yup, that's the secret service.
If you've read The Hacker Crackdown you'll know that part of their job is to trawl through all the threats made on the presidents/VPs' life - visiting mental institutes, crims in jail, and even the people who post threats on public forums.
http://www.lysator.liu.se/etexts/hacker/lorder1.hTo quote:
So it was nothing personal, just doing their job. Understand I'm not making judgments on you, them, their job, your post...
SDMI is about water-marking, and MP3 players (and memory sticks, etc.) refusing to do certain things with SDMI-watermarked music.
The reason that it's difficult to find MP3 players that will cat mp3 > hd[a-z] is the court case between Rio (one of the first MP3 player manufacturers) and the RIAA.
The RIAA alleged that because the Rio allowed you to copy music from PC to PC via the flash, it was guilty of contributory copyright infringement (or something).
Rio (IIRC) either lost the case, or settled out of court to not allow player > HD shifting of mp3s. Most of the other manufacturers took this as a warning sign, and now they don't allow player>HD copying either.
If you're interested in an HD-based player, this "Personal MP3 Jukebox" comes in 10, 20 and (I think) 30 gig models, <gloat>they have fantastic sound, open API's, easter-eggs(minesweeper :-) in the firmware and I haven't had any problems with mine</gloat>, other than the fact that it looks like it was made in Russia.
I think the firmware supports uploading of MP3's, but it's only actually implimented in un-official software (pjbExploder, I think), which is functional enough - in windows.
Your choice, monkey :-)
Um. HDCP is actually a standard being pushed by Intel, among others. It's the standard protection for DVI, which is used for digital cameras, etc. IIRC, they're also pushing it to be the standard video IO for PCs and as well as set-top boxes, there was a big thing on /. (here) about it when the HDCP details were first leaked. So it's about more than digiTV.
...is the moon. Now, IIRC, most of the problems with getting a fusion reactor (smashing atoms together) to work are solved by using Helium-3, He-3. But it's rare enough that minute quantities are sold by Us.Gov at fantastically high prices - they get it from old nuclear bombs, because a component (tritium gas) decays into He-3 (tritium has a half-life of aprox. 13 years).
The surface of the moon is rich in He-3.
To hear some tell it, the answer to all our energy problems is strip-mining the surface of the moon...
I think we can thank our lucky stars that MS wasn't at all involved in the hardware side of things :-)
To elaborate, when the first IBM PC came out, there was a choice of some UNIX-alike, which was bundled at price+x, and there was DOS, which was at price+x-y, where y was enough to make most people choose DOS. On top of that, MS courted developers, and (I think) ended up with the Lotus 1-2-3 spreadsheet app.
You're right - hypothetically, other companies could have taken the place of MS - but they didn't :-)
You said:
Yes, you are misinterpreting him. What he is referring to is the wide availability of standards-based hardware due to the Microsoft-Intel alliance that, like it or not, brought computing out of the hobbyist and into the business world. They accomplished this despite their crappy software (compare: Macintosh), and probably because IBM fudged the attempted hardware-monopoly thing.
The emergence of Linux as a (cool)UNIX-like OS that runs on consumer hardware then lead to the explosion of interest in all things Open Source. Of course, the FSF and the GPL was around way before Open Source, so Gates knows his terminology here.
So, despite the contempt people have for Microsoft, you have them (and Intel, and IBM(for fucking up)) to thank for the cheap (relatively speaking) x86 hardware that Linux runs so happily on.
Take a look at In the beginning was the command line, by Neal Stephenson, for another take on the matter.
Bingo. I tried it on the MS DRM demonstrations (specifically, the two-play limited one) and it didn't do anything - either the MS demos are version one, or it's broken. The error message is:
C:\WINDOWS\Desktop\FreeMe>FreeMe -v OhNo_DRM.wmaFound DRMv2 header object.
Found KID (EBqWe20fOki1LarX5Whk/Q==)
Found DRMv1 header object.
Starting to look for license.
License file full path: C:\WINDOWS\All Users\DRM\drmv2.lic
BlackBox library to use: BlackBox.dll
Keystore to use: C:\WINDOWS\All Users\DRM\v2ks.bla
Created BlackBox instance - extracting key pairs
Public key 1 x: 617957d5a0753d597ddea298a29f6ed9c62fdb2d
Public key 1 y: 152334862ad65d4a3a44d1abbfe0b10330bd9e74
Private key 1: 056e8dbe98aa3ecac820f624917cd7892724104a
Checking license with PUBKEY 2ab1612cdc32afd8136ca30e03e432b5aa61d49d
Checking license with PUBKEY 2ab1612cdc32afd8136ca30e03e432b5aa61d49d
Checking license with PUBKEY 2ab1612cdc32afd8136ca30e03e432b5aa61d49d
Couldn't find a valid license for this content.
It looks like he might have hard-coded $WINDIR\All users\DRM instead of $WINDIR\Profiles\$USER\$DRM_PATH\, which would be a pretty annoying mistake if everything else is correct.
IIRC (assumming the technical documentation he released is correct), MPlayer spawns indivualised versions of blackbox.dll, and in this case, he would be looking at the untouched version, not the one with the license. (and s/he said he tested it on win98 - probably not network configured).
If this is a hoax, in which case /., TheReg, Cryptome etc. would look pretty fuckin' stupid, then x^n geeks ran an untrusted executable posted anonymously on USENET - including me...
There are other alternatives - maybe he's not as cluefull as he sounds, and he'd got his hands on some demo app or something.
Microsoft didn't use their own crypto. Read Technical - they used DES, RC4, SHA-1, and ECC, all tried and tested algorithms, although we don't know about their implimentations.
The only 'innovations' they had were a bad MAC algorithm and a broken BASE64 implimentation.
That said, it doesn't matter what crypto they use. It's being implimented on so-called "trusted" software, on an untrusted OS using untrusted hardware in an untrusted environment, with key material in the same location as the ciphertext. A recipe for disaster.
OTOH, s/crypto/cryptosystems, and you're makin' sense. The closed culture (i.e. "you customer, me sales") isn't suited to cryptosystem or cipher design.
Even Microsoft doesn't trust Microsoft for protocol design - which is why they used Kerberos.
...comparatively speaking. For those of you who didn't read it, one of their objections is that while anyone involved in making the standard might potentially be forced to declare RF licensing, someone who keeps quiet during the standard's formulation but owns a patent on essential parts of the standard, can license under RAND or whatever else, as they didn't take part in the process.
While that is a problem, it doesn't negate the idea of RF. There were three other objections - but they're half legalese, and IANAL... :-)
The people who found the .IDA expoit (eEye security) told MS, and waited until a patch was available before making the press release.
Not only that, but Microsoft thanked eEye in their own press release.
Not only that, but it has been proven beyond all doubt that Code Red, + CRII were based on old exploit code, NOT eEye sample code.
Not only that but the old exploit code that Code Red etc. re-hashed, exploited a hole that was fixed by MS in the traditional manner, i.e. with no exploit sample code published, etc. If the original exploit code that Code Red built on was made public in the same way as the .IDA vulnerability was, the f**kin' thing would never have happened, because every competent IDS system out there would have caught Code Red before it even got off the ground.
The whole thing makes me sick. I can't believe that after Microsoft blitzing^W attempting to blitz the media with it's "renewed security efforts" that they let this slip past marketing. If this is what happened, then before they can even think about 'locking down' IIS, they need to examine their own attitude, and consider abandoning the tried-and-tested-and-FAILED 'security through obscurity' route.
Crimony. Writing viruses is not a crime. It is a crime to knowingly propagate a virus, and destroy other people's data.
Anyone can tell you that most cutting edge viruses never see the wild, they just get sent straight to the AV companies. Of the enormous lists they impress people with, maybe twenty percent or less have been found in the wild. How do you think companies like Symantec develop software to detect polymorphic viruses(polymorphic != encrypting) without studying them, and their evolutions?
In addition to Carnage4Life's comments, I should point out that the first SELinux release was a direct patch.
It was presented at a Kernel summit (I can't remember which) and one of the suggestions made was that the various people who were interested in increasing the security of Linux get together and work on a common set of hooks for SELinux, LIDS, etc. The hooks are the result of that.
Actually, a quick google returns an interesting point - what if you have partially encrypted data seized and the clear-text used againt you? In the K.M trial it was argued that because the US.gov couldn't access them, neither should Mitnick be able to.
The US.gov's argument (which is admittedly scaremongering) is that they could be plans for bringing down the power grid. The defence argued that surrendering the key would violate the Fifth (self incrimination), and that it could aid defense.
A legal bear-trap, I think, but the prosecution is going to have to come up with better answers in future :-)
I agree that dropping packets to reduce bandwidth costs is unnaceptable, but I never said that it was :-)
Well, according to the FBI, no encryption was used. To quote:
The whole encryption thing is opportunist scaremongering. People will communicate in secret even if ROT13 is outlawed. For example: "I'm going to the mall, we need beer" where "mall" = "airport" and "beer" = "identification".
You said:
The customer doesn't pay for the bandwidth, unless the customer has hired a leased line. The customer pays for the services of the ISP. And in most cases, when it comes to DSL, the ISP undersubscribes on bandwidth, and banks on the vast majority of users not downloading ISO's form ftp sites as a nightly cron job :-)
Did you read the press release?
You said:
They said:
(Emphasis mine). It is clear even to me that the patent, of which the abstract is:
, and bearing in mind that the patent was granted on November 30, 1999, it seems that it is a 'one-click' patent.
IHBT, IHL, bla bla bla, I've had a horrible day and I'm going to bed.
It's not your field. But then it's not mine either :-) But...
I assume you add a nonce/timestamp into your PRNG seed. Otherwise you'll be using the same seed each time for each user. Bad. Maybe confusing 'random' with 'unpredictable'? Or does the password change over time?
Except as the client doesn't have knowledge of the server public key (or if it does, it's not said here), the protocol is vulnerable to a man-in-the-middle attack from the word go. All this stops when the Kerberos server gets involved, but it's an effective service denial attack, as the client/server never get to exchange key material.
You are (if I've got this right) basically generating another key pair for key exchange (see below). Except that this time it's the server doing it, so you're trusting the server, and all the client has demonstrated (in terms of trust) is the ability to create a key pair. How does the server confirm the key-pair<->user match?
But you've already done this. Now, however, the server has the client private key, and you have to trust the server not to misuse it and not to get compromised, whereas before you were trusting the network to point the client at the server and not at a malicous proxy :-)
The key's are for the Serpent/Rijndael ciphers? Or Serpent/Rijndael is used to generate the keys? Excuse my lack of clue :-)
It would seem in this situation, that having brought a Kerberos server into the picture, the previous messages were a mere formality. I take it they were intended to secure the pipeline between the client and the server, but as I said above, you can have an MITM on the server as the client has no foreknowledge of the servers' public key.
I take it that refreshing the key material/key-exchange key pair regularly is to limit damage if anyone discovers them.
Unless I'm wrong, you're trusting the client to generate the initial key pair. You're trusting the server to generate the key pair used to exchange keying material, and you're trusting the transport not to MITM the server in the second paragraph.
Excluding the Kerberos server :-) And assuming that the server doesn't retain the private key it generated for the client.
I think that someone wishing to compromise your network would use other means than protocol/cipher attacks. I know I would :-) so your soak-off is effective in this case, because you have things like physical security, social engineering, etcetera which are an equally great threat to your network/data.
I assume you also use other primitives (digests, etc.), along with some form of authentication before all this even starts, because while you cover interception pretty well, there's still invalidation, impersonation, and service denial, among other things.
The other question is, if you're on an untrusted netork, how can you rely on the availability of any parties? E.g. someone could SYN flood the kerberos server.
Which is probably because of the similarities of both fields to actual warfare (albeit guerilla warfare) :-). Schneier has covered this recently
Excuse me I've missed something, misunderstood something, or made an assumption, seeing as it's not my field :-) Your comments appreciated.
IIRC, the main reason for the RIAA wanting the SDMI paper shushed is that one of the watermarking technologies (by Verance, I think) was already being used in DVD-Audio. The paper explained how to circumvent the watermark.
It's being done. Professor Felten (who wrote the paper on SDMI for an Information Hiding workshop) and the EFF are suing the RIAA. The RIAA are trying to get this dismissed, as it is exactly the kind of lawsuit they don't want. It's all very well to sue members of the "evil Open Source movement", or for that matter nasty hackers, but a professor at MIT is a different matter.
One thing which stands out about this is that the FBI guys didn't get a wiretap order. This is obviously not a good thing. IIRC, they got a search warrant, and assummed (wrongly IMHO) that the warrant included the right to search his computer, which necesitated something like this.
However, which would you rather have: a targeted bug/sniffer program which can only be used selectively (as in this case), or carnivore, which has the capability of dredging through large amounts of email regardless of who it's from?
I would rather that the FBI stick with keyboard bugs and trojans (nap the sub7 guys and 'turn' them :-), than have them install something upstream of whoever they're targeting that has the capability to do far more damage to many people's privacy.