December 2003 - cypherpunks-legacy

even more steganography talk
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Another way to describe a successful steganography system... I am the opponent. I possess a collection of files that might contain hidden encrypted messages. My task is to determine if they do contain hidden encrypted message. A casual inspection of the files does not reveal any bit patterns that deviate significantly from patterns found is most examples of these kinds of files. However, I suspect these files contain hidden messages that were deposited using a steganography algorithm initialized from a public-key generated initialization vector. To test my hypothesis, I will reverse the steganography process using a large collection of public-keys and then examine the resulting bit sequences. -------- If the steganography algorithm is a good one, reversing the steg process will produce a sequence of bits that appears relatively random, even if there is *no* hidden message. What does "appears relatively random" really mean? How do you measure the randomness of a sequence of bits? I'm not an expert in this field, but I would guess you could measure the randomness by attempting to compress the bit sequence. If the bit sequence does not compress much, it is relatively random. How much is "not much"? In other words, what threshold compression percentage value should you use to declare one bit sequence random and another not random? I don't know. To generalize, an opponent will perform some kind of test to determine if the result of reversing the steg process produces a random bit sequence or a non-random bit sequence. The test will have some threshold value below which indicates a random sequence. If the output of the reverse steganography step always falls below the threshold, even if there is no hidden message, then the opponent will not be able to determine if a file contains a hidden message. Jim_Miller(a)suite.com

2 1

Re: Security through Obscurity
by Hal 17 Dec '03

17 Dec '03

From: Sergey Goldgaber <sergey(a)delbruck.pharm.sunysb.edu> > Well, if we adopt the method of comparing the cost of implementing a > given steganography method to the cost of breaking it as a valid measure of > its effectiveness; then, it would make sense to "maximize" the cost of > breaking it as a means of making the method more effective (ie. making > the method more obscure would make it more effective). I don't think this is a valid measure of steganography's effectiveness. I proposed my own measure, which I think is valid. I think the fundamental problem with your measure is that it counts a system which is easy to break but very easy to implement as effective. I would count such a system as ineffective. > > Instead, if you are going to adopt this goal, this means that the test of > > your steganography is whether the opponent can extract the message. It's > > not that your goal is to "maximize his difficulty". It's that your goal is > > to stop him. Again, NoStO emphasizes clear statements of your goals and > > costs. > > The more difficult it is for one's opponent to extract the message, the > more effective the method is. Thus, "maximizing his difficulty" is a > valid goal. As I see it, this is a goal of most encryption systems. To > make decryption as difficult as possible, if not impossible (ie. maximum > difficulty). I don't think this is right either. The problem is that "as difficult as possible" does not allow for a measure of success. Something which is "as difficult as possible" may nevertheless be useless. This whole notion of maximizing difficulty as a goal is completely misguided. The correct goal is to achieve secrecy. If you have not done that, then maximizing difficulty is pointless. Your goal in making a parachute is to create something that will land you safely. It isn't to "maximize slowness of fall". Suppose I made a parachute out of lead, designing it to maximize slowness among lead parachutes. Will you jump out of an airplane with it? I'd think not. The problem is that this is the wrong goal. > I do not think you have understood _my_ essay. My proposal was for a > default, variable offset in certain steganography applications. The > benefit of this is obvious: having no offset or a non-variable offset > would make for generally poorer security; as, the effort required in > figuring out where one's file is located is nonexistant. Effort > increases when a variable offset is implemented. OK, let me ask this: what is the harm done if the opponent guesses the right offset? How bad are things? Some of your security has been lost. How much? Suppose your stego method is not completely invisible and does give away its existence to some extent. Would you still use it if protected by your offsets, or would you refrain until you had an undetectable stego? How much would you trade off the protection provided by your offsets against the protection provided by undetectable stego? Suppose I am a naive user of your program asking these questions. When I receive a stego'd file and put it on my disk, should I re-format it to change the offset? How much security does this gain me? Is it worth it? Should I have more than one public key, so that the opponent would have more offsets to guess? How much does this help? How much should I worry if I think I may be targetted for surveillance, which would increase the chance of them trying my keys as the offsets? Should I avoid controversial issues, keep a low profile, so that I can prevent this from happening? How much should I trade off against the benefit of making my offset less likely to be tried? I think if you are seriously proposing that your offset scheme adds security, you need to be able to answer questions like these. If it really adds security, you must be willing to pay a cost to achieve that security (recall the NoStO principle: count your costs when you count your benefits!). If you can answer questions like these then you are not violating StO, in my opinion. Hal

1 0

