Re: The problem with Steganography
I wonder if stego users will have to choose between uncrackable encryption or undetectable data. I don't think so. Replacing the low-order bits of a picture with random noise (or an encrypted message) is silly - like you say, anyone can find it easily. But there is a certain amount of free entropy in a picture. And if you create a data stream to match its statistical properties, and you hide it there, no one's going to notice. Of course, this isn't easy to do - "matching statistical properties" isn't a simple closed problem. But I bet you could do fairly well in certain circumstances. For instance, Linux uses a strong random number when starting a TCP connections. I bet you can hide a few bits of data in there and no one will see it. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: The problem with Steganography
The basic notion of stego is that one replaces 'noise' in a document with the stego'ed information. Thus, a 'good' stego system must use a crypto strategy whose statistical properties mimic the noise properties of the carrying document. Our favorite off the shelf crypto algorithms do *not* have this property -- they are designed to generate output that looks statistically random. So, can't we detect the presence of stego'ed data by looking for 'noise' in the document that's *too* random? Yes, and no. There is no particular difficulty in altering the statistics of encrypted data to match whatever distribution is necessary for the noise. So there is no reason a priori to expect that stego'd data would be "too random". The real problem arises in constructing an accurate noise model. Whatever model is built can be matched, but there is always the worry that the model is not quite right. In particular, if the adversary can spend more to construct an accurate noise model than the steganographer, then he can detect the stego'd data because its statistics will differ in subtle ways from natural data. In these circumstances, it is prudent to assume that an adversary does have more money to spend than the person hiding the data. He may well be a large government agency or a private bureaucracy which is looking for illicit data. The attacker's budget will often be far bigger than that of the people who need to hide from him. All is not necessarily lost; it becomes a matter of sufficient accuracy for the purpose. In order to distinguish the stego data from natural data it may be necessary to acquire a considerable volume of messages. The stego noise model only needs to be accurate enough to make the data indistinguishable from noise for the specific volume of data being embedded. If this threshold is reached, then even if the attacker's model is better the stego can still succeed. The greater danger is a subtle but catastrophic failure of the noise model, as for example when a new statistical analysis is used which the steganographer did not consider, perhaps some kind of higher order correlation. The well funded attacker can afford to spend time searching for such statistics, and if he is lucky, the game may be over before it has begun. These considerations are the real art and science of steganography. Plunking data into LSBs is grade school stuff, analogous to ROT13 as a cipher. True steganography goes far beyond such elementary substitutions.
[Fwd: 1/28/00 C.S. Colloquium]
--- begin forwarded text Date: Tue, 25 Jan 2000 18:05:39 -0500 From: Richard Lethin [EMAIL PROTECTED] Organization: Reservoir Labs, Inc. To: [EMAIL PROTECTED] Subject: [Fwd: 1/28/00 C.S. Colloquium] Sender: [EMAIL PROTECTED] Reply-To: Richard Lethin [EMAIL PROTECTED] -- Reservoir Labs, Inc. 628 Broadway, Suite 502 New York, NY 10012 212-780-0527 http://www.reservoir.com Return-Path: [EMAIL PROTECTED] Received: from cs.nyu.edu (CS.NYU.EDU [128.122.80.78]) by deer-park.reservoir.com (8.9.0/8.9.0) with ESMTP id PAA07926 for [EMAIL PROTECTED]; Tue, 25 Jan 2000 15:15:54 -0500 (EST) Received: (from majordom@localhost) by cs.nyu.edu (8.9.1/8.9.1) id OAA22855 for colloq-outgoing; Tue, 25 Jan 2000 14:45:47 -0500 (EST) X-Authentication-Warning: cs.nyu.edu: majordom set sender to [EMAIL PROTECTED] using -f Received: from dept.cs.nyu.edu (dept.cs.nyu.edu [128.122.80.31]) by cs.nyu.edu (8.9.1/8.9.1) with ESMTP id OAA22851 for [EMAIL PROTECTED]; Tue, 25 Jan 2000 14:45:45 -0500 (EST) Received: (from amico@localhost) by dept.cs.nyu.edu (8.9.1/8.9.1) id OAA08478 for colloq@cs; Tue, 25 Jan 2000 14:45:45 -0500 (EST) Date: Tue, 25 Jan 2000 14:45:45 -0500 (EST) From: Rosemary Amico [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: 1/28/00 C.S. Colloquium Sender: [EMAIL PROTECTED] Precedence: bulk X-Mozilla-Status2: == Department of Computer Science Courant Institute New York University DEPARTMENTAL COLLOQUIUM Allan Gottlieb New York University Intermemory The Intermemory project proposes an autonomous, world wide distributed system that will maintain information archivally and will offer extremely high availability without the storage costs of a large number of mirror sites. Information is dispersed in a redundant fashion so that only if an improbably large number of systems are down can the data not be retrieved. With one set of parameter values, an availability level comparable to more than 500 mirror sites can be obtained with a storage cost that is less than just 5 mirrors. If one assumes that the long standing exponential growth in bytes/dollar and hence bytes/system will continue, it can be shown that a contribution of storage to the system for a finite time period can entitle to the contributor to permanent ownership of (a smaller amount of) system storage. When exponential increases end, the guarantees weaken but are still attractive. The Intermemory project exposes important questions in areas as diverse as cryptography and DNS (domain name service). Recently the project has begun investigating intramemories, that is storage accessible throughout a smaller domain. Applications range from a single lan to a corporate-wide database. A major difference is that security is less of a concern since hosts are under a single administrative domain. Lowering the protection requirements will result in higher performance. When the system is restricted to a single lan, further simplifications are available and much higher performance is expected. Our implementations to date have all required that the data to be stored is write-once, i.e. immutable. We continue to examine the possiblility of full read-write support and believe that a system based on a form of ``session semantics'' in which all updates to a subtree are applied during a session of limited duration looks promising. Friday, January 28, 2000 11:30 a.m. - 12:30 p.m. Room 101 Warren Weaver Hall 251 Mercer Street New York, NY 10012-1185 Refreshments will be served in the Grumman Lounge from 11:00 - 11:30 a.m. in 13th floor of Warren Weaver Hall. Host: Allan Gottlieb, ([EMAIL PROTECTED]) (212) 998-3344 Directions: http://www.cs.nyu.edu/directions/new_wsq-campus.html Colloquium Information: http://www.cs.nyu.edu/calendar2.html == --- end forwarded text - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Re: legal status of RC4?
At 10:45 AM 1/25/00 , Eric Murray wrote: Real-To: Eric Murray [EMAIL PROTECTED] Does anyone know the legal status of RC4 in the US? I know that a cipher purporting to be RC4 was published on Cypherpunks by Anonymous, and that various crypto packages have RC4 or "EC4". My question is, has RSA taken anyone to court in the US for using RC4 without buying a license from RSA? I haven't heard of such a case. I see four possible approaches by which RSA could hold an interest in the IP around RC4 - patent, trade secret, copyright, and trademark. With respect to RC4, I believe the following - 1. No known patent covers RC4; so there is apparently no patent problem. 2. RSA used to say that the RC4 algorithm was a trade secret - but it's been published in a book (see Applied Crypto) and so widely publicized by now that not even the DVD people would say that it's still a trade secret. So I think there's no trade secret problem. 3. If you don't have an author who's willing to take credit for writing code, it's possible that the copyright in the code you're seeing hasn't been licensed to you, so there's a potential copyright problem. Safest course of action would be to reimplement RC4 from the published descriptions of its workings, e.g., Applied Crypto. 4. RSA likely has a valid trademark in the term "RC4", so it's safest to be careful about using the term so that you're not creating confusion in the minds of consumers about whether or not you're providing them with something created by RSA or yourself or some third party. Some people and organizations have used the term ARC-four to describe an algorithm that interoperates with RSA's RC4; I don't think it matters much what you call it, so long as you're not creating confusion about who wrote the code and the algorithm, or otherwise clobbering someone else's trademark. -- Greg Broiles [EMAIL PROTECTED] PGP: 0x26E4488C
Re: The problem with Steganography
David Honig writes: At 03:20 PM 1/25/00 -0500, Russell Nelson wrote: I'm trying to do forward stego -- that is, publish some encrypted steganographic document, with the idea that, once everyone has a copy, *then* you reveal the key. Fascinating, captain. Canna imagine why. Blackmail? But you don't really need stego for that. You could just send a private-key-encoded file to a list of friends, saying "Please keep this until mm/dd/yy. I may send you the key later." Run a watchdog process somewhere which checks a certain newsgroup for a crypto-signed timestamped message. If it fails to see the message, it sends the key to your list of friends. You could also use it for "Oh, by the way, that gzipped file of the Linux kernel that you downloaded, that's mirrored all over everywhere? It's made with certain sub-optimal compressions. If you run it through this program, it will produce a copy of the DeCSS code." If you wanted to be really clever, you'd bury it inside some government document, so you could at least obfuscate the prosecution with claims of First Amendment rights. But that's not stego either, whether the document is encrypted or not, because you're adding bits, not replacing relatively random bits. Problem is, how do you convince them to keep a copy of that document if they're unaware that it has something buried inside it?? Now you're into psychology. Yup. And I'm certainly (obviously not) competent at that. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Re: The problem with Steganography
On Tue, 25 Jan 2000, Rick Smith wrote: . . . . For example, many stego implementations involve embedding data in the low order bits of a graphical image. Those low order bits undoubtedly have some measurably non-random statistical properties. Once we replace those bits with data, the bits will have serously random statistical properties. So, we can detect stego'ed data if the implementation uses any well known strong encryption algorithm. Why disturb the measurably non-random statistical properties of the low order bits? No one says you have to use your crypto output straight, without 'bluing', so to speak. What if we replace every nth lower order bit, and make n relatively large? Message carrying capacity is reduced, but it becomes harder to see (guess) that a message is hidden there. I wonder if stego users will have to choose between uncrackable encryption or undetectable data. Or extreme inefficiency? Rick. [EMAIL PROTECTED]
Re: The problem with Steganography
If the picture was taken by an actual camera, the least significant bits will be random due to the nature of the way CCDs work in the real world. They might be biased, but it's not very hard to bias a "random" data stream. You could have the sender look at the bias in the odd frames, and use that in the following even frames, if the bias is similar. The recipient could compute the bias in the odd frames, and use that to normalize the stego in the even frames before applying the crypto. If the scene changes drastically, the bias may change, the sender wouldn't encode anything in that frame, and the recipient will need to resync somehow. Stego is subtle, but it's not impossible. After thinking about this a bit, perhaps the point is that any conversion, light-on-CCD to bits, bits to paper, etc., has a certain amount of bias-able "random" data and hence it is likely that any such process has a fingerprint that might even be unique as, of course, the color copier example shows can be made intentional. My knowledge of media reproduction technology in the large is near zero, but if a color copier can identify itself what is to keep it from identifying the time of day or serial numbering the individual copy or silently including a photo of the operator? Larger still, what's to prevent adding such a fingerprint to every copy of National Geographic, to every film processing lab's printing system, to every copy of every MP3 file, to the transmission of every PCS phone, etc., etc.? In short, is steganography the ultimate surveillance tool? --dan
Re: legal status of RC4
Eric Murray [EMAIL PROTECTED] queried the Listocracy:
Does anyone know the legal status of RC4 in the US?
I know that a cipher purporting to be RC4 was published on
Cypherpunks by Anonymous, and that various crypto packages
have RC4 or "EC4". My question is, has RSA taken anyone to
court in the US for using RC4 without buying a license from RSA?
To my knowledge, neither RSADSI, nor the new firm formed by the
combination of RSADSI and Security Dynamics last year -- RSA Security, Inc.
-- has ever dragged any individual or enterprise into court for using an
unlicensed implementation of RC4.
I may have missed something over the years, but there are today an
abundance of commercial products on the market which use ARC4, "Apparently
RC4," or some similar independent implementation of Rivest's RC4 -- with no
tithe to RSA, and no kickback that I can see. (There was a fascinating
discussion of all this a year or two ago, on either Cypherpunks or here on
C2's Cryptography. Search for an evocative subject-line: "None Dare Speak
its Name," or "The Cipher None Dare Name.")
RSA is reportedly far more conscientious in defending its trademark
on the label "RC4." RC2, RC4, RC5, RC6 -- and probably MD2, MD4, and MD5,
Rivest's freeware message digests or hashs -- are registered trademarks.
("RC," Rivest once told me, simply stands for "Ron's Code" -- a workbench
label for crypto in development that somehow escaped into the hands of the
RSA marketing guys.)
I suspect that RSA did send out more than a few nastygrams to OEMs
or other mass marketeers about "illicit use" of RC4, but -- at least in
recent years -- its complaints probably went to commercial enterprises which
both (a) sought to resell the algorithm in the US, and (b) blatently used
the RC4 label in a way that is likely to confuse many people as to the
source of the RC4 implementation code. In the real world, RC4 is today
almost exclusively associated with the implementation of RC4 in the RSA
BSAFE toolkits, which have been licensed to some 700 OEMs, designed into
thousands of products, and installed in a half *billion* user machines.
[Gothic legend to the contrary, I have also never heard of RSA
rousting _any_ US firm or individual who used their own unlicensed
implemention of RSApkc (and RC2 and RC4) in various homebrew SSL grafts, or
in the famous freeware SSL kits: SSLeay or OpenSSL. The elegant design of
RC4 has been widely studied and discussed in academia.]
[Vendors of commercial products which include various ARC4
implementations putz along untouched. The IETF also has several RFCs which
document and refer to various independent and equivalent ACR4
implementations. Indeed, in order to market Eric Young's BSAFE SSL-C
toolkit out of RSA-Australia, Young -- the "eay" of SSLeay in a previous
life, now the CTO of RSA-Australia -- had to prove to both the Australian
and US export control mavens that Young's implementation of RC4 for SSL-C
was based on wholly non-RSADSI and non-American sources.]
Of course, back in the early-90s when the reverse-engineered RC4
code was first anonymously posted to the Net, it immediately became clear
that the old combination of software license, trade secret status,
copyright, and trademark IP with which RSADSI had tried to protect and
control access to Rivest's RC4 algorithm was an utter failure.
As I think the insightful Greg Boiles, Esq., has pointed out
elsewhere, the possibility of unattributed global publication guts many of
the traditional IP defenses for commercial know-how or technical savvy in
commercial products.
Anyone who can deconstruct or reverse-engineer a proprietary and
secret design or formula -- be it the Coca Cola formula or Ron Rivest's RC4
-- can use the Net to duck the retribution that was at the heart of most
traditional IP defenses. (Ya gotta have a 16 year-old's sense of
invulnerability to sign your name to the deed, be you a DVD devil, an angel,
a curious teen scientist, or just a guy who doesn't like to pay royalties to
artists or inventors;-)
The fate of RC4 -- the anonymous post to the Net has led to the
widespread use of unlicensed "ARC4" in hundreds of commercial software
products today -- led RSADSI (and many other corporations) to conclude than
only patents could effectively protect software IP.
In 199o, there were 1,300 US patents issued for software
innovations. In 1999, there were 22,500 software patents issued. sigh I
have always believed the rogue publication of RC4 was a major accelerator in
this trend.
With the threat of anonymous publication of trade secrets on the
Net, it seems inevitable, at least in hindsight, that patents were to become
more important; more broaded applied; and more broadly construed.
Ain't nothin' else, folks, which can define and defend an
intellectual property claim for a novel and non-obvious invention --
Re: The problem with Steganography
Forgive me if I'm missing the point here but I don't think the original question was how to make steganography better and hide the message more effectively (although that's certainly a valuable goal). Sometimes it's important to hide the fact that a secret message exists. A good guy in enemy territory may wish to communicate with friends outside. Discovery of the ciphertext would alert the enemy to his presence. So the question becomes, without identifying the location of the ciphertext in a prior agreement or on some outside channel, can a person communicate with friends without alerting enemies to the existance of secret communications? For example, it's possible that this email was written by a political prisoner in a 3rd world country and he's used steganography to conceal a message to his friends and family right here in these 3 paragraphs. My question is, without prior agreement or access to an outside channel, how are his friends to know to look on the [EMAIL PROTECTED] Listserv for the ciphertext? No matter how well concealed (stego)or how well encrypted (crypto), does he have any way of notifying his friends that they should look here without alerting the enemy of his attempts to communicate? - Eric Tully
Re: NSA Declassified
John Young [EMAIL PROTECTED] responded: Your points are valid for the AIA document. However, in the Navy document, Number 9, image 3, there is the phrase, "Maintain and operate an ECHELON site." I had missed that reference. A agree that the capitalization here is consistent with a code name. On the other hand, the sentence "Maintain and operate an ECHELON site." is the first item in a list of specific functions and tasks that the commander of Sugar Grove is being ordered to carry out. The dictionary meaning of "echelon" fits well in this context, i.e. the commander is instructed to operate a facility subordinate to headquarters in the overall Navel Security Group hierarchy. While a few items on the list are blacked out, most seem to be boilerplate. The main mission of Sugar Grove appears to be detailed in a classified "Enclosure 1." I did a search on "echelon" at www.navsup.navy.mil (they had a search engine that actually worked) and found a number of examples of the word's ordinary usage in the Navy: "Multi-echelon modeling optimizes spares requirements across the wholesale and consumer echelons, and provides the ability to compute wholesale requirement on a readiness-to-response time basis. " http://www.navsup.navy.mil/flash/1096.html "All naval commanders will report through their immediate superior via the chain of command (ISIC) to second echelon commanders when this action has been complete. All second echelon commanders will report to DON CIO upon completion of this tasking by their claimancy NLT 15NOV98. " http://www.navsup.navy.mil/corpinfo/net-policy/alnav.html "Equal Opportunity Assistants provide equal opportunity/sexual harassment subject matter expertise to second and third echelon commands." http://www.navsup.navy.mil/flash/1996.html In light of these examples, the appearance of the term "Echelon 2" in the document fragment at http://jya.com/xechelon.jpg could also be interpreted as telling the recipient that he is responsible for documents coming from the second echelon level in the chain of command. The ACLU Echelon watch page http://www.aclu.org/echelonwatch/ says "ECHELON is a code word for an automated global interception and relay system operated by the intelligence agencies in five nations: the United States, the United Kingdom, Canada, Australia and New Zealand (it is rumored that different nations have different code words for the project)." I have no doubt that NSA runs automated global interception and relay systems and has cooperative agreements with the nations listed and many others. Interception is the essential first step in signals intelligence (SIGINT) which is a major mission of NSA. "Today, SIGINT continues to play an important role in maintaining the superpower status of the United States." http://www.nsa.gov:8080/about_nsa/ Do these interception capabilities include the monitoring and recording of individual phone calls? I am sure they do. I even remember press reports decades ago about whether NSA was restricted from monitoring intercepted down links from Soviet SIGINT satellites that were capturing the phone conversations of US citizens over microwave relays. But I am not convinced that ECHELON is the overarching code word for this activity or even a major component. I wonder why the code word question attracts so much interest. SIGINT is such a large part of NSA mission that it must have spawned dozens or hundred of code words. ECHELON might be better viewed as press moniker for an important story a la Watergate or Whitewater. The activities are real enough. Why does the code name matter so much? Arnold Reinhold
Re: DVD CCA Emergency Hearing to seal DeCSS
Up to 4 PM EST we've had no notice that the file has been "sealed." There have been over 26,000 downloads and they are now going out at 600 per hour.
Re: DVD CCA Emergency Hearing to seal DeCSS
This is becoming picayune but: I'm told that the court has now sealed Exhibits A and B of Hoy's declaration. These are the DeCSS notes and the CSS scramble code. However, the sealing applies only to the paper versions and will prevent hardcopying. Denying access to online versions will require some other action.
Re: The problem with Steganography
Rick Smith wrote: It sounds like there are a number of interesting design questions. For example, the sender and recipient must obviously share a secret key. Why is that obvious? What's wrong with encoding with the recipient's public key? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Y19100 no-prize winner! http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: The problem with Steganography
Rick Smith wrote: Rick Smith wrote: It sounds like there are a number of interesting design questions. For example, the sender and recipient must obviously share a secret key. At 10:18 PM 01/26/2000 +, Ben Laurie wrote: Why is that obvious? What's wrong with encoding with the recipient's public key? It depends on what you're encoding. I expect we end up with a three step process: first, encrypt the data, second, stego it into the image or other file, and third, provide the recipient with information for recovering the hidden data. If we're talking about the first step, encryption of the raw data that's being stego'ed (is there a more legitimate verb for that?), then I'd prefer to use secret key encryption, since it introduces fewer uncertainties regarding the safety of the ciphertext. As to step 3, how this secret information is shared with potential recipients, public key techniques are fine. If we're talking about Russ Nelson's "forward stego" problem, then PK is overkill -- he just needs to publish the secret information and voila, the previously hidden information is uncovered. As to Russ' problem of how to keep the information "available," I suggest we look around our environments and take stock of what iconic images or files we all have and for some reason can't part with. Perhaps there's some really great crt wallpaper image that would do the job, or one could embed it in a Craig Shergold make-a-wish chain letter. Those things NEVER die. I can't quite see the point of forward stego. Why not publish something public key encrypted and publish the private key later? If you want a lot of people to see it, you can't keep it secret. If you can't keep it secret, you may as well just come out with it and publish the bits without stego. What did I miss? Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html Y19100 no-prize winner! http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: The problem with Steganography
For example, it's possible that this email was written by a political prisoner in a 3rd world country and he's used steganography to conceal a message to his friends and family right here in these 3 paragraphs. My question is, without prior agreement or access to an outside channel, how are his friends to know to look on the [EMAIL PROTECTED] Listserv for the ciphertext? No matter how well concealed (stego)or how well encrypted (crypto), does he have any way of notifying his friends that they should look here without alerting the enemy of his attempts to communicate? Ideally, this would be handled by prearrangement, so that anyone involved in a resistance movement or who might be a target as a political prisoner would know where to post his messages and what keys to use so that they could be read. If this was not done, he could still tell his friends that he has heard that some people embed messages in that specific location. He could describe the software program used to do so, and that their public keys would be used to read the message. Maybe to be "politically correct" he could go on and say that doing this would be wrong. Presumably this would be enough of a hint for anyone; even the bad guys, of course, but they would not be able to tell whether any data was actually being sent by this channel. [Presumably the bad guys would only need to suspect, not to know for sure -- if they really don't pay attention to human rights, well, I'm sure the rubber hose will be cheap enough for them to buy. --Perry]
