Re: stego fingerprints
David Honig writes: Similarly, stego'ing an .mp3 ripped from a CD is a bad idea; stego'ing a .mp3 you made from a signal that was analogue at some point works. Every algorithm is deterministic, but different algorithms will produce different results. And there is no "standard" algorithm for mp3 encoding. It might be suspicious if the TLA found an mp3 which was encoded using no known algorithm. A sensible cryptographer would treat each tune as a one-time pad. A "stego" mp3 encoder could encode using a qualified random stream of bits by default, or a crypto stream for an encoded message. If this encoder was widely distributed, then you'd have somewhere to hide crypto. However if it wasn't, then you're tagging your messages "THIS IS HIDDEN ENCRYPTION". There's enough random bits flying around the net that there's no point in doing that. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | "This is Unix... 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Stop acting so helpless." Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | --Daniel J. Bernstein
Re: Is PGP broken?
Bram Cohen writes: Not that I'm going to propose a new standard or even modifications to old ones - there are already too many of those, the problem is making one of them acceptable, or develpoing a new one which has a good chance of getting universal support. Have you looked at CryptoKong? http://catalog.com/jamesd/Kong/Kong.htm --digsig Russ Nelson 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG BSvaK4MOZ2HQvr15n12Wn//srJ0bGg0SBsjB0i7z 9DzVhXhT9dtOvXQsvNgW9fxxzbg1MahNdUf/jGDb -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | If I knew the Crynwr sells support for free software | PGPok | destination of the 521 Pleasant Valley Rd. | +1 315 268 1925 voice | handbasket, I never would Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | have gotten into it!
Re: Is PGP broken?
Stefan Kelm writes: BTW, what do you mean by "point-source PGP signing"? Instead of leaving your key signing up to your friends, PGP could benefit from a policy-based signature. You could come up with any number of policies: o This keyholder is a Mason/Scout/Rotarian. o This keyholder is a Catholic/Mormon/Lutheran/Quaker. o This keyholder paid $X to sign their key (where X is a number large enough that key abandonment has consequences). o This keyholder has $Y in escrow, to be paid out under some circumstances. o This keyholder has identified themselves to a Notary Public. A photocopy of the identification is on file. o And last but not least: this keyholder publishes their key's signature weekly in the Sunday New York Times. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | If I knew the Crynwr sells support for free software | PGPok | destination of the 521 Pleasant Valley Rd. | +1 315 268 1925 voice | handbasket, I never would Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | have gotten into it!
Is PGP broken?
Is it just me, or is PGP broken? I don't mean any particular version of PGP -- I mean the fact that there are multiple versions of PGP which generate incompatible cryptography. Half the time when someone sends me a PGP-encrypted message, I can't decrypt it. Presuming that I'm right, is anyone attempting to fix PGP? Not to mention anything about PGP keyservers, or the utter and complete absence of anybody doing point-source PGP signing. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | The best way to help the poor 521 Pleasant Valley Rd. | +1 315 268 1925 voice | is to help the rich build Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | up their capital.
The best
If the best is the enemy of the good, is strong crypto the enemy of all other crypto? Just something to ponder... -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Crynwr sells support for free software | PGPok | Damn the firewalls! 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Full connectivity ahead! Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: DeCSS and imminent harm ...
James A. Donald writes: It is a test of will and power. Kaplan took offense at the widespread attitude that such an act was beyond the power of a judge, that judges not only should not censor thei internet, but that they *could* not censor the internet, that the internet was stronger than the judiciary. He's welcome to take offsense. He's even welcome to take action. But in the end, has he been successful? Will he ever be successful? What are the minimum qualifications necessary to get your hands on a copy of DeCSS? By the time this is all over, and the issue has been decided, DeCSS will be available in a thousand different places and a thousand different formats. For example, I'm openly publishing a copy of DeCSS on my home page. How stupid do you have to be to not "get it"? For example, one of these days, some popular artist's CD is going to come with a bonus load of bits. After it's been a million-seller, the activist is going to explain how to extract files from songs. No longer will you need to play a vinyl disk backwards to get the secret message. What do you try to suppress? The CD? Not possible. The information on how to extract? It'll be nothing more than a 1024-bit number. So now the government declares posession of a number illegal. And there is *nothing* any judge can do about it. Governments have a binary (I love the irony of it) choice: give up the economic benefits of digital medium, or give up legal restrictions on distribution of information. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Crynwr sells support for free software | PGPok | Damn the firewalls! 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Full connectivity ahead! Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: reflecting on PGP, keyservers, and the Web of Trust
Ed Gerck writes: Even though the web-of-trust seems to be a pretty good part of PGP, IMO it is actually it's Achilles heel. Nope. Usability is its Achilles heel. PGP needs to be wrapped in something, and yet it's not really designed to be wrapped. Even if it were, PGP, Inc. changed the interface! Doh! And then there's the whole encryption method problem. No, web-of-trust as a problem is way down there on the list. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | Crynwr sells support for free software | PGPok | Damn the firewalls! 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Full connectivity ahead! Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: Comcast@Home bans VPNs
Ian Brown writes: ... subscribers to agree not to use the service as a means to create a VPN. Could someone describe to me (in my ignorance) the problem this rule is intended to solve? -- -russ nelson [EMAIL PROTECTED] http://russnelson.com | If you think Crynwr sells support for free software | PGPok | health care is expensive now 521 Pleasant Valley Rd. | +1 315 268 1925 voice | now, wait until you see Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | what it costs when it's free.
Re: Electronic Signatures Yield Unpleasant Surprises
Don Davis writes: if we are successful in making crypto that's usable enough to become pervasive, then industry and the public will need new laws to help resolve social conflicts involving crypto, such as inevitably will arise. I'm not sure this statement is as obvious as you think it is. Legislation could help, or it could hurt. Unrealistic, unimplementable legislation enacted through ignorance might hurt less than well-informed legislation. Case law tends to be more reflective of reality, and there's becoming more of that. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Is Unix compatible with Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Linux?
Re: KeyGhost
Lyle Seaman writes: What I really want is a keyboard with a slight variation -- not a KeyGhost but a KeySpook. If you have no physical security, you have no computer security. I can't think of any qualifiers to add to that statement. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Is Unix compatible with Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Linux?
good cellphone hacking press
The May 1 issue of America's Network (http://www.americasnetwork.com) has some nice press for cryptography in its Wireless column. The title is "Hacked again!" and the subtitle is "Another cellular algorithm has bitten the dust at the hands of cryptographers armed with little more than a PC. The industry says there's no cause for alarm, but the cryptography community still says otherwise." http://www.americasnetwork.com/issues/2000issues/2501/2501_hacked.htm -- -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: Critics blast Windows 2000's quiet use of DES instead of 3DES
L. Sassaman writes: PGP's source code has always been available for public review. This has not changed. There are no "back doors" for the NSA in PGP, paranoiaUnless they are particularly subtle ones, based on a mathematical understanding that is not yet publicly known. Remember that the NSA knew about differential cryptanalysis well before anyone else. Times have changed, but maybe less than we think./paranoia -- -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: hiding plaintext
Bill Stewart writes: At 02:54 PM 03/01/2000 -0500, Russell Nelson wrote: The essence of the above algorithm (let's call it BP1, for Buried Plaintext 1) is to force the decryption trial to be iterated until the buried plaintext is found. It means that the decryption engine needs to have the full crypttext available to it. If you can decrypt a message in N steps, then using BP1 with half random data forces you to do N*2 steps, where the steps themselves are more complicated. The storage requirements are higher, as are the data transfer pathways. I'm not convinced that this is a big win compared to CBC with a random IV, which also forces the cracker to crank the crypto step an extra time. For many popular crypto algorithms, such as N-DES, Blowfish, even RC4, the key scheduling takes more time than cranking the algorithm (though there are ways to avoid that with 1-DES), and you know that once you find a SOT, that's the starting point, though if you've got the wrong key, 1/256 bytes will be SOT. Yes, but you're tying up a decryptor for that much more time. Cryptography is more about economics than anything else. You want to do things which cost the cryptanalyst more than they cost you, preferably as many multiples more as you can manage. But now I'm agreeing with you that there are probably other algorithms which are more profitable to you. That is, they have a higher multiplier -- for a given amount of effort spent, they generate more work for the cryptanalyst than anything else. And realistically, that translates into key length more than anything else. Perhaps HP1 is best used to pad messages while creating the least possible known plaintext. -- -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.
hiding plaintext
One could increase the difficulty of decryption by three or four doublings by intermixing random data with plaintext in a message. Here's the least stupid method I can think of: the first character in a message is the start of text (SOT) character. The second character in a message is the end of text (EOT) character. The message itself consists of random data intermixed with plaintext prefixed by SOT and suffixed with EOT. An EOT outside of plaintext stands for itself. An SOT inside plaintext stands for itself. This method can encode arbitrary plaintext. By implication, the random data does not contain an SOT nor EOT. Instead of being able to look at a fixed point in the encrypted text for plain text, it's necessary to examine the entire text. The cryptanalyst gets a clue that they should continue if they look at enough of the random text without finding SOT or EOT characters. They get a clue they should stop if the first two characters are identical, but that's only 1/256 probability. This mainly serves to increase the complexity and expense of decryption engines. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | No intellectual property 521 Pleasant Valley Rd. | +1 315 268 1925 voice | rights were harmed in the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | creation of this message.
Re: hiding plaintext
Eric Murray writes: On Tue, Feb 29, 2000 at 11:14:31AM -0500, Russell Nelson wrote: One could increase the difficulty of decryption by three or four doublings by intermixing random data with plaintext in a message. Here's the least stupid method I can think of: the first character in a message is the start of text (SOT) character. The second character in a message is the end of text (EOT) character. The message itself consists of random data intermixed with plaintext prefixed by SOT and suffixed with EOT. An EOT outside of plaintext stands for itself. An SOT inside plaintext stands for itself. This method can encode arbitrary plaintext. By implication, the random data does not contain an SOT nor EOT. I assume that you do this before encryption. Yes. Wouldn't compressing the plaintext before encryption have the same effect? Only if you use a secret compression system. Otherwise the structure of your compression system still exists as a known plaintext. You could (probably should) compress your plaintext before running it through the above algorithm. The essence of the above algorithm (let's call it BP1, for Buried Plaintext 1) is to force the decryption trial to be iterated until the buried plaintext is found. It means that the decryption engine needs to have the full crypttext available to it. If you can decrypt a message in N steps, then using BP1 with half random data forces you to do N*2 steps, where the steps themselves are more complicated. The storage requirements are higher, as are the data transfer pathways. -- -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: ZKS hires Brands, licenses patents
lcs Mixmaster Remailer writes: Have their been other open source projects which used patented technology owned by the company releasing the source? How has the licensing been handled in those cases? Basically, "You get a license for this patented algorithm only if you use this source code." Details are at http://opensource.org/licenses/ -- -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. ^gratuitious moderator suck-up^
Coerced decryption?
Caspar Bowden writes: And, as a result, the Bill proposes that the police or the security services should have the power to force someone to hand over decryption keys or the plain text of specified materials, such as e-mails, and jail those who refuse. Nobody's mentioned the possibility of an encryption system which always encrypts two documents simultaneously, with two different keys: one to retrieves the first (real) document, and the second one which retrieves to the second (innocuous) document. With such a system, it should be clear that coercing decryption has the same negative attributes as coercing self-incrimination. As an aside, why hasn't anybody mentioned this before? It seems obvious to me. Am I some sort of supergenius or something (more likely the latter, in my experience!)? Or is there an information source that I'm missing out on? Are people saying things about cryptography that don't make it to [EMAIL PROTECTED]? -- -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
Ben Laurie writes: 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? It depends on how hostile the regime is. If you want to publish something but the publishing process itself is risky, you could publish it stego'd after running it through something pseudo-random, e.g. the low bits of a particular song. Hmmm I think I'm thinking... my brain is starting to swell... I'm starting to come up with something. Just as PGP doesn't use a public key algorithm to encrypt, but instead to encrypt a private-key-encryption key, you wouldn't use low-bit stego to hide the data, you'd use it to say which *other* stream of random bits had been used to exclusive-or the actual encrypted data. If the set of random (low) bits came from the same type of data stream, then the statistics would be the same. So you use 1 out of every 1024 bits to create a number, and the number selects a particular archived piece of data, and then ... and then Sigh. But here we run into security by obscurity. This only works if the algorithm to select the other audio stream is not published. As soon as you publish it, someone can de-randomize, or de-color the data, and see that you have non-statistically-correct data hidden. What you'd need to do is have an algorithm which takes in a whole big pile of bits, and depending on the recipient's private key, selects some of them for decryption. In this manner, you make the problem of detecting the stego computationally equal to decrypting the data. -- -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.
A big safe source of random (colored) bits
Okay, here's something I've been thinking of for a while. Run a political discussion mailing list which mails audio files back and forth. This list, at least in the US, would enjoy the highest Constitutional protection. However, you'd never know if the low bits of the audio stream have been tampered with or not. In fact, you'd actually *presume* that they had been. Assuming you had effective stego, anyway. As Rick points out, we don't have any such. -- -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
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
lcs Mixmaster Remailer writes: The problem with Steganography is that there's basically no way to clue people in to it's location without clueing everyone into it. Encryption is successful if the attacker can't find information about the plaintext without the key. Ideally, he can't answer questions about the plaintext any better with access to the ciphertext than without. 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. 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?? In this particular case, there is no crypto -- it's completely security-by-obscurity. I've published the burial algorithm, or at least sent it to the maintainer of the software. Haven't written the retrieval algorithm yet, so in a sense the "key" is still secret. But only 33 people sucked down a copy. Maybe I should have buried it inside a pornographic picture? :) -- -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: Export control of Java VM ??
Ron Rivest writes:
(*) A Post tag system has a number of rewrite rules of the form
L_i -- R_i
where L_i and R_i are strings over some alphabet (e.g. binary).
As long as the prefix of the input matches some L_i, that
L_i is removed from the beginning of the input, and the
replacement R_i is added to the end of the input.
You mean like:
#!/usr/bin/perl
# usage: post-tag '01--02' '002--3'
# tests: 01 002 010 00201
while($_=shift) {
die unless m/(.*)--(.*)/;
push(@L, $1);
push(@R, $2);
}
while() {
chomp;
do {
for($i=0; $i @L; $i++) {
$l=$L[$i];
$r=$R[$i];
print "$_ trying $l--$r\n";
last if s/^$l(.*)/$1$r/;
}
print "$_ restarting\n" if ($i @L);
} while ($i @L);
print "$_\n";
}
--
-russ nelson [EMAIL PROTECTED] http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
RE: Two Observations on the IETF Plenary Wiretap Vote
lcs Mixmaster Remailer writes: Lucky Green [EMAIL PROTECTED] writes: Over the years, using Wei Dai's term Pipenet (or Pipe-net, as it was spelled originally) has firmly been established as denotating an anonymous IP network that uses constant or otherwise data independent "pipes" between the nodes of the network. Since Freedom uses link padding, I would consider Freedom a Pipenet. It has been the recognition that data-independent traffic flows are a necessary design component of a secure anonymous IP network, especially between the end-user and the first network node, that sets Pipenet designs apart from naive implementations such as the first generation Onion Routers and Crowds. This documentation would apparently be consistent with the use of link padding between the nodes of the network but not between the user's machine and the node where it enters the network. As Lucky points out, padding from the end-user to the first network node is important. We need a clear description of the Freedom architecture which answers this question. I utterly fail to see what's wrong with mixmaster, other than the fact that the sole implementation is no longer supported. The concept seems fine, it's just the implementation that's lacking. If I had anything resembling copious spare time, I'd take it over, and write a Windows version as well. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: PGPphone sources released.
Ted Lemon writes: Apparently the sources to PGPphone have been released (after many years). See: According to that message, the license is not an open source license, though, so this is unfortunately not very exciting. :'( Right. However, you are free to download the source code, and you are free to distribute patches. You just don't have any permission to distribute the code, or derived versions (e.g. code with patches applied, or binaries). Unfortunately, this means that we have to rely on NAI's continued distribution of the code, and users will be limited to those who can download, patch, and compile the code. Yes, it would be better if NAI distributed the sources under some sort of open source license. A number of open source licenses may be found at http://opensource.org/, not all of them unfriendly to business interests. SpeakFreely (http://www.speakfreely.org) is already open source, so it sets a minimum bar on the restrictions you can expect to be able to set on the distribution of a freeware encrypting telephone package. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: Almost-Everywhere Superiority for Quantum Computing
Julian Assange writes:
Simon as extended by Brassard and H{\o}yer shows that there are
tasks on which quantum machines are exponentially faster than
each classical machine infinitely often. The present paper shows
that there are tasks on which quantum machines are exponentially
faster than each classical machine almost everywhere.
Okay, then can I ask a silly question (I prefer to contribute good
answers, but in this case hopefully the question is good enough)? If
quantum computers make brute-force cryptanalysis tasks easier, don't
they also make brute-force cryptographic tasks easier as well? Put
another way, is there something special about quantum computers that
is different from Intel's next process shrink? That is, apart from
the havoc it plays with key lifetime expectations?
--
-russ nelson [EMAIL PROTECTED] http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: IP: IETF considers building wiretapping into the Internet
Steven M. Bellovin writes: So -- how should the back door be installed? In the protocol? In the telco endpoint? Is it ethical for security people to work on something that lowers the security of the system? Given that it's going to be done anyway, is it ethical to refrain, lest it be done incompetently? If something evil is done poorly, is that more or less evil? Answer not obvious to me. In any case, a properly implemented end-to-end encrypted voice stream traveling over a data path with the CALEA bit set just allows the FBI easy access to strong crypto. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: desirable properties of secure voting
Anonymous writes: 8. Receiptfreeness: A voter can't prove to a coercer, how he has voted. As a result, verifiable vote buying is impossible. It appears that the votehere system does not satisfy this, since the vote is published in encrypted form, so the voter can reveal the plaintext in a verifiable way. Of course even if the system mathematically protected against this you could still sell your vote by voting at home while the vote buyer watched you. Any time you're allowed to vote in a manner which a third party can observe everything you observe, they can affect your cost of voting one way or another. It's much more fun to try to disprove a positive statement. So let's try. Perhaps the voting is in a challenge-response form? Given a number, the voting executes a pre-arranged algorithm on it, and votes with the results of the algorithm. That would work, presuming that the algorithm has enough bits of entropy to confound cryptanalysis. There's a bunch of problems, though: the algorithm has to be executable in someone's head, without any intermediate values being transcribed. The algorithm has to be memorized. The algorithm has to be coordinated with the vote-taking authority. Does this sound like the pre-computer key distribution problem to you? Sure does to me, so much so that I would say that this disproof disproves nothing in a world where guys pick their girlfriend's name as their password, and where people can keep 5+-2 things in their head at any one time. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: The well-travelled packet
Ray Hirschfeld writes: Seriously, my first reaction was that no crime had been committed, but upon re-examining the export regulations I'm not so sure. Perhaps the fact that the packets are explicitly destined for the US is considered "adequate precaution" against unauthorized transfer. Here is the relevant section [734.2(b)(9)] of the EAR: The precautions may be "usual", but they are certainly not sufficient. If crackers can write a credit card number scanner, they can write a crypto code scanner, particularly if they're looking for a special package. But really, this is just a curio. Anyone can get a shell account on some ISP's computer in the US, and download to their heart's content. The crypto export laws are not based at curtailing export, they're aimed directly at businesses. It may hurt to be a US crypto businessman, but at least you can take comfort from the fact that your pain is intended. :( -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
The well-travelled packet
Forwarded with permission (the permission being the short quote below, the message being the long one). I don't have a copy of the traceroute, but it definitely showed packets going from Washington DC to NYC through Paris. Dick St.Peters writes: Well, the questions were really intended to be rhetorical and/or amusing, but sure. The crypto guys will probably be as amused as anyone. Dick St.Peters writes: Remember that traceroute I sent you showing packets from me to a site near here going by way of Europe? I was telling a friend about that this morning, and he asked an interesting question. Suppose someone on my network sent someone at the site a cryptographic program - a US citizen in the US sending it to another US citizen in the US, but the packet route is via Europe. Is that illegal? If so, who is guilty? My user with no knowledge of the route? Sprint, who sent the packets abroad with no knowledge of what they contained? EUNet, who BGP-announced the route to Sprint in Europe? -- Dick St.Peters, [EMAIL PROTECTED] Gatekeeper, NetHeaven, Saratoga Springs, NY Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/ GlensFalls/LakePlacid/NorthCreek/Plattsburgh/... Oldest Internet service based in the Adirondack-Albany region
I'm not sure we have the obvious problem here.
On Fri, 17 Sep 1999, Greg Broiles wrote: What scares me is the possibility that there won't even be an argument about whether or not a particular clump of ciphertext decodes to a particular bit of plaintext because I don't think it'll be possible to cross-examine prosecution witnesses about the way that they came into possession of what's purported to be plaintext. They won't need to say how they came into possession of the plaintext, because that would reveal their methods . . . . On the other hand, if a defendant could show a possibility of a violation of the 4th Amendment (quoted below), then they've got a serious case. What we have been fretting about are a bunch of serious 4th Amendment violations. There's no two ways around it: non-circumspect gathering of encrypted documents, or a keyboard sniffer, or a processor protection by-pass, are all potential 4th Amendment violations. Now, I don't mean to wave a piece of paper and say that it's a magic token that keeps me safe. However, what we are afraid of is illegal. We don't have to pass any new laws. All we have to do is ensure that the existing ones are enforced. It all comes down to your threat model. Is the entity you're protecting against capable of subverting your processor? Your operating system? Your hardware configuration? If so, there's no crypto that can protect you. You want to get scared? What if your network controller chip was spying on the keyboard controller accesses, and leaking the keystrokes in data appended beyond the length of valid IP packets? Or into ICMP replies? I don't know of any protocol analyzer that bothers to look at that data. Would you notice or care if someone was pinging you? Some sites would, but most wouldn't. 4th Amendment The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated; and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched and the persons or things to be seized. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: Why did White House change its mind on crypto?
Ben Laurie writes: Declan McCullagh wrote: Another answer might lie in a little-noticed section of the legislation the White House has sent to Congress. It says that during civil cases or criminal prosecutions, the Feds can use decrypted evidence in court without revealing how they descrambled it. If you can not reveal how you descramble it, doesn't that mean you can't be asked to show that it actually corresponds to the ciphertext? Scary! I agree it's scary. What's the difference between that, and being stopped on a dark road at 2AM by a state trooper? I was, and it was scary, because he kept asking me if I had any guns, and he wanted to see what was inside the foil candy wrapper on my dashboard (more foil), but obviously he expected that it was hash. But what if he handed back some hash wrapped in foil? What would I have done? At that point, I've got drugs, and he knows it, and he could arrest me. What's the difference between that, and someone claiming that a certain piece of text decrypts to a sinister message? Seems to me like the best defense against that is mass-market crypto. Because if the TLA claims that something decrypts to something, and I can use the mass-market crypto to have it decrypt to something else, the TLA has a credibility problem. Or is this not why you're scared? -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
RSA security advert
The September 13th InfoWorld has an advertisement by RSA Security. If you squint your eyes up real tight, and read between the lines, it reads like this: Our patents are running out. Please don't forget who invented this stuff. RSA Security For almost two decades, More than 450 million copies businesses have had no choice of our RSA BSAFE(r) encryption but to purchase public-keytechnology are installed in cryptography from RSA Datatoday's most successful Security. Because we've applications and devices. And gotten so much money, we've why shouldn't it be that way? purchased another company,All other software is illegal, Security Dynamics and we like it like that. To Technologies, Inc. Today, thetry to keep you using our companies have unified under software, we have a new RSA one name, RSA Security, Inc. Keon(tm) product line, Our new name and look reflectsproviding companies with a our desperate desire for you complete digital certificate to continue to purchase system, known as "PKI," to products from us, even after enable and manage security for our patents run out. We know e-commerce applications. you have almost no idea who weThousands of customers have are, but you should. Chances chosen RSA Security, including are pretty close to 100% Cisco, Compaq, Ericsson, you've had to rely on one or Fidelity, IBM, and Lucent. more of our products to They haven't had any other purchase something over the choice, and neither do you. Internet, securely send email,Now that we have to persuade safely connect to youryou to purchase from us, we're network, or do you bankingnow trying to build a brand online. As a combinedname before it's too late. To company, we are the premier learn how we might serve your monopoly in e-security -- at e-security needs, please visit least until our patents run us at www.rsasecurity.com, or out. contact us at [EMAIL PROTECTED] or 1-877-RSA-4900 Your Only Choice in e-Security -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: Power analysis of AES candidates
John Kelsey writes: There's some question about how hard it will be to design hardware that will be DPA-resistant for different algorithms. Big on-chip caps. Lithium batteries. Tamper-resistant housings. That's what Dallas Semiconductor uses for its 1-Wire devices, including the famous Java ring. It works to protect data, but not algorithms, because once you extract the algorithm, you've got it. With data, you have only to make extraction more expensive than the data is worth. You could also superglue the chip to something very hard, so that you can't probe the chip without getting the cover off, and if you try, you destroy the chip trying. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: message-signing at the MTA level
Greg Rose writes: At 22:09 21/08/1999 -0400, Russell Nelson wrote: I've been thinking about cryptographic signing of messages at the mail transfer agent level. I can think of how to do it, but I'm not sure what problem it solves. :) Anyone have any ideas? Signing messages at the MTA level solves no problem at all unless there's a widely deployed PKI. Because of man in the middle attacks? You could supply a public key in the SMTP server banner, but that doesn't help if someone is fudging things in the middle. Encryption would help, though, wouldn't it? Of course, you've got a nasty bit of known plaintext right at the beginning: "Received:" Actually, if your sole threat model is "telnet mail.example.com 25", then *any* kind of crypto helps. :) And if I go down in history for any quote at all, it should be: "Crypto without a threat model is like cookies without milk." -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: Proposed bill for tax credit to develop encryption with covert access
-- BEGIN 2rot-13 David Jablon writes: Amazing! Despite the title, this seems to be a retro-active tax break for all developers of snake-oil and other poorly concieved or poorly implemented cryptography. Or for that matter, poorly selling. There's nothing in the bill that requires that the encryption be otherwise unbreakable (e.g. I could get a tax credit for implementing a backdoor'ed rot-13) or that anyone actually buy or use the snake-oil^H^H^H^H^H^H^H^H^Hencryption software. Just how *would* you put a backdoor into rot-13? Ah! I've got it! Implement a new, higher security 2rot-13 (apply rot-13 twice, for double the encryption value). -- END 2rot-13 -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
It's to be expected (crypto laws)
I just read _The Incredible Bread Machine_, by R. W. Grant. A Fox Wilkes book, available from Laissez-Faire Books. I think a quote from page 241, on The Limits of Political Action, is appropriate in re the recent "I told you so" observation by Lucky Green: Government is force, and politics is simply the means of deciding who gets to use it at whose expense. By its nature, then, politics will inexorably represent the interests of those who seek the favors of government. Hence the bewilderment of voters who find that no matter who wins the election, government continues to grow bigger and more intrusive. At best, transient reforms can be accomplished, but the underlying dynamic of politics is constantly to expand the role of the state. Accordingly, those seeking to limit the role of political force [aka crypto export laws] in our society are quite literally disenfranchised. You can vote for ruler A or ruler B, but you can't vote for ino/i ruler. Political action can possibly be helpful for educational purposes, or as a rear-guard effort, but its effectiveness as an influence for less government is limited. [as we've seen.] What to do? Attack the state at the source of its power: our cooperation. It can be noisy civil disobediance. It can be simply ignoring an unenforcable law. It can be challenging the power of the state in its own institution, as in the Bernstein, Karn, and Junger cases. I highly encourage all [EMAIL PROTECTED] readers to read The Incredible Bread Machine. It puts together a comprehensive attack on the legitimacy of the state. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr sells OSI Certified(tm) Open Source Sware| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: depleting the random number generator
John Denker writes: The bad part is that Whitney has already gobbled up quite a few bits of entropy from /dev/random before the slightest bit of authentication is attempted. You're presuming that you're using the standard Linux version of /dev/random. You could quite easily write a driver for that serial port white noise generator which was discussed earlier on this list. Make it's operation compatible with /dev/random, and replace /dev/random with a node pointing to your device. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Eason/Kawaguchi stego
There's an EETimes article on Eason/Kawaguchi stego in the 6/28 issue. They hide their bits in the most complex parts of the image -- where neighboring pixels are most different from one another. Also, only a few parameters are needed to retrieve the information, so anybody with the appropriate detector and a few guesses can find the information. Yes, that's right, it's only hidden from view, not from even the least determined observer. So why not just call it watermarking? Because (so they claim) watermarking is embedded everywhere in the image. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: Eason/Kawaguchi stego
Jay Holovacs writes: -- From: Russell Nelson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Eason/Kawaguchi stego Date: Tuesday, June 29, 1999 9:27 AM . Also, only a few parameters are needed to retrieve the information, so anybody with the appropriate detector and a few guesses can find the information. Yes, that's right, it's only hidden from view, not from even the least determined observer. But if data is properly encrypted first, noise extracted from any picture should be virtually indistinguishable from encrypted data. Stego is really just obscurity with plausible deniability, it should never be used without encryption. I don't know of any stego packages that work with mass-market cryptography e.g. pgp or mixmaster. You can't just take the output of one of those crypto systems and stuff it into the "random" bits of a real-life sample. There's too much plaintext for the stego to hide. Stego needs a special type of cryptography that has no known plaintext in its encrypted output -- where the output of the stego algorithm is just as white as the white noise it replaces. So you've got a chicken-and-egg problem -- you have to have yet another set of public keys for your stego crypto algorithm. But besides that, you need software which camps on every source of "random" bits that come into your life, cryptanlyzing it using your private key. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: NPR story on crypto...
John Young writes: What's intriguing is whether PECSENC, now headed by an ex-NSA honcho, is going to bite NSA's sigint bullet, and recommend that strong encryption is better for the public interest than natsec snooping, what with the world now getting its hands on means of strong protection for conventional telecommunications of text and to a lesser extent voice. I'll go out on a limb and speculate that the NSA will eventually be a proponent of strong crypto. Why? Because the weak-crypto crowd essentially operates as a cartel. A cartel is built of all interested parties (e.g. oil producers in OPEC). They all agree to refrain from behavior which would be advantagous if only a minority did it, but which is harmful if everyone did it (e.g. competing in a free market). In the case of economic producers, that means reducing production and raising prices. Of course, you can't deny the free market. It's like a balloon -- press in on it, and it presses out somewhere else. If you succeed in containing it, it pushes back hard everywhere. Now that prices are higher, you have two problems: new entrants have to be incorporated into the cartel, and current entrants have a strong incentive to cheat. These problems are bad enough that only one cartel has survived in the long run: the deBeers diamond cartel. Remember the new diamond fields in Canada and Russia discovered earlier this decade? They were brought into the cartel (IIRC). They had to be, otherwise the cartel would fall. This works because people have been persuaded that diamonds are precious, worth paying very high prices. There's lots of room in the diamond cartel. Is it obvious now how this applies to the crypto market? If everyone is forced to use weak crypto, all governments can spy on all others.[1] But now that PC's are cheap and strong crypto is widely available, governments have a harder time enforcing weak crypto (presuming they want to). As their citizens and corporations defect, the remaining cartel members lose the advantage of decrypting the defectors, and have a shorter lever to control their own citizens and corporations. At some point there will be enough defectors to bring down the cartel. Once we break the dam, the NSA, being a responsible government institution, must advocate strong crypto in order to protect its mission. Because, their mission is to gain an advantage over other countries through sigint. If their policies create an obvious disadvantage (US crypto can be broken, but nobody else's can), then they'll be changed. And when the dam breaks, you'll see an amazing flip-flop. You'll need a seat belt on your computer chair to keep from falling on the floor. [1] There are secret trade shows where wiretapping equipment is sold. You need a clearance and a photo badge to attend. I've never been, but I expect that the same, or similar, trade shows sell DES-breaking equipment. Particularly when it's cheaper than five hum-vees. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: Word needed for Entropy
[I suspect we're hitting the end of this thread... --Perry] At 9:32 AM -0700 6/26/99, Carl Ellison wrote: I've been guilty of sloppy use of English, occasionally, and one such sloppiness that I run into occasionally is with the word "entropy" for cryptographic purposes. What we need is a word or very short phrase to capture the full phrase: How about "God's dice"? -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Lucky Green writes: OpenSSL is a library. It should support whatever the standard supports and whatever users and/or authors of the lib desire to be in the lib. That may include broken or null-ciphers. But the user should have to take positive action to get at the broken ciphers. I believe by default, OpenSSL should ship with the weak ciphers disabled. And there should be a clear warning: "Not secure, don't fool yourself, do not use, etc]". Offering ROT-13 in a library you one maintains is one thing. That's it! Include a whole range of ciphers, all the way from ROT-13 through Caesar through Enigma through an exportable 40-bit code through DES through IDEA through blowfish. Make it clear that the security one gets is the security one chooses, and include an analysis of the history and security of the various ciphers. I mean, it's foolish to impose your threat model on other people, just as it would be foolish for someone with a higher threat model impose her security requirements on you. I mean, one high threat model says "No back channels", so all data must travel through a hardware one-way interface. No. Would you like to be told that your chosen level of security is insufficient for that threat model, therefore you must take special steps to enable a cipher sufficient for your threat model? -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Just the ticket for those conferences
http://loaf.ecks.org/ Linux On A Floppy. Get networking params (IP address, subnet mask, default router), power-down, insert floppy, reboot. Comes with ssh. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Neal Stephenson's Cryptonomicon
Jeff Simmons writes: There's also a page at http://www.well.com/user/neal/cypherFAQ.html that is aimed at the cypherpunk list. Most interesting part is that evidently Bruce Schneier designed a special cypher for use in the novel, based on a deck of playing cards. (?) I'll ask the obvious stupid questions now: Is our government going to refuse export of playing cards? Are border guards going to start shuffling decks of cards they find in passenger suitcases? Or confiscating them? I expect to go abroad within the month. I think I'll take a half-dozen decks of cards with me. Guard: Why do you have so many decks of cards? Me: They're munitions. I wanted to be well-armed. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Biprime Cryptography to replace RSA?
Bluefish [@ home] writes: I would propose "Biprime Cryptography" or "BPC" as the generic term for RSA. Biprime is a natural and appropriate English name for the product of two primes. There are other "biprimes" too, BiPrime Factoring. BPF (no, not Berkeley Packet Filter!) -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
mixmaster the DNS
Hmmm Anybody thought of combining mixmaster, an SMTP client, SMTP server, and the DNS? Here's how it would work: 1) email would arrive at the SMTP client using ordinary means. 2) The SMTP client would ask the DNS for the MX records for the host. 3) If the DNS has two MX records which point to the same host, one of which is in a particular range (e.g. 23489-23511), then the recipient is considered mixmaster-enabled. If not, then the mail is simply delivered. 4) The SMTP client has access to a list of acceptable relay hosts, also mixmaster-enabled. It either delivers the mail, or relays the mail to one of these hosts. The relay is done in the usual mixmaster fashion. 5) (and here's the key). When the SMTP client (either the original one, or the one on the relay) tries to deliver the mail, it does so by connecting to the port number named in the highest-numbered of the two MX records. If that fails, then the mail is delivered via unencrypted SMTP. It's got some weaknesses, but it goes a long way towards keeping intranet trans-Internet mail private. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Intel announcements at RSA '99
Arnold G. Reinhold writes: I do not agree, however, that 1 bit per second would be fast enough. Why not? Randomness never goes stale. If it did, they wouldn't print books full of random numbers. Store the 1bps in a FIFO. Save that entropy! There's a limited amount of it in the universe, you know. :) -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
RE: France Allows 128 Bit Crypto
Black Unicorn writes: WOAH. Are you sure you know what you are doing? You're close to imposing a duty to decrypt punishable by penal sanctions (read jailtime). This is precisely the WRONG way to go. Sure, because you can't tell the difference between someone who is unable to decrypt (Sorry, I lost my key), and someone who is unwilling to decrypt (Sorry, I "lost" my key). Encrypted documents should be covered under our Fifth Amendment. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: crypto-stego
Bill Stewart writes:
At 09:42 PM 12/30/98 -, Russell Nelson wrote:
Now here's a silly question: cryptanalysis requires that one be able
to recognize the plaintext. Steganography requires that one NOT be
able to recognize the cryptography from random noise. So, if I use a
legal cryptography algorithm (with however few bits I'm allowed), on
the output of an illegal stego program, all of those bits are pure
pleasure. Even someone with my legal public key can't be sure that
they've decrypted the right thing unless my stego is broken or they
have my illegal public key.
I think you've got this backwards - your words say that
Output = Crypto( Stego(something), WimpyKey )
where "something" is presumably the message.
But that's not secure - good steganography doesn't require that
Stego(Message) look like random noise, only that
Stego(Crypto(Message)) and Stego(Noise) look similar enough
so the Bad Guys won't notice that the encrypted message is there.
No, "something" is presumably a crypto algorithm that adds another set
of key bits. But you're right, it was a silly question. Stego relies
on hiding crypto within something identifiable as something ordinary.
It needs to say "These are not the droids you're looking for." You
might get a fair bit of extra security, perhaps approaching the number
of added key bits, by using the same crypto algorithm which produced
the input to your stego algorithm.
you need to make sure that it's really stealthy, something PGP hasn't done
after N years aand several format changes.
Maybe there's hope for GNU Privacy Guard?
Cryptography restrictions are the USA's Maginot Line. Big, expensive,
ultimately routed around regardless, and once the war is over,
difficult to get rid of.
Heh - it's especially surprising to me that regulations designed to
keep Commies from getting military technology are still in place,
and the Russians are even part of the deal.
The comparison seems apt because France is now filled with large
chunks of concrete, with no budget to get rid of them. I fear that,
once we win the crypto war against our own government ("Give me crypto
or give me death!") the crypto landscape will be littered with large
chunks of concrete. Heck, it already is -- look at the sorry state of
cellular phones, or Internet communications.
--
-russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Building crypto archives worldwide to foil US-built Berlin Walls
Enzo Michelangeli writes: JYA and others, The first Hong Kong free crypto archive is up and running at: ftp://ftp.futuredynamics.com/freecrypto/ At the moment I'm just mirroring ftp.pgpi.com (about 119 Mb). More stuff will be hopefully added later. Also, I hope to announce more sites soon. Here's a suggestion I don't have time to implement (ideas are cheap): Create a system of mirrors where files cannot be removed, only repudiated. Have a single piece of software which is 1) distributed in the archive, and 2) when installed, creates and publishes a local archive. This piece of software checks other archives, and incorporates content from those archives. This kind of archive has a problem akin to the key distribution problem (call it the archive anti-distribution problem). How do you keep people from wantonly adding things to the archive? Perhaps an archive would have a list of signatures for which it is an archive? -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Is a serial cable as good as thin air?
Arnold G. Reinhold writes: I am uncomfortable with the tone of this thread. There is nowhere near enough information provided in Mr. Georgoudis' posting to conclude that hisbank's existing floppy disk transfer scheme is secure, much less render an opinion on the impact of a serial connection. :all). Here is the question: Is this as good as thin air? He didn't ask if it was secure. He only wanted to know if a serial connection could be made as secure as a floppy disk transfer. I contend that an xmodem transfer of the file is as secure as a floppy disk transfer. The truly paranoid would insert a PIC chip which enforces that only the xmodem protocol could transit the wire, and then in only one direction. Sure, the floppy disk transfer could be insecure, but as you say, he neither gave us enough information, nor asked if we felt it was secure. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
RE: Is a serial cable as good as thin air?
Brown, R Ken writes: If I was a bank I would be very wary of proposals like "We would write our own transmission protocol. " That seems to introduce yet more complexity, not to mention maintenance effort and undiscovered bugs. It would seem safer (more conservative a bank might say) to use off-the-shelf code which had been tried and tested ( for which source code was available if you really cared about security) Use xmodem. Only provide the receive code and the transmission code on the respective sides. That will be as safe as sneakernet. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