Stego in Jazz?...The Miles Files
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Straightahead jazz fans take note! More significant bits follow: * Critics who claim jazz = noise now will understand that jazz evolved in the 1940s as a stego method for communicating with agents in the field. * Hitler was right in suspecting "that Negro music." * Agent Parker developed method of putting signals in Bird calls, with great sax appeal. * Unveiling below of "crypto-jazz" movement. Cryptids are spreading the PGP word. Jazz raves to be the Next Big Thing. From: esharp(a)panix.com (Elliot Sharp) Newsgroups: rec.music.bluenote Subject: crypto-jazz Date: 3 Mar 1994 12:10:51 -0500 Organization: PANIX Public Access Internet and Unix, NYC Message-ID: <2l55mr$b5s(a)panix.com> Summary: a night of Keywords: Sharp,Ribot,Berne on Tuesday, March 15, the Cooler (416 W. 14, NYC) will present a night of crypto-jazz with: 10 pm Elliott Sharp's THE CRYPTIDS (Sharp-reeds, guitar w/ Reuben Radding-bass, David Gould-drums) 11 pm Marc Ribot - solo guitar 12 am Tim Berne's BLOODCOUNT (Berne-reeds with quartet)

1 0

Seattle Times, 3/6/94
by Matt Thomlinson 17 Dec '03

17 Dec '03

The Seattle Times' front page story (1984 + 10 years) leads into a few articles on pg 18 that deal with encryption/clipper/privacy. Paul Andrews seems to have a _few_ misconceptions about exactly what the clipper chip will do, but all in all it seems like a good wake-up call. This article is the first in a series in privacy, it says. I'm glad something like this made the front page. mt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom(a)u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu

1 0

Update on user-level hack to do telnet encryption posted recently
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

OK folks, I've started tidying up that hack code I posted recently which outlined a method for rolling your own telnet-style encryption. In particular, I've done the hard bit of making it work with an arbitrary binary 1:1 stream cypher, rather than the original hack which *had* to encrypt printable text as printable text (to get it through 7 bit terminal links). [Note, anyone who didn't look at it too closely because they thought it was only for telnet - look again: it's useful for *any* local to remote connection, even kermit down a serial line, as long as you're calling between unixes.] Now, what I need are volunteers - preferably outside the US and any other country where any relevant patents are valid - to work on a suitable stream cypher. Note you don't have to use any patented technology, as long as whatever you come up with is sufficiently secure for your needs - this will eventually be issued as a modular system, with the default encryption module being rot13. If you don't really care much about the strength of encryption (assuming your only opponents are kids who sniff packets who won't have enough crypto experience to decode even an trivial cypher) then there's a lot to be said for everyone implementing their own variation... just for the amusement of tying up the time of all those more competant people who feel they have to know everything that's going on everywhere in the world. Machine cycles they can afford aplenty; man years are a different question... Anyway, back to the project: Currently there's a trivial interface that you can work to - I suggest for demo purposes just using a hard-coded known key at each end, and we'll do the key exchange stuff after we've got the stream cypher working. Here's the header file: /* Placeholder module for arbitrary stream encryption */ #define STATE_SIZE 128 typedef struct cypherstate { char *unique_tag; char whatever[STATE_SIZE]; long int byteno; /* Add useful stuff here as need be... */ } CYPHER_STATE; void new_cypher(CYPHER_STATE *s, char *unique_tag); char stream_cypher(CYPHER_STATE *s, char byte); Put any state you need in the struct, initialise it (with a known secret key for now) in new_cypher; and supply a function that does a 1:1 encoding of a byte in stream_cypher. Make the function stateless apart from the CYPHER_STATE parameter so that it can be used to encode multiple streams without interference. With a bit of help from you guys, this project shouldn't take more than a week to get a prototype running... When I have a feel for what sort of encryption methods people want, and how precisely they're implemented, I'll know better how to generically code the key-exchange part too. I don't think it's appropriate for me to post any more source over the net. Anyone who wants to discuss this in public rather than by mail, I suggest we stick to alt.sources.d Anyone wants the current sources, send mail to gtoal(a)an-teallach.com Thanks G PS The sources I have probably won't work anywhere except on BSD systems. If you want to make the framework bit work on other versions of unix, drop me a line about that too. Your programming will have to be up to the level of writing a clone of the unix 'script' command, which is all this program is really. PPS Americans: please don't get either you or me in trouble by mailing me unsolicited gifts of crypto code. I don't want it. The crypto part of this project is for those people in countries where there's no legal barrier to them participating.

2 1

Truly Stealthy PGP
by Hal 17 Dec '03

17 Dec '03

