April RSA, Cypherpunks Meeting Schedule - Request for Comments?
The 2001 RSA Security Conference will be April 8-12 in San Francisco. http://www.rsasecurity.com/conference/ The Bay Area Cypherpunks monthly meeting is normally the second Saturday, except when there are major conferences in town. If you're visiting the area that week, are you likely to be here for the weekend of the 7th or the 14th? Enough Usual Suspects are expected to be in town the 7th that if we don't move the meeting, we'll probably do a get-together at a nearby brewpub. Passover starts the weekend of the 7th/8th and ends the weekend of the 14th; Easter is the 15th. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: electronic ballots
At 05:28 PM 1/25/01 -0600, (Mr) Lyn R. Kennedy wrote: On Thu, Jan 25, 2001 at 01:03:49PM -0500, William Allen Simpson wrote: I've been working with Congresswoman Lynn Rivers on language for electronic ballots. My intent is to specify the security sensitive information, and encourage widespread implementation in a competitive environment. We'd like feedback. It seems that something like a smartcard would be the best scheme. The card would have to be able to encrypt the vote and sign it. An observer would need an additional card to sign votes. This would allow a voter to vote from almost anywhere and coercion could be defeated by going to another place and voting in front of an observer. But that would only work if you distribute cards to voters, which gets awfully close to creating a national identity card. Also, a smartcard is easily transferred from one person to another, so votebuying becomes convenient and automated - especially if you don't have passphrases, or if you write them on the card. If you limit use to authorized polling places, you could put the voter's picture on the card to reduce that problem, but that increases the privacy problems. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: small crypto that isn't predictable
This is more of a cryptography question than a coding question, so I've Cc:d [EMAIL PROTECTED], and you may want to shift the discussion there. How small do you need? And how unpredictable? RC4's pretty small, though it has issues with how you use it. DES isn't really all that big these days - I think I've seen it in 10 lines of obfuscated Perl. Some of the AES candidates were pretty tight. What're your application and your threat model like? At 06:00 PM 1/23/01, John Kedzie wrote: I am looking for an algorithm, as small as it can be (code size), as long as it can withstand the following: if an attacker has access to the plain text, and can see the outgoing ciphertext that is created by the plaintext, but he does NOT have the key used to encrypt, is there any way that if he sees the plaintext another time, he can predict what the ciphertext will be? i need something where when you encrypt one time with the same key, the ciphertext will change every time, if that's not possible, the closest possible thing to it will have to do. any suggestions? (would TEA work? i'm only suggesting it because it easily meets the size req, but i am unsure about the second part of my problem) I'm puzzled - are you asking for an algorithm that, given the same input, will produce different output on different runs? Doesn't make much sense Or are you asking for an algorithm that, given different inputs and the same key, produces different outputs? If you're looking for the former, it's somewhat equivalent to asking for an algorithm that has two key parts, one reusable and one non-reusable (as Jim Gillogly mentions below). Many algorithms support block chaining modes that can do this, but it does increase the length of the cyphertext by one block - you'll have to decide if your algorithm minds this. At 07:00 PM 1/23/01 +, Jim Gillogly wrote: You can use any cipher with a random IV included in the key and exposed in the ciphertext, such as CipherSaber, an RC4 based system: http://www.ciphersaber.gurus.com/ . RC4 has one basic rule - never EVER use the same key twice, because it's a stream cypher that works by XORing the input data with a pseudo-random stream derived from the key. Using the same key twice opens up many different attacks on the (plaintext1 xor plaintext2) stream. If you've got room for an IV, you _could_ do something like XORing the IV with the key, not the data stream - that means that it isn't really using the same algorithm for the IV as for the rest of the data stream, but you may not care. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Cryptographic Algorithm Metrics
Single DES is obviously a mistake - the "24 hours/$200K"
limit is so closely what it took to crack DES,
using either the EFF's ~$250K cracker or
Distributed.net's internet-based crack,
that it's clearly referring to DES.
Back when DES was _designed_, it was computationally
secure, for values of "short enough time" up to
about 20 years, but no longer.
RSA is only conditionally computationally secure,
because you can choose key lengths -
384-bit keys are crackable, 1024-bit keys are not.
3DES keys are long enough; Skipjack keys aren't quite.
But even 3DES and Rijndael are crackable if you pick your password
out of a small dictionary.
The "Very Weak" category includes the "Buy Ian Lunch" attack,
which works for the GSM A5 algorithms,
and a few variants like the "Buy Rivest or Shamir Dinner" attack
for somewhat stronger algorithms (the $20K includes
you flying to Boston or Israel while they work on the problem),
or the "Buy Me Coffee" attack for much weaker problems :-)
At 11:11 AM 1/3/01 -0500, John Young wrote:
A cipher is Computationally Secure (CS) if it cannot
be broken by systematic analysis with available
resources in a short enough time to permit
exploitation. Examples: DES and 3 DES.
A cipher is Conditionally Computationally Secure
(CCS) if the cipher could be implemented with keys
that are not quite "long enough" or with not quite
"enough" rounds to warrant a CS rating. Examples:
SKIPJACK and RSA.
A Weak (W) cipher can be broken by a brute force
attack in an acceptable length of time with an
"affordable" investment in cryptanalytic resources
(24 hours and $200K). No examples.
A Very Weak (VW) cipher is one that can be broken
by determining the key systematically in a short
period of time with a small investment (8 hours
and $20K). No examples.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Fwd: from Edupage, December 22, 2000
At 02:42 PM 1/3/01 +0100, Jaap-Henk Hoepman wrote: On Tue, 02 Jan 2001 12:03:40 -0800 David Honig [EMAIL PROTECTED] writes: At 10:27 PM 1/1/01 +0530, Udhay Shankar N wrote: Did this slip between the cracks in holiday season or has it already been discussed here ? Its just yet another 'secure' scheme that uses quantum theory (here, discrete photons; elsewhere, entangled photons) to detect or prevent leaking bits. More elegant than gas-pressurized, pressure-monitored 'secure' cables, but the same idea. Except that eavesdropping on the quantum key distribution channel is _always_ detected (by `laws of nature'), which is not true for these pressure-monitored cables. The theoretical difference _is_ there, but from a practical perspective, both are so inconvenient or expensive that even the very paranoid won't use them, and the moderately paranoid can use multiple encryption algorithms and overly-long keys. If you suppose that quantum crypto hardware becomes medium-cheap, people who are connecting RF-shielded cages together over distances of a hundred meters to a hundred kilometers (if the quantum crypto can go that far unamplified, otherwise ~2km) may find it more practical than pressurized cable. If you're going less than a hundred meters, stick to pressurized cable and armed guards :-) Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Is PGP broken?
At 10:06 AM 11/29/00 +0100, [EMAIL PROTECTED] wrote:
You have to agree that the "not using patented algorithms" thing
solves the problem once and for all, if in a somewhat Gordian way
(partly breaking backwards compatibility). We would never had any
problems if not for PGP screwing it up -- by using potentially
problematic pieces of code.
PGP1.x used Bass-O-Matic, which had no patent problems :-) Also RSA,
which had far more serious problems in the US than mere patents.
PGP2.x used IDEA, which was patented but free for non-commercial use,
and used RSA blatantly and unapologetically in violation of patent,
so the restrictions on IDEA were mild in comparison.
PGP 2.5 and later used RSAREF in the US, which could be used for free
for non-commercial use, still more restrictive than IDEA,
but had copyright problems outside the US, because of RSA's license.
The PGP 2.6.x international versions used homebrew RSA implementations,
which were patent-free outside the US (except maybe for Canada, I forget),
but still used IDEA, which is patented in Europe, US, and a few
other places, but not everywhere in the world.
As PGP's track record went from "angelic"
to "distinctly tarnished", I stopped using it. Many other people I
know did as well. I've switched to GPG, which hasn't got any track
record so far, once it became stable. We'll wait and see how they do.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: migration paradigm (was: Is PGP broken?)
At 03:43 PM 12/6/00 -0600, Rick Smith at Secure Computing wrote:
At 05:04 PM 12/5/00, Ray Dillinger wrote:
If someone wants to enter "sex" as a password, s/he deserves
what s/he gets (although you may put up an "insecure passphrase"
warning box for him/her).
The problem is that there's no objective way of knowing when a passphrase
becomes 'insecure' since it depends on the amount of effort an attacker
wants to spend trying to crack it. Going after Bill Gates' passphrase may
yield more value than, say, my 12-year-old son's passphrase.
A more important problem with passphrase-based keys is collisions -
two people picking wimpy passwords can end up with the same keys.
This means that you need to use something besides the key to differentiate
between the users. It's not always a problem - if you've got your
database of known public keys sorted by email address, it's ok,
but if you've got it sorted by public key, you may have a problem.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Is PGP broken? - public keys in every message
-- 2
At 12:01 PM 12/3/00 -0800, Bram Cohen wrote:
A problem with including a public key with every plaintext message is that
it isn't very discreet - actually looks kind of ugly in some peoples's
email clients. This could be changed by making a header line saying
something like X-accepts-crypto, and have other mailers only send their
keys to addresses they've formerly gotten mail with that header line from.
One nice thing about Elliptic Curve crypto is that the keys are nice and
short.
This makes it much easier to use the whole key instead of PGP-like KeyIDs,
and makes it easier to do signatures that aren't aesthetically annoying.
Here's an example of a document signed by James Donald's Crypto Kong,
from his page at http://www.jim.com/jamesd/Kong/Kong.htm
--
Example signed document.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
BSvaK4MOZ2HQvr15n12Wn//srJ0bGg0SBsjB0i7z
9DzVhXhT9dtOvXQsvNgW9fxxzbg1MahNdUf/jGDb
The first lines of mmencode is the key and the last two are the signature.
Kong has its problems (including being Windows-specific),
but it's an interesting experiment in crypto user interface.
(Also, there's a real question as to what version is what -
the web page says "1.1.2", the Download page says "1.1.1",
and the code I actually downloaded says "1.1.3", so I hope it's not a hoax.)
--digsig
[EMAIL PROTECTED]
DBY838ylRbu3lT5qQ5kM6XI++JHR0NBZtaQ52Egs7Vq
KcdeXicUTIlSnilH+vKrYZJjNTTRlyOemCgX/z5M
4cko2RYx7R+ZRoVTBDDDu0TIrXfAwscgUjSH733Pw
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: reflecting on PGP, keyservers, and the Web of Trust
At 08:45 AM 9/4/00 +0200, Jaap-Henk Hoepman wrote: What's wrong with the PGP wrappers for Outlook or Eudora? They looked quite usable and user friendly to me - as far as any secure email product could ever be completely be user friendly... The user has to do more stuff than usual, and has to have some understanding of what is going on in order to judge whether his/her security requirements have been met. There are some things they're good at; others that they're not. If you've already got somebody's public keys in your keyring, the Eudora versions work fine. If not, then you need to fetch and verify the key somehow - they're not so good at that. Older versions of the Eudora implementation are good at processing keys included in messages into your keyring, but are useless at verifying signatures on signed messages when the only copy of the key you have is in the message itself. I've recently installed 6.5.8 (still Eudora 3.x), and it's improved a bit, but I haven't tested it extensively. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: I foresee an increased interest in secret-sharing
At 11:48 AM 9/7/00 -0700, Ray Dillinger wrote:
On Thu, 7 Sep 2000, Matt Crawford wrote:
If it takes the conscious participation of 10 employees to divulge
a key when demanded, it will be that much harder to prosecute for
"tipping-off".
It's not clear to me how you could set up a situation where one
employee was able to *use* the key, and access encrypted data,
but it would still take ten employees to *divulge* it.
The issue is tipping off the key's owner.
If Alice's key is secret-shared among Bob,Carol...Katy,
to subpoena Alice's key, you either need to ask Alice,
which lets Alice know she's a suspect, or else you need to ask
the other 10 people, which you might be able to do quietly.
Alice knows all of Alice's key, so she can use it,
but the other 10 people only know shares of the keys.
Of course, with 10 or 100 shareholders, word will
probably get around to Alice that she or somebody's a suspect.
This is especially effective for signature keys used to
authenticate Diffie-Hellmann key exchanges, because neither method
of obtaining Alice's key lets you decrypt past messages -
it only lets you forge future messages through your Man In The Middle,
so if Alice knows she's a suspect, she can issue new signature keys.
It's much easier to argue in court that confiscating a signature key
is unfair and ineffective and leads to forgery, unlike an encryption key
which might assist the police in their investigations.
(But you can only do that if you're aware that it's being taken.)
A secret-sharing strategy *should* include the company's legal advisors
and upper management, who have a need to know whether the investigation
is likely to divulge legitimate corporate business or
whether it's just about Alice's side activities selling broadswords
to the Scottish Liberation Army.
Also, they have a legitimate corporate need to know that
Alice may be unexpectedly taking a long vacation and that they
should find somebody else to handle her job while she's away.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: PGP ADK Bug Fix
At 10:33 AM 8/27/00 -0400, Arnold G. Reinhold wrote: How hard would it be to filter the public key servers for unsigned ADKs and either notify the keyowner or just remove the unsigned ADKs? The cert containing the unsigned ADK could be moved to a separate key server, equipped with suitable warnings, so the forensic record would be preserved. The philosophy of the keyservers is that they only provide distribution and convenience - the security of using a PGP comes from signatures. If we've lost the security of the PGP signature system, at least for DH keys, then perhaps they can help, but that doesn't tell you if there are already-distributed keys containing ADKs. ADK-infected PGP keys can still be used for signatures and keysigning, just not for encryption keys. Fortunately, the RSA patent expires Real Soon Now, so we could start widely redeploying RSA keys. (Unfortunately, the old-style RSA keys had format bugs too, and they use MD5 which is moribund.) The real question is whether somebody will hack the keyservers to eat ADK keys before or after somebody downloads all the DH keys, adds ADK keys to them, updates the servers, and threatens to publish Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Using signature-only certs to authenticate key exchanges
At 07:39 AM 8/17/00 +0800, Enzo Michelangeli wrote:
My question was about the legal meaning, or, better, prevalent legal
interpretation, of "signature-only key". ...
This is not a purely academic issue. For example, in Hong Kong the import of
cryptographic devices is exempted from import licensing (not a big hurdle,
but an annoying bureaucratic procedure nevertheless) if they are "only used
for authentication or digital signature":
Ah. The certificate structure - keys, software, smartcards, data, etc.
can all work fine as signature-only, so it sounds like it'll pass your
import license issues. On the other hand, the Diffie-Hellman key exchange
itself,
and the symmetric-key application that uses the key generated by DH,
aren't signature-only systems - they're clearly for doing encryption.
So you'll need to keep track of which pieces are integrated and which
are separate.
Do your import restrictions apply to intangibles like downloading software
in the net? Some places only restrict import/export of physical objects.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Using signature-only certs to authenticate key exchanges
If you ignore standards for the moment and think about requirements and threat models, you need to do the following: - protect against passive eavesdropping (so use crypto) - exchange keys securely (so use Diffie-Hellmann) - prevent man-in-the-middle attacks (so sign the DH parameters) - only talk to people you know (optional)(again, sign the DH parameters) - prevent public-key substitutions (check certificates or whatever.) So you're not encrypting a key for transmission - you're only signing DH keyparts, and a signature-only key and cert should be fine. It's also particularly useful if you live in nosy jurisdictions like the UK that want you to hand over your private encryption keys, because the DH keys are ephemeral and not saved, and your signature keys can only be used for forgery, not decryption of previous traffic. At 11:03 AM 8/15/00 +0800, Enzo Michelangeli wrote: If I use a signature-only cert to authenticate a D-H key exchange (e.g., in IPSEC, or SSL with ephemeral DH ciphersuites) am I in violation of any licensing condition and/or, when applicable, export regulation? I'm asking because MS seems to suggest that for Win2K's IPSEC stack a signature-only cert would suffice: http://www.microsoft.com/WINDOWS2000/library/planning/security/ipsecsteps.as p [...] Here are the requirements for the certificate to be used for IPSec: Certificate stored in computer account (machine store) Certificate contains an RSA public key that has a corresponding private key that can be used for RSA signatures. Used within certificate validity period The root certificate authority is trusted A valid certificate authority chain can be constructed by the CAPI module [...] Cheers -- Enzo Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: What would you like to see in a book on cryptography for programmers?
On Thu, 10 Aug 2000, Michael Paul Johnson wrote:
What would you like to see covered in a practical book on cryptography for
programmers?
- Some fundamentals of groups and fields.
- Provide all your code examples on the web.
At 03:37 PM 8/10/00 -0400, dmolnar wrote:
* Discussion of crypto libraries available (say an updated version of
Shostack's comparisons), with attention to licensing issues.
Discussion of multi-precision integer libraries available for
various languages. Also their performance on various OS and
chip combinations.
* What is and is not provided by a library. What should a programmer
expect to write? what should he or she certainly not try to write?
- A general discussion of ways of moving data through programs :
besides the standard "read N more bytes, call crypto function, output",
it's worth looking at Raph Levien's stream-oriented libraries,
as well as OpenSSL and other packages.
- Environments crypto applications will be used - batch file applications,
real-time speech/video, file system drivers, browser plugins, TCP/UDP
daemons -
differences in handling data flows and memory management, ways to screw up.
- A discussion of parameter negotiation techniques - obviously different
for batch and interactive connections.
- Threat scenarios for everything - the Photuris papers have some
good discussion on designing protocols to avoid resource-burning DOS's.
* Practical details of encoding schemes which may come up in practice
(such as what ASN is, how to use it, whether you need it, etc).
- Not just ASN and how to avoid it, but also portability,
representation of simple numbers and strings (e.g. the benefits of
PGP's ugly compressed number approaches and why you shouldn't use them :-)
Stealthy vs. non-stealthy representations, etc.
* Lots of examples of how to screw up in subtle ways. Either
cryptographically (e.g. not verifying that a particular
element is a member of a subgroup or something else sneaky)
or with the language (buffer overflows).
Especially examples of tempting, but wrong, things to do.
Some theoretical focus on snake oil - particularly material about combining
algorithms, and about combinations of LFSRs or other simple PRNG algorithms
not being any stronger than the basic algorithms, since this is a popular
snake oil approach.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Weak user keys, strong servers.
James A. Donald: The problem is that I assume that people find each other's IP and transient public key through the server. I also assume the user's computer is insecure, the user is ignorant and careless about security and the user may change computers from time to time. Thus his public key has to be transitory. Thus the server can mount a man in the middle attack. Are you assuming that the user's computer is fast, but the user is dumb, or are you assuming that the user's computer is also limited, e.g. a smart card? If the problem is just the user choosing a wimpy passphrase, but the user's machine is fast and has some entropy available, have the user's machine generate a random key and combine with the passphrase, using your favorite hash, and store the generated key in some manner that can be accessed by a user who knows the passphrase, e.g. 3DES(genkey, hash(pass)). That way, the server hasn't contributed anything it can use in an attack. Alternatively, if there's no better entropy source, you could also have the user's machine ask the server for some random bits, and then hash them up with whatever else is available (if nothing else, the message it's trying to send), though that lets an eavesdropper do the dictionary attack on G**(hash(p,bits)) which is at least slow. If you want the public key to be always reproducable from the passphrase, which is one of the modes I liked in Crypto Kong, this may not be usable, but I'm assuming you're trying to do something different. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: FBI announcement on email search 'Carnivore'
At 10:27 PM 7/16/00 +0100, Ben Laurie wrote:
Lucky Green wrote:
In
particular, the "black box" monitoring device installed at the ISP level
appears to be in the process of becoming the implementation of choice.
Pioneered by Russia, this design has rapidly been adopted by the UK, and
now
is used in the US.
This may be a nit, but there are those of us who hope it is a nit of
significance: unlike Russia or the US, the black box monitoring device
is still a twinkle in the eye of the spooks in the UK. RIP is not yet
law, and when and if it is, it may not include provision for such a box.
Yes, but now that the US has legalized export of crypto hardware to
EU and other friendly governments, they can have 10 of them there overnight
:-)
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: GNU Privacy Guard license question
At 11:30 AM 06/12/2000 -0400, P.J. Ponder wrote: from the documentation for GnuPG: http://www.gnupg.org/gph/en/pgp2x/t1.html | Note: Using the extension modules idea.c and rsa.c without licensing the | patented algorithms they implement may be illegal. I do not recommend | you use these modules. If you have PGP 2.x keys, I suggest you revoke | them in favor of new keys and encourage correspondents who use PGP 2.x | keys to do the same. Is this right? If one obtained PGP 2.x legally, and used RSA and IDEA in conformance with the original license for personal use, would that license permit the use of the older PGP keys with Gnu Privacy Guard? RSA and IDEA are totally separate issues. I don't know when the IDEA patent expires (probably randomly different in Switzerland, the US, and elsewhere), but you're bound by whatever limits the old license used. RSA patent expires this summer (Yay!) But code that's based on RSAREF is covered by copyright, so it's still limited by the RSAREF license. If you're using non-RSAREF code, it goes free when the patent expires. So use the non-RSAREF versions. As far as the older keys go, you'll be able to use RSA keys after the patent expires, so if you don't need IDEA, e.g. for signatures, or for non-IDEA encryption, you're fine. Also, remember that MD5 is pretty dodgy these days, so you'll want to convert to SHA-1 forms as soon as possible. I don't have a copy of the old PGP license around. I presume one could continue to use PGP 2.x indefinitley under the old license. Yup. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: NSA back doors in encryption products
At 02:08 PM 05/24/2000 +0100, Ben Laurie wrote: John Gilmore wrote: Anybody tested the primes in major products lately? Interesting point ... of course, these days one can produce checkable certificates of primality - but I'm not aware of any free software to do it ... is there any? There's primality testing software in PGP's key generation routines, and also in the GIMPS Great Internet Mersenne Prime Search software. It's not designed for an independent input of test material, but that's not a tough thing to add wrappers for. I think somebody also did an N-Lines-Of-Perl version. GIMPS uses Lucas-Lehmer tests; I forget if PGP uses that or Miller-Rabin. It's a probablistic primality testing system, and if you wanted to do a widespread-use backdoor-checker, it might make sense to use some test primes in the usual sequence and some chosen at random. IIRC, Technically, it won't catch use of Carmichael numbers, but there aren't a lot of those. More seriously, there's David Jablon's point that it won't catch use of real primes from a small search space or other RNG tricks. Is it time for the Campaign for Real Primes[1]? [1] Apologies if this quip dies in translation! :-) The Campaign for Real Ale was a Good Thing... Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: From NewsScan: new EU export rules...
At 11:20 AM 04/28/2000 -0700, Eric Murray wrote:
The new EU rules eliminate
the need to secure approval from national licensing bodies and do away with
security checks for all encryption products with the exception of so-called
crypto-analytic tools, which can be used to test systems and crack codes.
What? That's a new one!
Could it be that certain large organizations(GSM) who have been
embarrased(A5) added this as a way to discourage/prevent exposure
of their weak crypto?
Yes - that means that Europeans will need to import their
cryptanalysis tools from Berkeley or Montreal, or wherever the
Party At Ian's Place is this week, except when Lucky and Ian are in Europe :-)
(In that case they'll need to import from Boston.)
It also means that EU security-by-obscurity products will be at a
competitive disadvantage against non-EU products that can use
automated tools for testing, and the Bad-Crypto-Cracking business
will have to move to non-EU countries, or hire mathematicians in India...
Steve Bellovin wrote:
The WSJ story said that "France demanded this exception because the
country is concerned that some of its communications could be vulnerable
to hacking by Corsican terrorists."
Yow! Corsican hackiere-terroristes will certainly be stopped by that!
They'd have to download GSM-crackers with instructions in English
instead of French or Italian!
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Automatic passphrase generation
At 11:42 AM 05/10/2000 +0200, Sergio Tabanelli wrote: Perhaps this can be out of topic, but recently I was involved in a discussion on metods to generate strong password starting from easy to remember word or sentence, there I proposed to use a private key to encrypt easy to remember words. Is this is a valid or applicable metod? [Ex Nihil, Nihil. If you start with only the universe of easy words, the maximum entropy of your passphrase is is limited. Pull, stretch, squish and mangle it any way you like -- you cannot increase the entropy of something by a deterministic algorithm. You can at best obscure it well --Perry] Steve Bellovin's Encrypted Key Exchange (EKE) and some related protocols including A-EKE and SPEKE provide various ways to use a short shared secret with random numbers and Diffie-Hellman to provide a stronger key exchange than the shared secret alone could do. The main objective is to make it safer to use human-rememberable passphrases with low risks from attacks like dictionary search. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: GPS and cell phones
That doesn't mean that the author isn't mixing up two concepts -
GPS vs cell phone location by the phone system's signalling.
GPS burns too much power to be used in typical cellphones -
most of the cheap GPS sets I've seen get 24 hours or less on
a pair of 1.5v AA batteries, while cellphones should last several days
to a week (at least any cellphone I'd buy...)
On the other hand, cellphone systems do track which cell sites their
users are near, and can track motion over time, though this
may not be accessible from the phone's user interface,
and may require integration between cell sites rather than
being something the phone set itself knows how to do.
GPS improvement helps locate cell sites more precisely,
(though differential GPS can do that at installation time)
and improving GPS may improve the timing that the cell sites can do.
The real problem is that cellphone standards committees
need to recognize the need for privacy - they're currently being asked
to build in location features that don't inform the user
when the user's being located, if I understood one of Lucky's comments
correctly, and they didn't understand why this might bother people
If the location is something the phone set can do, it ought to
require explicit user permission for location - and also ought to
let the user find out where the phone thinks it is.
At 11:06 PM 05/09/2000 EDT, [EMAIL PROTECTED] wrote:
I came across this in my local newspaper and figured it might be of some
interest. Earlier, on this thread, I received an email regarding Motorola's
patents and the government using that information to track cell phones. It
seems they have expanded their power a bit:
"Manufacturers of cellular telephones, who will be required by the Federal
Communications Commission next year to make sure all cell phones are capable
of revealing their positions, will benefit from the increased accuracy as
well."
-Baltimore Sun (Monday, May 8, 2000)
The article mentioned accuracy is now around 48 to 60 feet of resolution due
to the decrypting of civilian GPS signals.
Bob
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Planned Net-treaty limits privacy, may compel key disclosure
At 11:18 AM 05/03/2000 -0400, Richard D. Murad wrote:
Does obligations through treaty circumvent US law and US
constitutionality? In other words, if the US signs and ratifies a treaty,
does it take precedence over other US law?
If so, it's a way to do an end-run around US law and US constitutionality.
This is really a better question for cypherpunks that cryptography,
and I'm planning to write a rant there.
The US government doesn't have the authority to make
unconstitutional laws. Doesn't mean they don't try on occasion (:-),
but they don't have the authority to do it, whether they're
regular laws or treaties or the laws implementing treaties.
Also, the Senate has to approve treaties, though they often
rubber-stamp them, just as they often give blanket regulation-making
powers to various bureaucratic agencies.
On the other hand, "US law" just means "the laws the politicians have
made so far", which is a moving target - they can change them
any time they want, though some laws are sufficiently
entangled with other laws or political agendas that it's sometimes hard.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Article about TriStrata in Fortune
It's also referenced on Slashdot.
I tried to get somebody from Tristrata to talk to a
Cypherpunks meeting last summer, but timing didn't work out.
Little did I know what was going on under the surface :-)
At 10:17 PM 04/09/2000 -0400, Richard Stiennon wrote:
*That* was entertaining reading. Articles like that are always more
interesting if you know the players. I remember being in one of
the first groups to go to the "Tristrata Academy" to get educated. The
training was pretty high level and did not go deep enough into the guts of
the
algorithms for us to judge their validity. Dr. Atalla was introduced as
a multi-billionaire (not just $20 million as the article reveals).
I remember thinking "I am not expert enough to poke holes in this, but I
*do* know the folks on the crypto lists are going to eat these guys for
lunch!" :-)
"Perry E. Metzger" wrote:
Some of you may remember a certain pseudo-OTP snake oil vendor called
TriStrata. This article in Fortune tells the story of their rise and
fall...
http://www.fortune.com/fortune/technology/2000/04/17/boo.html
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Junger wins in Appeals Court - Junger v. Daley, 6th Cir. 4/4/00
Peter Junger's export case just won in the Appeals Court! Yee-hah!
: Junger v. Daley, 6th Cir. No. 98-4045
: http://pacer.ca6.uscourts.gov/cgi-bin/getopn.pl?OPINION=00a0117p.06
: http://pacer.ca6.uscourts.gov/opinions.pdf/00a0117p-06.pdf
: "Having concluded that the First Amendment protects
: computer source code, we reverse the district court
: and remand this case for further consideration of
: Junger's constitutional claims in light of the amended regulations."
...
: Because computer source code is an expressive means for the exchange of
: information and ideas about computer programming, we hold that it is
: protected by the First Amendment.
To clarify what's going on, I wrote to Peter
: Am I correct in my understanding of the actions?
: - Peter Junger filed in Federal District Court for Northern Ohio
: - Court awarded summary judgement to the Bad Guys
: - Junger appealed to the 6th Circuit Appeals Court
: - The Appeals Court just decided the Constitutional issue of law,
: holding that source code is protected by the 1st,
: reversed the summary judgement, and
: remanded to the District Court
And he replied
Right
: - The District Court now needs to hold the full hearing,
: but given the important finding,
: it should be a slam-dunk for Junger?
The remand is partly to determine the effect of the new regulations.
The lawyers are going to have to decide what we will do next. I
am just a satisfied client.
But just because the new regulations are such an improvement, the
really significant point is that we now have a circuit court decision
holding the computer programers are entitled to the same constitutional
protections that pornographers receive.
: Or can Junger file to get a summary judgement in his favor?
I suppose we could, don't know if we would.
: - If the Feds still want to appeal, they've got to
: go to the Supreme Court? (Or win in another Circuit first
: and then try appealing to the Supremes?)
Yes. But they may want to see what happens on remand before appealing.
(And, of course, it is theoretically possible that we would lose on
remand.) In that case the appeal would be back to the Sixth Circuit.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
ANNOUNCE 4/8 Bay Area and Toronto Cypherpunks Meetings
This is a pre-announcement for the April 2000 Cypherpunks Meetings.
The Bay Area meeting will be held in two places at once,
April 8, 2000, 1-6pm.
The 10th Computers, Freedom, and Privacy Conference http://www.cfp2000.org/
will be in Toronto April 4-7, and many of the Usual Suspects will be there
April 8th, so there will be a Cypherpunks Meeting (and Party at Ian's Place.)
Dave Del Torto is coordinating the agenda; possible location City Hall.
The Bay Area instantiation will be at Fort NOCs, 19925 Stevens Creek Blvd,
Cupertino.
Bill Stewart is coordinating the agenda.
Cindy Cohn will be speaking about the Bernstein Case's current status.
The detailed announcements for San Francisco and Toronto
will be mailed to meetingpunks and cypherpunks lists, and posted at
http://www.cryptorights.org/cypherpunks/meetingpunks.html
Dave [EMAIL PROTECTED] and Bill [EMAIL PROTECTED] would both appreciate
speaker volunteers and other related event announcements.
If there's Internet access at the Toronto location,
we may be able to arrange connectivity.
---
Map of 19925 Stevens Creek Blvd, Cupertino
http://maps.yahoo.com/py/maps.py?Pyt=TmapYY=17435addr=19925%20Stevens%20Cr
eek%20Blvdcity=Cupertinostate=CAslt=37.3232sln=-122.0218zip=95014-2305
mag=9cs=9newmag=7
---
This email was sent to the meetingpunks list,
cypherpunks-announce, cypherpunks, [EMAIL PROTECTED], and a few Bcc:s.
To UNSUBSCRIBE an address from the meetingpunks list send email to:
with "unsubscribe meetingpunks " in the BODY.
To SUBSCRIBE an address to this list send email to:
with "subscribe meetingpunks " in the BODY.
To contact the list-owner, send email to .
To get off the other lists, send mail to cypherpunks-request
at the machine that mailed you the announcement, saying "help".
---
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: secret-sharing code
At 04:59 PM 03/29/2000 -0800, John Gilmore wrote:
Are there any freely-available secret-sharing packages around?
Specifically,
I need to be able to set up modestly complex policies to protect a
sensitive
signature key.
I use Hal Finney's "secsplit". Google found it in a couple of places; it
doesn't seem to have been updated since 1993.
This is why I don't recommend secret-sharing for important DNSSEC
private keys. Using infrequently maintained software increases the
risk of losing the key, perhaps years from now when you suddenly
decide you need it.
. [suggested plan, deleted].
I'd put it as ink on good paper inside steel, rather than rely on some
obscure
secret sharing software from ten years earlier, that won't run on
modern bloodstream-resident computers.
Modestly complex policies probably require real software,
particularly if you're trying to be efficient and fast.
But for John's problem, it makes more sense to go for simple.
For the long term, it's much more likely that any computer media
will be hard to find usable readers for in the future,
and complex data formats like PGP's and X.509's ugly bit-twiddlers
make it *much* more difficult to use. The fundamental algorithms
for secret-sharing and RSA can all be done with bignums
and short paper documentation, and you can do the complex parts
(e.g. good random number generation) up front with your existing tools
and keep the downstream work to simple stuff.
If all you need is to do N-Way splitting, without M-of-N redundancy,
generate N-1 nonces the same length as the secret, and calculate
Share1 = Nonce1
ShareN-1 = NonceN-1
ShareN = Secret Xor Nonce1 Xor ... Xor NonceN-1
print them on paper with an indication of what they are
and the algorithm used and where the parts are stored,
store securely, and when needed, calculate
Secret = ShareN Xor Share1 Xor ... Xor ShareN-1
A crude redundancy approach is to just store two copies of each piece,
which should be adequate if you're just splitting a few ways.
If you really need M-of-N for reliability, use Shamir sharing,
and make sure all the secret-reconstruction calculations can be done by
any convenient bignum calculator (as opposed to the XOR method,
which can be done by hand or abacus :-)
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: secret-sharing code
At 08:31 AM 03/30/2000 -0600, Matt Crawford replied to John Gilmore:
Keep the meta-root private key under very very high security (my
recommendation was to embed it in the structural members of a
skyscraper, such that anyone who tried to get it -- the legitimate
owner or anyone else -- would have to make a lot of noise for an
extended period, in a very public place).
You need to see more stage magic. The theft or copying would be done
before the steel was welded. To be fair, this bald assertion is
applicable to many schemes in which the complete secret exists
somewhere before it is divided or hidden.
My first reaction to Dorothy Denning's description of the
Clipper Key Escrow Charade In The NSA Vault was that
"PennTeller could find a dozen ways to steal the keys in that process" :-)
(About the same time, Penn wrote a scathing criticism of Clipper
in his computer-magazine column, but he took the moral high road
that escrow is none of their business rather than the "I could steal *that*"
approach :-)
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Encrypting folders in Win95/98
At 01:05 PM 03/13/2000 +0800, Enzo Michelangeli wrote: Does anybody know any good Win95/98 utility providing connectoids seen by the user as folders, so that any file moved to and from them get automatically encrypted and decrypted? Something like Encrypted Magic Folders by PC-Magic, but with a serious crypto engine instead of their proprietary snake oil. Do you really want something that encrypts decrypts individual files? Bad! I tried RSA's freebie that did that, and while it did use real crypto instead of snake oil, it depended on having enough warning to re-encrypt on shutdown (really bad assumption for a laptop), and not encrypting files until they're closed cleanly (really bad assumption on Windows) as well as the extra work of decrypting and encrypting things in advance. One alternative is to use an encrypted diskoid driver that keeps its cyphertext in a file rather than using a full partition, similar to what Stacker and several other disk compression products do. Safehouse and Scramdisk both do this (ask AltaVista where to get them.) They do their encryption on a disk-block basis, not a file basis, and decrypt blocks when reading them off the disk, encrypt when writing, so they're never writing unencrypted data onto the disk. You assign some space on another drive (e.g. C:\MyDocuments\Scramdisk.svl), and when you want to use the contents, you run the mount command, which gives you something looking like a removable drive (e.g. F:\), which you can store files in. I assume you can build shortcuts to point to the disk if you want files to look like they're somewhere else. Some of these products know how to expand their space if they get full, some don't. NTFS has a third approach for compression, and it may also do encryption (though it's probably just MSSnakeOil crypto if it does.) Each file and directory can be vanilla or compressed, and they're decompressed/compressed on the fly when reading/writing, though I'm not sure if it's a block-by-block basis or per-open/close. The user interface is the Windows Explorer file-system browser, which lets you select which files will get treated this way and which are stored as normal uncompressed files; compressed stuff turns blue, and compressed directories automagically handle all the files added to them as compressed. It was a very pleasant way to handle compression (unlike the big Double-Space blocks I needed to set up when I downgraded to Win95), with a lot less administration work needed. If they also did Real Crypto with it, it could be a win. In both the pseudo-disk and NTFS-like methods, you'd have to see how it worked mapping files across a net from a file server. I suspect the pseudo-disk products like Scramdisk do the right thing (or else refuse to work entirely) but I don't know if the NTFS-like systems do the compression on the file server or the client or just refuse to work. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: [FYI] ECHELON for combat of european national culture of bribery?
Well, of course they do. Knowing who to bribe, what they're selling,
and how much they're charging can be really valuable for
"national security" interests - not only lets you bargain down your
bribery payments, but occasionally lets you use blackmail to get
stuff for free :-)
Former CIA Director Says US Economic Spying Targets "European Bribery"
Duncan Campbell 12.03.2000
"We have spied on that in the past. I hope ... that the United States
government continues to spy on bribery."
...
He claimed that economic spying was justified because European
companies had a "national culture" of bribery and were the "principle
offenders from the point of view of paying bribes in major
international contracts in the world".
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Legal/patent analysis of Lucre?
At 10:23 AM 02/18/2000 +, Ben Laurie wrote:
A problem with continued development of Lucre is that various solutions
to the coin marking problem have been proposed, and various opinions as
to the likely patent-infringment-ness have been given, leaving me no
clearer as to what the best way to proceed is.
I'd always assumed that the patent status was
"Deliberately flaunting"
and the author's pseudonymity was partly for that reason and
perhaps partly because the author had worked for Digicash
during the period when almost all digicash-connected cypherpunks
were doing so :-)
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
At 09:15 AM 02/02/2000 -0800, Eric Murray wrote:
Until Intel releases the design for the RNG, I would treat it the same
as any suspect source of entropy- assume that it can contain no
entropy. That means that you whiten its output before mixing it
together with your other entropy sources (some of which you beleive do
provide real entropy) to provide random numbers.
Doesn't this add one more level of isolation than you really need?
I'm reading your statement "whiten before mixing" as
pool = hash1( pool, hash2(intelrng) )
as opposed to the presumably-safe-enough
pool = hash1( pool, intelrng )
which mixes in the raw intelrng rather than whitening.
(Hash1 is abstractly whatever complex mixing process you've got,
including keys, multiple entropy sources, etc.)
Do you think there are attacks where this is really necessary,
assuming the pool is used in some hashed fashion rather than
exposed to the public directly?
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
[SFBCA] Cypherpunks MEETING PRE-ANNOUNCEMENT for 15 Jan 2000
Originally sent to "SFBay Cypherpunks Announce List" [EMAIL PROTECTED] by [EMAIL PROTECTED] Forwarding to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] and a few Bcc:s Subject: [SFBCA] Cypherpunks MEETING PRE-ANNOUNCEMENT for 15 Jan 2000 You can subscribe to SFBCA at mailto:[EMAIL PROTECTED] === Join us for the first Cypherpunks meeting of the new millennium! NEXT Meeting: http://www.freedomfighter.net/cypherpunks/2000/0115.html Meeting Page: http://www.freedomfighter.net/cypherpunks/physical.html SF Bay Area Cypherpunks (80th Chairborne Regiment) 15 Jan 2000 * MEETING PRE-ANNOUNCEMENT The January 2000 SF Bay Cypherpunks meeting will be on January 15th! General Info: For those of you who plan ahead: the January 2000 cypherpunks physical meeting will be on January 15th, the THIRD SATURDAY of January, instead of the usual second Saturday. This will align our meeting with the RSA Data Security Conference in San Jose the following week (registration starts on 16 Jan). Many of the usual cypherpunk suspects from around the planet will be in town. Location: The meeting will be held in San Jose, a few blocks from the RSA conference site. Location details to follow. Time: Meeting time is 12-6pm, followed by a group dinner nearby from 6-8pm. Speakers: (so far...) Cypherpunk Projects: general "Works-in-Progress" session Bruce Schneier (Counterpane) Austin Hill (Zero Knowledge) Paul Holman (Shmoo Group) Adam Shostack (Zero Knowledge) Mystery Guest More Volunteer Speakers are welcome: Send us your agenda proposal (one brief paragraph, include amount of time needed, e.g. 5/15/30 minutes). mailto:[EMAIL PROTECTED]?subject=2000-01-15%20ag enda%20request RSA Conference Vendor Expo Free Registration The show floor will be open January 18th and 19th at the San Jose Convention Center. Onsite Expo registration is $50, but it's FREE if you register NOW at: http://www.rsasecurity.com/rsa2000. Also, you can register for the conference or the IBM gala party at that site.
Re: sci fi (was Re: Onhand, clapping? (was Re: NTK now, 1999-12-10))
At 12:25 PM 12/13/1999 -0800, David Honig wrote:
Has anyone extrapolated from the fact that the more you carry a device with
you, the less physically subvertible it is? Your home machine may be more
robust against that attack than your office machine, e.g., if some friendly
or yourself occupies the house most of the time.
Office PC Home PC PDA dick-tracy watch waterproof dick tracy watch
implant network of implants which monitor
each other (so you'd have to pull all of them at once...)
Yes and no. My laptop is much more likely to get stolen than my home PC
(though less likely to get blackbagged.)
My current PDA is pretty secure, and only communicates by wires,
and my current cellphone is more communicative but only knows my phone list.
But my next PDA will probably do infared, like this wristwatch PDA does,
and the one after that may do Bluetooth or some cellphone protocol,
and they'll probably have mechanisms for downloading firmware upgrades.
So you may be walking down the street or sitting in Starbucks and
some cop or some computer-viking or some industrial data reseller
may "upgrade" your machine by radio or M.I.B. infrared blinkylight widget;
that doesn't even count the e-calendaring services that will add
"Big Sale At Virgin Megastore" or "Happy Hour at Starbucks" to your PDA
as you're walking by.
Infrared's a bit safer - you can keep the PDA in your pocket or carrying
case,
or put black tape over it when you visit the NSA museum (:-),
but Bluetooth is made to work even while it's in your pocket,
and obviously cellphone-related systems need to be on the air,
though they may not support high enough data rates to do drive-by upgrades.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Semantic Forests, from CWD (fwd)
At 10:42 AM 12/02/1999 -0500, Arnold G. Reinhold wrote: http://www.dragonsystems.com/products/audiomining/ "New AudioMining Technology Uses Award-Winning Speech Recognition Engine to Quickly Capture and Index Information Contained in Recorded Video Footage, Radio Broadcasts, Telephone Conversations, Call Center Dialogues, Help Desk Recordings, and More It's easier to do that with single calls than with large numbers at once; scaling can be hard or at least expensive. A T3 carries 672 calls, unless there's voice compression or silence suppression increasing the capacity (which there probably is, for international circuits), and an OC48 carries 48 T3s. So if you need a P133 to track one call, you need about 3 of them to track a wavelength. I suppose that's only a few million bucks if designed efficiently, but that's more than the fiber optic network equipment on each end costs the telcos :-) (plus you need the euivalent fiber optic equipment as well.) This may still be affordable for international circuits, but it's unrealistic for land-based communications. For instance, ATT announced having installed a thousand or two OC48-segments a year, though many long-distance calls go across multiple segments because they're going a long ways. Adds up to a lot of wiretapware. On the other hand, if you're only looking for a small number of Usual Suspects, or can use dialing information or other call setup data to figure out which calls you want to eavesdrop on, the scale becomes much more manageable. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: 128-bit support
At 07:35 PM 12/01/1999 +0800, Enzo Michelangeli wrote: Speaking about which: isn't Certification Authority software subject to EAR export controls? I'm asking because Hongkong Post (the Hong Kong Post Office) has announced that they will start to offer CA services (being in fact the first legally recognized local CA), and will use a system provided by HP. HP swears that there are no backdoors or covert channels to leak bits of the CA's root key, and Hongkong Post believes them, but then I wonder how they got an export license. Software that's authentication only isn't supposed to need an export license - only software that provides data privacy does, and CA products only need to do signatures, not privacy. A CA product using DSA instead of RSA shouldn't have a problem; a CA product using RSA would probably have to demonstrate that it only does signatures and doesn't use the RSA for privacy protection, and might be able to get away with using cryptographic protection for its own certification secrets if it asks nicely. If you're shipping the CA software as a binary, not source, then the non-Yankee CA service provider can't use it to also provide privacy (at least without reverse engineering, which is much more work than just writing new stuff themselves or downloading software from Finland or whatever.) Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: 128-bit support
At 04:33 PM 11/29/1999 -, V.Krishna Reddy wrote: Hello, I am based in India. I would like to know the possibilities of using 128-bit SSL support in browsers and Web Server in India. Is any company (probably outside US) is providing such functionality with which we can enhance the encryption support to 128-bit in IE,Netscape, etc.? Can anybody provide some resources on web where I can find this information. Thanks in advance. Regards. www.fortify.net has free software for upgrading Netscape to 128-bit, for many different versions of Netscape clients. The Apache web server is the standard Linux web server, and versions of it are available with SSL security - since it's source code, you can easily do 128-bit capability. I don't know what laws, if any, India may have about it, but there probably aren't any. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Marked cash in Lucre
At 10:20 PM 11/21/1999 -, Some Ostensibly Anonymous Person remailed an article to coderpunks, which Bob Hettinga reposted to cryptography and probably also to cypherpunks. David Wagner's developed a blinding method probably not covered by Chaum's existing patents, which has been implemented in -Lucre, http://anoncvs.aldigital.co.uk/lucre/. [..There's a Chaum blinded undeniable signatures algorithm which unfortunately fails for digicash use because the bank can mark coins.] It was suggested at the time that David Wagner's blinding was immune to this marking attack. However recently it has been learned that this is not true; the bank can mark cash using Wagner blinding as well. The current Lucre implementation would be vulnerable. ... It appears that there is a simple fix, but other people should look at it ... The proposed fix is to combine the two forms of blinding, Wagner's and Chaum's. Choose two random blinding factors, r and s, and blind by calculating y^s * g^r. [...Details omitted...] By having two blinding factors rather than one, there is one additional degree of freedom There are two issues to deal with - whether the blinding works technically, and whether it's possibly covered by Chaum's patents. After all, the prime importance of Wagner's blinding work was that it hopefully wasn't stuck in the Chaum patent mess. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: DEA says drug smugglers used crypto Net but cops got around it
At 08:21 AM 10/25/1999 -0400, Marcus J. Ranum wrote:
including use of the Internet, encrypted telephones, and cloned cellular
telephones
They don't say what "encrypted telephones" mean, either. Remember,
these are the same guys who try to tell people that spread spectrum
is "encryption" or at least "secure."
Remember that GSM phones and US digital cellphones support encryption.
All broken, of course, but it _is_ encryption.
In some countries the PTT turns off GSM encryption or forces use of A5/2.
In the US, the different cellphone standards support different crypto,
and some cell companies or cell sites don't use it.
I'll bet $100 to a $1 that if there was a way to find out, we'd
find out that the "encrypted telephones" in use in the case in
question were not "encryption" as most of the members of this
list understand it. Is there enough information in Mr. Marshall's
description to be able to associate the FUD with a case and then
find out what kind of evidence they present?
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Almost-Everywhere Superiority for Quantum Computing
Russell Nelson [EMAIL PROTECTED] wrote: If quantum computers make brute-force cryptanalysis tasks easier, don't they also make brute-force cryptographic tasks easier as well? At 01:12 AM 10/18/1999 -0400, Vin McLellan wrote: The problem to worry about, of course, is that maybe not everyone is going to have access to the same oracle. Consider what was involved when the NIST lab at Boulder created a qubit a couple of years ago. As I recall, to get their qubit they had to trap a single atom with missing electrons (an ion) and two energy levels by nailing it down with an array magnetic and electric fields at minus 273 degrees C. For instance, will it fit in your palmtop or smartcard? Probably not. It's not clear that, in practice, it will be possible to get high enough resolution out of quantum computers to affect crypto - a resolution of 20 bits is enough to annoy smartcards by forcing the encryptor to use more key bits, but doesn't bother other computers. A resolution of h-bar is ~10**47 or 150 bits, but by the time we get that much resolution, it probably won't bother palmtops much, except maybe for RSA key generation. Quantum devices with resolutions like that probably aren't small or portable However, if you can get much bigger resolution improvements out of quantum devices without some way to use lower-resolution devices in parallel while still collapsing one big waveform in some kind of Quantum Black Magic. Hard to say if that will be portable or not, or affordable except by large organizations (particularly, even with Moore's Law constantly making things cheaper, will the cost be some large multiple of the cost of small portables, Pocket Area Networks, Pencil Area Networks, RF grocery tags, you-are-here broadcasters on store shelves or license plates, etc. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
RE: Is SSL dead?
At 04:35 PM 10/6/99 , Phillip Hallam-Baker wrote: This is a problem with SSL 2.0 first discovered by Simon Spero then at EIT. It was fixed in SSL 3.0, that must be almost three years ago. The server certificate now binds the public key to a specific Web server address. That means that you can only succeed against web-users whose browsers still accept SSL2.0, which is most Netscape users by default; I don't know if IE also defaults to that, but it probably does. Even if the https://www.target.com uses SSL3.0, the user isn't talking to it - they're talking to https://www.attacker.com, which can use 2.0 if it wants. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
[SFBCA] SF Bay Area Cypherpunks 09 October 1999 Meeting
SF Bay Area Cypherpunks October 1999 Physical Meeting Announcement General Info: Sat 9 October 1999 1:00 - 6:00 PM Mrs. Fields' Cookies shop, near the payphones* Embarcadero 4, Embarcadero Center complex - Ground floor, North side, a few paces east of Drumm and Washington St. - (* Ever been to a 2600 meeting? Same location. Follow your nose.) The October Physical Meeting of the San Francisco Bay Area Cypherpunks will be held on Saturday 9 October 1999 from 1-6 PM. "The court shall enter such orders and take such other action as may be necessary and appropriate to preserve the confidentiality of the technique used by the governmental entity..." -- Section 2716 of the proposed Cyberspace Electronic Security Act As usual, this is an "Open Meeting on US Soil" and, as always, members of the Public and any interested inteligence agency are welcome to attend (preferably in person). Meeting Agenda: "Our agenda is a widely-held secret." 1:00-2:00 Informal pre-meeting gathering - Accepting cookies from strangers, etc. 2:00-6:00 Ian Goldberg - Hushmail, and probably other topics Cypherpunk Legislation-of-the-Month Club: "CESA, the Cyberspace Electronic Security Act of 1999 "Jamming ECHELON Day" (22 Oct) "Disappearing, Inc." mail shredding? The Switzerland of the Net? The Bermuda Monetary Authority and Entrust Cypherpunk Book-of-the-Month Club: "Cryptonomicon" (Additional agenda items TBD on-the-fly at the meeting) 6:00-? Dinner at a nearby restaurant usually follows the meeting (see meeting notes below). Featured Speakers: Ian Goldberg will be consulting in Montreal for the next N months. Meeting Notes: The Weather Underground predicts warm weather and moderate chance of earthquakes Location Info: Southbound on Market St. from the Embarcadero/Steuart. HARD RIGHT on Drumm St. (not left on Spear). BEAT IT down to Washington St. (a block or two). RIGHT on Washington, into cul-de-sac. You can almost smell us from there. (The cookies, that is.) The best way to get to Mrs. Fields' is to park _under_ it in the Embarcadero 4 parking lot, accessible from the cul-de-sac. NOTE: Get your PARKING VALIDATED and it's FREE! Food (non-magic cookies) and beverages are available at Mrs. Fields'. There are several other places nearby to grab a snack during the meeting. Mass Transit From the East Bay, take BART to Embarcadero in SF. From the South, take Caltrain. Due to Construction, trains may leave 10 minutes earlier or later than the www.caltrain.com schedule, and the last few stops are really a shuttle bus. Weekend Caltrain Pass is $5. Location Map(s): Mrs. Fields' Cookies: http://www.freedomfighter.net/cypherpunks/maps/981212.jpg (red star over Mrs. Fields) Collateral Damage, Known Parties, etc. URBAN WASTELAND ENCORE - Sameer Parekh and friends - East Bay 10pm-dawn Call 510.594.4000x217 after 10 for directions. PENSFA at Howard Davidson's in San Carlos 10/16 will have an all-weekend Party at Ian's Friends' Place and a Revel Alliance party in Felton. If you have any questions, please send them to the co-organizers of the mtg: Bill Stewart Cell +1-415-307-7119 [EMAIL PROTECTED] Dave Del Torto [EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Digest: mailto:[EMAIL PROTECTED] List-Unsubscribe:mailto:[EMAIL PROTECTED] s.org But I blasted this to the usual suspects mailing lists as well -- Bill
Re: Ecash without a mint, or - making anonymous payments practical
On Mon, 27 Sep 1999 [EMAIL PROTECTED] wrote: One small final comment: physical cash is not really anonymous (bills have serial numbers, and certainly coins may contain secret marks. Why? At 02:47 PM 09/27/1999 -0700, bram wrote: I believe at least part of the reason is to make heists difficult It also makes basic counterfeiting more difficult - the counterfeiter not only needs to make good-looking banknotes, but needs to put unique serial numbers, rather than taking a single banknote and copying it many times. One effect of changing technology is that serial numbers on cash did not provide much traceability in the past, but they do in the future. There have been various proposals to put bar-coded numbers on cash to make scanning faster and easier, but that's becoming less necessary. OCR technology for reading numbers has become much more affordable, and (either now or in the near future) it would not be difficult to make ATMs which record serial numbers of cash when dispensing it. Recording serial numbers used to be a slow manual process used mainly for kidnap ransom and similar transactions - now it's almost practical for drug payments and soon for everyday transactions. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: US encryption announcement: Business as usual
As various people have commented, the critical issue is the
"one-time technical review" by the NSA.
In the absence of technical constraints, it's hard to tell what
the technical review could be reviewing - we're being told to believe
that we're allowed to export full-strength crypto,
and there aren't requirements for key compromise,
and "works in North Korea" isn't a technical requirement,
just a customer-destination one.
The requirement of course means that "The NSA Is Still In Charge",
but it's difficult to imagine what they have as criteria for review
or how they can claim to be doing anything other than prior restraint
(generally banned as a first-amendment speech-chiller) without them.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: message-signing at the MTA level
On Sat, Aug 21, 1999 at 10:09:31PM -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? At 12:01 PM 8/22/99 -0700, Eric Murray wrote: I wrote a similar system for Sun 4 or 5 years ago. However its purpose was to encrypt the email for secrecy. It used sendmail and PGP, would automagically encrypt messages sent to hosts/domains registered in a config file, and would use the same config file to attempt to decrypt incoming PGP'd messages. PGP/NAI developed an SMTP forwarder system that does rule-based processing with capabilities like - Encrypt outgoing mail when possible - Block unencrypted outgoing mail to some/all sites - Block encrypted outgoing mail to some/all sites - copy+encrypt in/outgoing mail to Corporate Email Escrow - Block outgoing mail not also encrypted to Corporate Escrow - Signdate incoming or outgoing mail This was during their Corporate Escrow period, so we all taunted them about it, rather than doing much thought about what things might be useful. Cryptographic signing of the messages can be useful in some business environments, though I'd prefer encryption+signing for many of them. If you always sign outgoing mail, and somebody asserts that an unsigned message is from your company, you've got some ability to argue that it's forged. More importantly, if someone knows you always sign your mail, and they receive unsigned mail claiming to be from you, you and they can be suspicious. One of the fun things about just doing signatures is that you can distribute the software for free if you want, without US export laws. A big problem with this, though, is making very sure that the software doesn't sign things it's not supposed to sign. This is hard, because it depends on the user's configuration of their mailserver and firewalls, which is mostly out of your control - having software with your name on it that gets abused this way would be Really Bad. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: crypto on calculators
At 06:18 PM 9/9/99 -0400, [EMAIL PROTECTED] wrote: On Thu, 9 Sep 1999, Arnold Reinhold wrote: Are you saying that there are existing encryption programs for the Pilot or that there are better languages to program it in? (Basic really isn't bad for something like RC4) If I understand it correctly, there exists a Pilot C (C++ ?) development suite for Windows from Metrowerks. I think there's also a gcc version - not hard to port Unix gcc to yet another 68000-based environment, though some of the libraries are less straightforward. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Paul Brown on Solitiare randomness flaw?
At 09:23 AM 9/8/99 -0400, Arnold Reinhold wrote: BTW, several of these units also permit assembly language programming. The 83/83+ is Z80 based. The 89/92+ are 68000 based, with 188K of RAM. PGP isn't out of the question on those. ... Staples stocks the TI-83+ at $92.99. So for under a hundred bucks and a little time spent in TIBasic programming you can own an off-the-shelf coding machine using strong encryption, interoperable with CipherSaber programs on other platforms, in a reasonably portable and innocent-looking package. And it will still do math. Of course, you can get a low-end Palm Pilot for about $130-150 (or cheaper if you buy used from somebody upgrading.) More memory, and you don't have to program in Basic. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: linux-ipsec: /dev/random
At 01:50 PM 8/2/99 -0400, Paul Koning wrote:
What we need is a minimum of ONE decent quality additional
entropy source, one that works for diskless IPSEC boxes.
That's unfortunately outside the scope of IPSec :-)
If you don't have random number hardware,
you can't get hardware random numbers.
That means if you don't have a disk, you need to add something else,
whether it's a sound card or /dev/geiger or whatever.
At 03:35 PM 8/2/99 -0400, John Denker wrote:
1) Hardware TRNG
2) Network timing
By the way, you can help network timing if you've got a router
in front of your IPSEC gateway - it won't protect you from
inside observers, but it'll do some randomization that outside
wiretappers can't see. Of course, if you're using a 10ms clock
instead of a 1us or 5ns clock, it's not much use.
3) Deposits from a "randomness server"
4) Just rely on PRNG with no reseeding.
.
4) I don't think my customers would be very happy with a system that could
not recover from a transient read-only compromise.
You can at least help the PRNG problem by encrypting the PRNG output
using some secret key and crypto algorithm before using it as a random number
(or encrypting some constant value with the PRNG output as the key.)
This is probably stronger than simply hashing the PRNG output,
because the crypto was designed for different attacks than a hash.
It's not something /dev/urandom can easily incorporate,
because of Stupid Export Law Tricks, but IPSec does encryption anyway
and isn't written in the US. The key doesn't have to be constant;
you could update it from the randomness stream also,
but it may be more resistant to attacks or give you something more
to bootstrap randomness from if your gateway's been compromised.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: linux-ipsec: Re: TRNG, PRNG
At 05:14 AM 7/22/99 -0400, John Denker wrote:
1) Linux /dev/urandom can be considered a PRNG with some good properties
but two suboptimal properties:
1a) First it reseeds too much, and then
1b) it reseeds in dribs and drabs.
That is:
1a') When there is entropy in the pool, it gobbles it all up before
acting like a PRNG. Leverage factor=1. This causes other applications to
stall if they need to read /dev/random.
5) So let's talk about solving problem (1a). For clarity, let's talk in
terms of a new device /dev/vrandom. Consider the following possible
design: We use code similar to the existing /dev/urandom, EXCEPT that it
does not share its internal state with /dev/random or /dev/urandom. The
new device initializes its state from /dev/random or some other TRNG. (We
*really* want the initial state to be really random.) For a stripped-down
host on which TRNG bits are scarce or unavailable, this initialization is
done "at the factory". Thereafter it performs quantized reseeding often
enough to fend off iterative guessing attacks but not so often as to
deplete the TRNG.
You could help this problem by giving the randomness pool a secret key
that's typed in by the operator, and hashed in with each reseeding and
each output phase. You'd probably have to store it in a key file as well,
since there may not be an operator keyboard at boot time,
but if you've got an extra 160 bits of information not obtained
from the physical-randomness process, it should be stronger.
The user interface could allow the superuser (or maybe everyone?)
to input a bunch of text that gets SHA1'd together with the existing key.
2b) Suppose the attacker briefly gets root access. Such an attacker
*could* do something much worse than merely reading the keyfile -- but
might be afraid to. Altering the system has to be done very carefully or
it will leave fingerprints.
This is a non-problem - once the attacker gets root, you've lost
the game anyway.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: depleting the random number generator
At 10:04 PM 7/17/99 -0700, Mike Brodhead wrote: Step 3a) If Whitney is getting key material from /dev/random, the result is a denial of service. All the IPsec tunnels will time out and will be replaced slowly or not at all, because of the entropy shortage. seems to me that the reason the denial of service attack works does not have anything to do with the randomness per se. the attack works because the host must expend a lot of time and/or CPU juice before the new connection is determined to be bogus. /dev/random only gives you bits that it thinks have good entropy, and stalls or fails if you ask for more bits than it has right now, and the pool of entropy it keeps is small, up to ~4096 bits. Most machines can calculate public key encryption much faster than they can obtain new physical or other high-quality entropy. So if an attacker does enough connection requests or rekeys, he can easily blow through 4096 bits of entropy. /dev/urandom will give you pseudo-random bits if it's run out of entropy, so you've got the security risks inherent in that. As David Honig points out, you can't avoid those alternatives, so if you need the high quality randomness, you need hardware randomizers. Some of the key setup protocols are designed to reduce CPU-busting attacks; Photuris does so explicitly, but I think someone's said that ISAKMP/IKE doesn't do this well enough. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Encrypting filenames
At 04:00 PM 7/10/99 -0500, Steve Hawkinson wrote: Does anybody have any ideas on what would be a good algorithm for encrypting filenames? I would like for the alogorithm to do compression also. CFS uses an algorithm that lengthens the filename, thereby shortening the maximum allowed length of the clear text filename. I want to avoid this and possibly store extra metadata in the filename. What are you trying to accomplish by encrypting them? What's the environment you're planning to use them in? What's your threat model? Is it ok to always use the same key? (Thus, 3-DES is fine.) Do you need two-way encryption, or is a 1-way hash adequate? Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: The Beer Bottle Cipher (some fun summer reading for you...)
[I couldn't resist. Mea culpa, mea culpa, mea maxima culpa. --Perry] At 12:07 -0400 1999.06.30, Ron Rivest described the Beer Bottle Cypher, asking: The actual security of this cipher seems to be an open question... Can it be broken? Martin Minow [EMAIL PROTECTED] replied Have you tried getting an export license for it? Does it pass the Reinheitsgebot, or is it wimpy American beer? Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Bridge
At 11:44 AM 6/25/99 -0700, bram wrote: There are 52! bridge hands, so a random hand has log2(56!) = 226 bits of entropy or 68 decimal digits worth. No, just 52! / (13!)^4 hands, which is around 2^96. The interesting part is to come up with an algorithm that only uses 96 bits. Take the 96 digits as a really big number base two, find it's value modulo 52! ... (Actually 52!/(4*13!)) Doesn't work, though - for values higher than 52!/13!*4 you need to reject the random number and draw again. Otherwise you've got an excessively high probability of repeating the first 2**96 mod 52!/13!*4 hands. The real point, though, is that you never, *ever* need more than about 80 bits of entropy for *any* amount of random numbers if you use a crypographically strong pseudo random number generator. It depends on the application - for encryption keys, it's probably ok, at least for the next N years, unless the structure of selecting your keyspace interacts with the crypto algorithm in a way that decreases the strength of the resulting encryption. It's unlikely in the general case, but it can happen. But for bridge games, if you don't use at least 52!/13!*4 bits, or more if you're using them wastefully, there are hands that _won't_ happen, and those hands can be predictable in ways that are useful to the players, and therefore bias the results of the bridge game as well as complicatng play. If you know the system will never generate a hand where more than one player has more than 10 cards of one suit, and you're holding 10 clubs, this can be fun, but it's less emotionally satisfying than bidding that slam when you're worried that your opponents have 11 spades because the deck wasn't shuffled right :-) Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: ICSA certifies weak crypto as secure
The important points were Btw -- large password files using anything like this scheme are obsolescent. You can't use a hashed password for challenge/response, The fundamental problem is that users pick bad passwords and passphrases ... Yup. I like S/Key better than the annoying SecureID card I use to log in to work, or public-key challenge/responses where there's an intelligent client that can use them. b. Use a unique per-passphrase salt of at least 32 bits. If you're going to bother with a salt, might as well make it 64 or 128 bits; increasing storage by 2**32 is fine, but some combination of Moore's law, holographic storage, tape robots or whatever may catch up with you, but if you're doing an iterated-SHA1 or equivalent, you can allow long passphrases and still use enough salt to make things unstorable, forcing the cracker to iterate calculations every time. You're arguing with 20-20 hindsight. 16 gig of disk space wasn't even comprehensible then. 16 *meg* of disk space sufficed to bring up UNIX. On the other hand, 16 gig of tape was comprehensible then, if large, and tape sorting was still common technology - much more annoying with 160MB tapes than Exabytes or whatever the current big tapes are, but you could sort things into some convenient retrieval order. How would I like to do it, given a blank slate? Most likely, I'd use SHA-1 on the user's password, probably concatenated with a salt, to produce a DSA private key; the server would store the corresponding public key. (It's harder to pull a trick like that using RSA keys.) A while back I did a login protocol based on Diffie-Hellman; it turned out to be relatively easy (though unfortunately someone from Siemens had also discovered it and patented it in Germany and then the US :-) But almost any public-key system can give you a good mechanism for a challenge/response and set up a shared secret for encrypting or AHing a login session so it doesn't get hijacked. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Xerox supplies stego?
At 08:34 AM 3/22/99 -0600, Brown, R Ken wrote:
Probably not news to most of you, but I didn't realise they did this sort of
thing.
http://www.xerox.com/xsis/dataglph.htm
The basic intent of the system is watermarking, rather than stego in general -
you can hand somebody a paper copy of your document, marked for them,
and if you later encounter a Xerox copy, you know whose original it was.
[...]
"DataGlyph technology allows ordinary business documents to carry thousands
of characters of information hidden in these unobtrusive gray patterns that
can appear as backgrounds, shading patterns or conventional graphic design
elements. Often, their presence will go completely unnoticed. "
[...]
"As a final step, the bytes of data are randomly dispersed across the glyph
area, so that if any part of the glyph area on the paper is severely
damaged, the damage to any individual block of data will be slight, and
thus easy for the error correcting code to recover. Together, error
correction and randomization provide very high levels of reliability, even
when the glyph area is impaired by ink marks, staples and other kinds
ofimage damage."
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
PLANNING May 8 SF Cypherpunks Meeting, Berkeley/Oakland
The monthly SF Bay Area Cypherpunks Meeting will be Saturday May 8. We're looking for speakers and agenda items for the meeting. Because the IEEE Crypto conference will be at the Claremont starting the following Monday, we'll be meeting somewhere near there. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Starium announces STU-III for the masses
On the other hand, RFC 2523 is more relevant, Photuris being
the genus that Fireflies belong in...
At 10:32 PM 4/28/99 -0400, Vin McLellan wrote:
The reference to "Firefly" crypto in 1217 is informative, and --
given that the NSA's internal development of the FIREFLY protocols goes way
back -- may have actually been intended as a comment on the Agency's design
effort. It was, however, something less than the treasonous publication of
classified type-1 crypto by that noted revolutionary author.
My only involvement in ATT's STU-III design was helping keep
the typesetter alive while my co-workers did the proposal,
so I can tell you things about Imagen wet-process printers and
won't have to kill you :-) (I may have fixed some troff macros for them as
well.)
The box could do the required 2400 and 4800 baud modes, and ours also
had a 9600-baud mode for better sound and data. The guesses were that
the FIREFLY keying involved random number generator hardware and
Diffie-Hellman, but if I remember right the chip to do it came from the NSA.
The ATT box had several optional crypto versions, including
a Wimpy Exportable crypto for commercial users, DES, an NSA hardware-based
algorithm,
and maybe something else.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
RE: Starium announces STU-III for the masses
At 09:05 AM 4/29/99 -0400, Trei, Peter wrote: I asked Eric if the protocols will be published, so that compatible software implementations can be created. He said yes. Great! BTW, this sounds rather like the Harmless Little Project, which appears to be moribund. HLP proposed designing a Harmless Little Board that you could build for about $100, with a compatible software implementation. While that appears not to have happened, there are a number of $5 full-duplex sound cards, $20 28.8k modems, and cheap DSP and CPU chips around that designing a board to sell in that price range should be reasonable assuming you can sell enough volume. I'm glad it's actually being done! Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Using crypto to solve a part of the DNS/TM mess
At 04:34 PM 2/27/99 -0800, bram wrote:
Unfortunately, the problems of domain names are really ones of authority,
and the best cryptography can really do is make sure that a reasonable set
of rules are enforced smoothly, it can't fix the rules.
The exception is that there might be a way of using technology to destroy
any sort of naming authority. There are various schemes by which this
could be done, although they all involve sacrificing human readability,
and there are various ways they could be hacked on top of dn. WIPO might
get really mad about screwing around with 'their' domain name system, but
as long as all the goofing around was done beneath a single top-level
domain which noone was ever going to use, it might be possible to win that
battle.
Raph Levien and/or David Wagner did some interesting work on
"taz and rewebbers", for maintaining a "temporary autonomous zone"
anarchically managed .taz webspace.
You can trivially run a namespace under a 2nd-level domain name, e.g.
new-name-format.namegods.com
or foo.dyn.ml.org - to cite a real example
without having to disrupt the worldwide naming system.
The problem is getting enough people to want to participate,
which is admittedly easier with a TLD than 2LD
(thus Turkmenistan's .tm has some extra opportunities.)
Some of the small-country name registries have used ambiguity-resolving
name-spaces, which had forms like
www.1234.interesting-name.com.zz
where multiple participants who wanted interesting-name.com.zz
each got a number, and the page www.interesting-name.com.zz
had some indication of which company named interesting-name was which.
Back when Usenet was primarily uucp-based rather than tcp/ip based,
and we all had ambiguous names, "Harris's Lament" said that
"All the good ones are taken", but nobody was commercially worried
about the problem; you just used hop-by-hop routing and it was ok.
The Plan 9 operating system from Bell Labs used a relatively-defined
naming system rather than an absolute-rooted system, and there's a
paper by (I think) Ken Thompson and Rob Pike called "The Hideous Name"
on why that's a Good Thing. I don't know if Inferno kept that or not.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Using crypto to solve a part of the DNS/TM mess
O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm
-- It's warm here. --
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Liquid Audio MP3
Because the watermark is going to be different for every copy of a
particular song this suggests that if you get three copies of a song with
different watermarks and do bit voting with them you can produce a fourth
file that contains all the information that is the same in the first three
(the song) but does not include any of the differences (the marks).
If memory serves the mark Anderson describes is sort of steganographic in
nature. Most of the marks that I've seen have been FIR filters. This
complexity is needed to survive analog reproductions. As Liquid Audio
claims that their mark will survive analog reproduction its likely to be a
filter. Can you build a filter that removes the mark? Probably. Most of
If you're limited to filters that survive transition to audio and back,
the space available for watermarking becomes smaller but hairier,
requiring more complex math than simple stego techniques for digital environments,
and also is more likely to do things that annoy listeners.
Bit voting may well catch most of the pieces if the watermark
looks like "tweak the value of a few bits", but it's tougher to use
on changes like "add or drop samples at known points", or
"speed up or slow down sections by 1%" or "add different frequencies
with very low amplitude" which may cause huge numbers
of differences for simple comparisons (maybe this is ok,
since you're trying to disrupt watermarks rather than impersonate them.)
But there's a lot of room to hide large numbers of bits, letting you
play spread-spectrum code-division kinds of games that can still
tell you some bits about the user even after voting kills lots of them.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Mailinglist programs with PGP-encryption?
Ask the Oracle for pointers to "pgpdomo".
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Needing references on FWZ-1 algorythm
At 02:07 PM 12/28/98 -0800, Alan Olsen wrote:
I need general and/or specific information on the FWZ-1 algorythm.
This is used by the Firewall-1 VPN software.
I have been trying to find details beyond the marketing hype.
Wanting to know just how bad it is beyond "exportable protocol".
Unless I'm mixing it up with a different firewall maker's algorithm,
FWZ-1 is another "Our trademark lawyers won't let us call it RC4",
and if it's exportable it's probably 40 bits, though perhaps they've
been allowed to upgrade to 48 or 56 bits.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Web Hosting Providers in Many Countries? For crypto archives.
John Gilmore has proposed setting up crypto archives in
many countries to avoid Wassenaar restriction problems.
Does anybody have a good source for information on web hosting providers
or other ISPs in a variety of countries around the world?
Shell accounts are nicer, because it's easier to create
servers that check where the request is coming from,
for countries that insist you only provide access to their citizens
but still allow you to do that on a web site. The US doesn't
appear to have strictly defined legal requirements for such sites (YET)
and places like MIT have gotten quite flexible about it.
Also, are there any good sources of relatively private VISA
credit cards, preferably outside the US, that can be used
to rent computer accounts with?
There are other crypto distribution methods that, while slower,
are still legal from the US - censoring printed books embarasses
them a bit still, though some other countries don't have
the same squeamishness even though they may be less interested
in banning the material. Printing PGP source books was annoying,
but a week's delay in shipping few-page crypto subroutines
isn't that serious, especially if it's in a scanner-friendly format.
Any guess how the various countries feel about faxes of source code?
And, of course, shipping or even selling source for 40-bit RC4
and 512-bit RSA is pretty simple, even if you don't include the note
"WARNING: DO NOT CHANGE THE #define KEYLENGTH TO 128 OR THE
#define MODULUSLENGTH TO 2048 AND RECOMPILE"
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
ANNOUNCE: SATURDAY Bay Area Cypherpunks Meeting - Stanford University
The November Cypherpunks Meeting will be Saturday 11/14 from 1-5pm at Stanford, at the tables outside Tresidder Union, near the bookstore. The tables are on the west side, which is the inside of the U-shape. Coffee and food are available in the building. If the weather is uncooperative, we will also be inside the building. Lucky Green will be talking about his latest work. Bagels and Bagel Parephrenalia will be provided. Directions to Stanford Tresidder Hall Stanford is between El Camino Real and Junipero Serra Blvd, which are between 101 and 280. The Tresidder Parking Lot is on Mayfield Ave, off Campus Drive East. http://www.stanford.edu/home/map/search_map.html?keyword=ACADEMIC=Tresidder+Union http://www.stanford.edu/home/map/stanford_zoom_map.html?234,312 The upside-down map of StanfordVicinity is at http://www.stanford.edu/home/visitors/vicinity.html Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