Eric points out the difficulty of making a "stealth PGP" which is 100% indistinguishable from a string of random bits. The problem is that we have to encode the RSA encrypted number, m, which is less than n, the RSA modulus. PGP first puts out two bytes of bit length, then m. This obviously won't do, since the bit length is generally much less than 2^16 and so these two bytes are a dead giveaway. However, we could leave these two bytes off and just output m as raw bits, padded to the length of n. The recipient knows n so he would be able to extract m. The problem here, as Eric points out, is that m is less than n, so the high bits of m will look non-random. If the high two bytes of n are, say, 0x0C12, then m's high two bytes will never be bigger than this. This will allow the opponent to do much better than 50% on guessing which files have embedded messages. This was discussed some time back on the pgp developers' list, and at that time the suggestion was made to add a multiple of n to m so that it covered a fuller range of values. The recipient would then just take the exponent mod n and try that. Mathematically, call L the next multiple of 256 above n. (0x10000... in the example above.) We want to choose k so that M = m + k*n is randomly distributed between 0 and L-1 if m is randomly distributed between 0 and n-1. This may not be possible in this form. Perhaps there is another deterministic and reversible transformation would accomplish it, though. In that case we would have M = f(m,n) such that f can be reversed given M and n (we can recover m). As a trivial example of this problem, given n=2 and L=3, try to come up with a way to turn a random 0/1 value into a random 0/1/2 value which is both reversible and produces each of 0/1/2 with 33% probability. Seems pretty tough! Hal

2 3

RSAREF help requested
by Eric Conrad 17 Dec '03

17 Dec '03

I need to use RSAREF to do 3 simple things: generate a keypair, encrypt a file, and decrypt a file. This is so that I can safely encrypt online information with the public key, while keeping the private key offline. PGP does what I want, but I can't use it due to legal reasons. Ripem does too much (all the mail and key management stuff), and is too complex for my purposes. I've begun writing the C code using the RSAREF libraries to do what I want, but I'd rather not recreate the wheel. Has anyone written the simple tools I described? ...Eric

1 0

delete from list
by leonar716＠aol.com 17 Dec '03

17 Dec '03

delete my name from cypherpunks BBS

1 0

No Subject
by cowen＠glia.biostr.washington.edu 17 Dec '03

17 Dec '03

about joe6pack>>> though joe 6-pack might not vote, and likely won't even understand about the crypto of it all. he would understand the police listening in on his conversations with jill 6-pack. and not like it to well. i do think though that the ge that the general public should know, what the congress is getting itself into other topics before congress get aired why not this one. making it simple for simple minds, might be beyond some folks though there has been talk here about how to go about the process. which on the surface looks so easy. but the general populace of the US of A has a bit of problem with concepts at times. big bangs and lots of noise and death, that sure does catch attention, for about 20 seconds. the computer folks are going to be fighting with the gov't types til the end of time and the joe 6-packs are going to be stuck in the middle. but we need them more than we need to alienate them. they do pay taxes, some of them do vote, and some of them are the rich and famous we want to get our point across to. not every rich man knows about computers. we as a group or as individuals should at least try to let the joe 6-packs that we know in on the secrets the gov't and the FBI and the NSA are trying to hide from him. maybe that is the point of a so called free nation. and sure we might not run this country, but public outcry most times turns heads in congress. charles the monster maker

1 0

RE: New mailing list?
by Blanc Weber 17 Dec '03

17 Dec '03

"I want each reader of these words to reflect on the phrase "implementing culture". If you do not realize the magnitude of this principle and have some respect for its enormity, I would sincerely suggest that your time would be better spent reading some political philosophy and some technological history and pondering over your desires, to make sure that you know them." Okay, Teach. :>) Thanks for the clarification, Eric. I remember some critical statements made about your attitude toward modifications to list and the suggestions which you apparently shot down. I remained silent but wondering. "Cypherpunks is where the politics meets the code. .... Policy separated from development lags the reality of deployment, and necessarily. " These are some things I have thought about, upon reading complaints against the tangential discussions which come up on the list: It is not unimportant to engage in these conversations as they develop, to allow for the associated efforts to achieve precision on attitudes/expectations which counter the rest of the intellectual atmosphere of acceptance, especially when one might be required to produce just cause why things should go in one direction (yours) rather than another (theirs); when you might have to answer to 'authorities' for non-complicity to collectivist programs. Some people do (and some should) struggle for better justification in their own mind, of their position relating to what they themselves do (writing & distributing code which permits alternatives to government-supplied arrangements), of what they advocate to others that they ought to do (positive or negative support for a method/plan of action), or would prevent (as in thwart the progress/implementation of Clipper). It is not unimportant to be clear about the propriety of the motives behind an argument, to be satisfied that one is correct - that it isn't merely 'whining' because one is not getting one's way, or because the government & its advisors are not sufficiently lenient in their outlook; that there is philosophical, logically consistency in the actions/solutions proposed. It is not unproductive to maintain a general awareness among all those who would deem to be of the same "attitudinal alignment". Else how could such a group survive as advocates of ideas promoting complete independence & total autonomy. (euphemism) I myself would welcome the existence of a more thorough elaboration on this subject, from yourself and the others who founded the list: an explanatory FAQ for reference, especially on the matter of "implementing culture", since this implies more than simply effects dealing with government. Blanc

1 0