Re: Run a remailer, go to jail?
Peter, I'll see if I can get there. I'm not sure I can. But I know a number of other MIT-types who are considering going. If I can go I'll try to keep notes. If I can't go, then hopefully someone else can take some notes. -derek "Trei, Peter" <[EMAIL PROTECTED]> writes: > Derek, etal > > If you (or anyone) goes, I'm sure we'd all appreciate some > notes on what transpired. I understand 17 different bills are > being considered at this hearing, so don't blink or > you may miss it. > > Peter Trei -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Run a remailer, go to jail?
Dave Emery <[EMAIL PROTECTED]> writes: > For those on this list in the Boston area there is a hearing > scheduled on the Mass Bill at 10 Am in Room 222 of the Mass State House > in Boston. 10am on what date? -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: meet in the middle attacks
Note that SSH is vulnerable to a Man in the Middle attack (not meet in the middle -- that is an attack on 2DES where you attack from the input and output and then "meet in the middle"). In particular SSH is vulnerable if you do NOT have the long-term server key cached on the client. That notwithstanding, I think that Ian is just upset about paying for an SSL Cert and wants a way to setup an SSL/TLS server without paying homage to one of the Big Three (or is it down to Big One at this point?). Ignore the fact that he could use self-signed certs and be as secure as SSH. -derek "Perry E. Metzger" <[EMAIL PROTECTED]> writes: > I have to say I've watched this with a bit of puzzlement. > > Meet in the middle attacks are perfectly real. I've seen them myself, > and toolkits to perform them are readily available out there. Ian's > vague comments about a lack of evidence of the economic impact > notwithstanding, it is unreasonable to leave one's protocols and > systems open to such attacks. > > You do not need an elaborate CA infrastructure to prevent them, of > course. SSH manages to prevent them simply by having both sides sign > exchanges using naked (i.e. uncertified) keys that are pre-shared, for > example. Even use of MACs over exchanged values and pre-shared > conventional keys can prevent many such attacks. > > However, not attempting to prevent such attacks -- especially given > that they are very effective -- seems foolish at best. -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Face-Recognition Technology Improves
Bill Stewart <[EMAIL PROTECTED]> writes: > >Were there really 750 Million Passengers flying through ATL??? That > >number seems a bit high... > > 750,000 * 100 = 75,000,000 usually (:-), which sounds more credible. > No idea how many of those are unique passengers, but there are probably > a lot of frequent business travellers going through there many times. Ok Ok ok. I'm sorry for trying to do math on only 6 hours sleep before a flight. I mis-counted 0's. I'm sorry. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Face-Recognition Technology Improves
"Sidney Markowitz" <[EMAIL PROTECTED]> writes: > > In addition, only one subject in 100 is falsely linked > > to an image in the data base in the top systems. > > Wow, 99% accuracy for false positives! That means only a little more than > 75 people a year mistakenly detained for questioning in Atlanta > HartsField Airport (ATL), and even fewer at the less busy airports (source > Airports Council International, 10 Busiest Airports in US by Number of > Passengers, 2001). Were there really 750 Million Passengers flying through ATL??? That number seems a bit high... Also, I'm not convinced that multiple trials for a single individual are independent. Indeed, one could easily assume that multiple trials for a single individual are highly correlated -- if the machine isn't going to recognize the person on the first try it's highly unliklely it will recognize the person on subsequent tries. It's not like there is a positive feedback mechanism. Therefore, a better question would be how many UNIQUE passengers flew threw ATL, and then take 1% of that for the number of false positives. I think it's safe to assume that the 99% accuracy for false-positives is over the population, not over the number of trials. > -- sidney markowitz > [EMAIL PROTECTED] -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Diffie-Hellman 128 bit
Hi, I'm sorry to inform you, but a brute-force attack on a 128-bit prime is simple to mount. I don't think I can estimate the length of time to attack a prime of this length, but it wouldn't be very long. Consider that 425 bits is only about 4KMY (Kilo-MIP-Years) -- with todays 2KM+ processors you're probably talking about a week or less to crack it. Also, there aren't THAT many "strong" 128-bit primes. If you're using these numbers for real data (even if ephemeral), I would suggest using at least 512-bit ephemeral DH Primes.. But then you need some way to securely AGREE upon the ephemeral prime. How do you intend to prevent an attacker from forcing you to agree to a prime that it's already solved? -derek NOP <[EMAIL PROTECTED]> writes: > I am looking at attacks on Diffie-Hellman. > > The protocol implementation I'm looking at designed their diffie-hellman > using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no > go on pohlig-hellman attack), so what attacks are there that I can look at > to come up with either the logarithm x from (a=g^x mod p) or the session key > that is > calculated. A brute force wouldn't work, unless I know the starting range. > Are there any realistic > attacks on DH parameters of this size, or is theoretically based on > financial computation attacks? > > > Thanks for your time. > > Lance James > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Delta CAPPS-2 watch: decrypt boarding passes!
"Roy M. Silvernail" <[EMAIL PROTECTED]> writes: > On Thursday 06 March 2003 02:34 pm, John Ioannidis wrote: > > > Both JFK and SFO have stopped gate searches. Searches at security are > > still decided by the TSA personnel there (they don't get to see your > > boarding pass). > > FWIW, MSP initial security screening wants to see your boarding pass. I > didn't see anyone try to avoid showing it. I've not seen ANY airport that didn't have this initial check, although generally it is "boarding pass, printed ticket, or printed itinerary". This is actually one of the "written rules" (as opposed to some of those lovely unwritten rules that TSA seems to like imposing). -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Delta CAPPS-2 watch: decrypt boarding passes!
John Ioannidis <[EMAIL PROTECTED]> writes: > Are you referring to the "" string on the boarding pass? That > indicated that you were going to be searched by the boarding gate TSA > people whether they were going to decide to search you or not (they > still picked up "random" people without the search string on their > boarding passess). Yes, that's what I was referring to. I didn't recall exactly what the mark was, but "" sounds right. I was just annoyed because they flagged about 30% of the flight. Even though I was seated in like row 15/22 (in the second group to get boarded), by the time I actually made it through the line they had already finished normal boarding and closed the gate doors. > Both JFK and SFO have stopped gate searches. Searches at security are > still decided by the TSA personnel there (they don't get to see your > boarding pass). Hmm. Well, I'll let you know about BOS. And I'll find out about ORD on my return flight. I consider gate checks rather rude, but then again I consider commercial travel in general rather annoying. If it weren't going to take me 3 days (rather than 6 hours) I would have just flown myself out to SF -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Delta CAPPS-2 watch: decrypt boarding passes!
John, John Gilmore <[EMAIL PROTECTED]> writes: > And, besides identifying what cities they're doing this in, we should > also start examining a collection of these boarding passes, looking > for the encrypted "let me through without searching me" information. > Or the "Don't let me fly" information. Then we can evaluate how easy > it would be to turn one into another. (Don't mistake a system that > claims to provide security for one that actually does.) When I flew on US-Airways out of BAL last year, they had a marking on the boarding pass that signified "search this person". If your boarding pass had the mark, you were searched as you tried to board. If it did not, then you were not searched. I'm flying United out to the IETF next week, so I'll gladly report my findings. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: EU Privacy Authorities Seek Changes in Microsoft 'Passport'
Single Signon by ITSELF is not a bad technology. But it very much depends on the architecture and implementation. A Globally Centralized SSO system like Passport certainly has problems as you suggest. A locally centralized SSO system like Kerberos is less of an issue. A Federated SSO system like Shibboleth is much better. It all depends on your threat model. Don't destroy SSO just because some company decided to "do it wrong". -derek bear <[EMAIL PROTECTED]> writes: > The widespread acceptance of something as obviously a bad idea as > passport really bothers me. I could see a "password manager" program > to automate the process of password invalidation where you discovered > a compromise; but the idea of putting everything you do online on the > same password or credential is just... stupid beyond belief. > > Why are single-sign-on systems even legal to sell without warnings? > Why don't Msoft and the other members of the "Liberty alliance" have > to put a big warning label on them that says "USE OF THIS PRODUCT WILL > DEGRADE YOUR SECURITY"? Because that's what we're looking at here; > drastically reduced security for very marginally enhanced convenience. > > But what really gets me about this is that it's totally obvious that > that's what we're looking at, and people are buying this system > anyway. That's hard to swallow, because even consumers ought not to > be that stupid. But it's even worse than that, because people who > ought to know better (and people who *DO* know better, their own > ethics and customers' best interests be damned) are even *DEVELOPING* > for this system. It just doesn't make any damn sense. > > Bear > > > > --------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
The fact that the hole is on the bottom pin is not important. What is important is that the hole at the change-key height does not need to be at the same angular position as the hole at the master-key height. It's hard to draw ascii art to show what I mean, but because the twist holes are at a particular height when the key is inserted, you can certainly see how at different heights the holes can be in different locations. -derek Matt Blaze <[EMAIL PROTECTED]> writes: > Actually even in their Biaxial design the sidebar hole is always on the > bottom pin, and so the master shares the angle with the change keys. > > -matt > > > There is, however, a newer medeco design that uses a drill-hole > > instead of a groove. With that design you can have the pin twist be > > different at different pin-heights (by putting the drill-hole at a > > different twist-angle). I don't think this attack would work quite > > as easily on this design. > > > > -derek > -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
Matt Blaze <[EMAIL PROTECTED]> writes: > I have no particular interest in seeing you eat crickets (and before > I went veggie I've eaten a few myself; taste like whatever they're > cooked in), but I've done it on Medecos; it's no problem. Having taken apart Medeco's before, I have to agree with Matt that this attack would work fine on old-style medecos with a groove for the the turn-bar. This means the twist is the same at all pin heights for any particular pin. > The angles will be the same on the master as the change key; only the > cut depth will differ. If you have a code cutter at the oracle lock > it's no different from doing the attack regular locks, except that Medeco's > MACS restrictions mean you have to be careful about whether you use the > change depth or previously learned master depth at the positions adjacent > to the position under test. If you're using a file at the oracle lock, > just use a code machine to pre-cut a #1 cut at the right angle at each > position; the sharp angle actually makes filing a bit easier than on > locks with a standard cut. There is, however, a newer medeco design that uses a drill-hole instead of a groove. With that design you can have the pin twist be different at different pin-heights (by putting the drill-hole at a different twist-angle). I don't think this attack would work quite as easily on this design. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: DOS attack on WPA 802.11?
The answer is multi-fold. 1) The 802.11i standard wont be finished for a while. 2) There is an apparent Market Requirement for something better than WEP __NOW__. 3) The WPA can only change their "requirements" once per year, so even if 802.11i were ready in 3 months, it would still take another year until it hit the WPA conformance requirements. But they wanted to make some changes _now_ in order to get "better" security into next year's product line. In other words, the answer is due to layers 8 and 9, and nothing technical -derek [EMAIL PROTECTED] (David Wagner) writes: > Arnold G. Reinhold wrote: > >If I am right and WPA needlessly > >introduces a significant denial of service vulnerability, then it > >should be fixed. If I am wrong, no change is needed of course. > > But TKIP (the part of WPA you're talking about) is only a > temporary measure, and will soon be replaced by AES-CCMP. > > The question is not "Should we replace TKIP?", because the > answer to that is obvious: "Yes, we should, and we will". > Th question is: "Why bother working on a `fix' to WPA that > will likely never be deployed and that will be obsoleted > in a few years by the spread of AES-CCMP?". > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: open source CAs?
OpenCA? At one point I wrote some PERL around OpenSSL called WebCA, but I don't know what became of that. I don't think it was ever released. -derek "Perry E. Metzger" <[EMAIL PROTECTED]> writes: > Beyond the openssl tools (which are quite primitive), are there any > open source certificate authority tools out there at the moment that > people can recommend? > > -- > Perry E. Metzger [EMAIL PROTECTED] > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: unforgeable optical tokens?
[EMAIL PROTECTED] writes: > I can't dig up the memory, but I think I heard of a similar idea -- > random structure in transparent solid, difficult to copy -- used in > some kind of tag or seal for nuclear security. Can anyone remind me > what this might have been? This isn't security -- this is a small-form-factor physical ROM. This "read-only data crystal". The fact that they cannot be duplicated easily just means that you cannot use these tokens for real data storage. Imagine if they _were_ replicable.. Imagine keeping a terabyte of backup data on one of these tokens! > Eli Brandt | [EMAIL PROTECTED] | http://www.cs.cmu.edu/~eli/ > (finished Ph.D., woohoo; looking for good work in the Seattle area) -derek PS: My Master's degree is from the Media Lab, so I can vouch for the fact that reasonable work is done there ... ;) -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Palladium and malware
Bill Frantz <[EMAIL PROTECTED]> writes: > All general purpose computers require a way to move data space to code > space to support compilation. Even if you don't allow compilation, most > modern systems have enough different powerful scripting languages that > interpretation is sufficient to support viruses. "application/shell" anyone? (Yes, some Mail-readers actually implement this!) > Cheers - Bill -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SEC weighing civil injunction against RSA
Steve Bellovin <[EMAIL PROTECTED]> writes: > RSA, Inc., in a filing, reported that the SEC is considering > seeking an injunction against it and some of its officers. The filing > did not say what the injunction was about. >From the Boston Globe this morning: <http://www.boston.com/dailyglobe2/232/business/SEC_may_sue_RSA_over_records+.shtm> -derek SEC may sue RSA over records By Bloomberg News, 8/20/2002 B EDFORD - RSA Security Inc. said the Securities and Exchange Commission may file suit following an investigation into how the company disclosed a change in accounting and stock sales by executives last year. The SEC's staff told the computer-security company last month that it may seek permission from the commission to file a lawsuit against the company and some of its officers, RSA said in a quarterly report to the SEC last week. The company, which denies wrongdoing, in April said it was the subject of an SEC investigation. RSA changed its accounting in the first quarter of 2001 to recognize revenue when products are shipped to distributors, rather than when the goods reach customers. The company didn't disclose the change, which boosted first-quarter revenue by $1.74 million, until more than a month after reporting results, when it filed a quarterly report with the SEC. This story ran on page C3 of the Boston Globe on 8/20/2002. ? Copyright 2002 Globe Newspaper Company. -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: get a grip on what TCPA is for
"John S. Denker" <[EMAIL PROTECTED]> writes: > But how to trust a machine when you don't have physical > custody? Even the most-skilled members of this list > would find that a challenge (depending, as I have emphasized > before, on what your threat model is). Note that this is not the only interesting question to be solved. It is one question, certainly the major question that Da Mouse wants to be answered, but far from the only one. > I guarantee you will not understand TCPA/Pd unless you > walk a while in the proponents' moccasins. If you can't > stand the smell of those moccasins, OK, but prepare > yourself for perpetual ignorance and irrelevance. Ok, I qualify here as "stepping in those moccasins", so let me continue my analysis. > For example: Imagine you are the owner of a valuable copyright > and you want to protect it. You want consumers to be able > to use your work in some ways, but you want to prevent rampant > infringement. What will you do??? It's not an easy problem. True, however I have yet to believe that this is a credible threat. Perhaps I am naive, but I do believe that a majority of people are honest, and honest people are going to do the honest thing. Do I listen to digital music? Sure, but I still go out and buy the CD. > If your powers of imagination are not up to the task in the > previous paragraph, here's an alternative: Suppose you want > to spend a few weeks visiting Outer Zambonia, but you want to > communicate securely with your colleagues back home during this > time. Alas, the Zambonian Ministry of Friendship has been > looking forward to this as an opportunity to trojanize your > laptop. You simply don't have the resources to guard your > laptop 24 hours a day. You can't travel with a GSA-approved > safe in your carry-on. You can't take your laptop with you > when you go swimming. The idea of hardware with !!some!! > degree of tamper-resistance might eventually start to appeal > to you. Um, this is NOT the same problem. In fact, this is completely different. Yes, you still need the TPM to do this, however the requirements over the TPM are completely different. To solve this problem I only need a TPM where *I* can control the keys, and have it watch over itself. I could still run Linux or whatever OS I wanted, because the goal here is for me to certify my own software running on my own machine. In fact I don't even need a TPM to detect tampering. All I need is to have a boot-CD with md5sum and have it burn the md5sum values of all files onto another CDROM... Then I can detect tampering by again booting off the CDROM and running the tests again. A TPM that *I* control just makes it more real-time. You can enforce restrictions that no changes are made to the OS. But the manufacturer needs no control over this. They don't need the keys. They don't need certificates. Actually, as I think about this, you can do this today with "non-resetable" BIOS and Bootup passwords and "encrypted" disk drives (where the disk key is also stored in the BIOS). Someone with physical access would need to be able to read out the BIOS settings or obtain my BIOS passwords to do anything. You don't need a TPM for this, you just need resiliant BIOS nvram. Then the machine is useless without the passwords. So, what does the TPM buy _ME_ when running my own machine? > Of course, our task of understanding what TCPA/Pd is trying > to do is made more difficult when proponents lie about what > they are trying to do. Yep! -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: responding to claims about TCPA
AARG!Anonymous <[EMAIL PROTECTED]> writes: > I don't agree with this distinction. If I use a smart card chip that > has a private key on it that won't come off, is that protecting me from > third parties, or vice versa? If I run a TCPA-enhanced Gnutella that Who owns the key? If you bought the smartcard, you generated the key yourself on the smartcard, and you control it, then it is probably benefitting you. If the smartcard came preprogrammed with a certificate from the manufacturer, then I would say that it is protecting the third party from you. > I wrote earlier that if people were honest, trusted computing would not > be necessary, because they would keep their promises. Trusted computing > allows people to prove to remote users that they will behave honestly. > How does that fit into your dichotomy? Society has evolved a myriad The difference is proving that you are being honest to someone else vs. an application proving to YOU that it is being honest. Again, it is a question of ownership. There is the DRM side (you proving to someone else that you are being honest) vs. Virus Protection (an application proving to _you_ that it is being honest). -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: adding noise blob to data before signing
Nomen Nescio <[EMAIL PROTECTED]> writes: > Derek Atkins replied: > > It depends on the signature algorithm. With RSA you can sign any > > message "directly" if said message is smaller than the public key size > > (N). DSA, however, requires the use of a hash. > > Actually, depending on the data being signed, it can be important to > hash for RSA. After all, RSA is existentially forgeable: anyone can > forge a signature on a *random* value (if C=M^e mod n, then M is a > signature on C). They might be able to try some large number of sigs > until they got a random value which looked enough like legitimate data > to be accepted - especially possible if the 1kbit value being signed > holds dense, random-ish binary data. Let me be clear: I implied (but clearly I should have been explicit) that PKCS#1 padding should be used, not "raw" RSA. The problem with raw RSA is that you can combine multiple encryptions into new encryptions. Using PKCS padding inside the RSA signature foils the multiplication attack. So, sure, your message is can only be N-(sizeof(pkcs#1)) bits, not N bits. However you still do not need a hash. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: adding noise blob to data before signing
Eugen Leitl <[EMAIL PROTECTED]> writes: > 1) What's the name of the technique of salting/padding an small integer >I'm signing with random data? Blinding? Padding? It depends on what you are trying to accomplish. > 2) If I'm signing above short (~1 kBit) sequences, can I sign them >directly, or am I supposed to hash them first? (i.e. does a presence >of an essentially fixed field weaken the signature) It depends on the signature algorithm. With RSA you can sign any message "directly" if said message is smaller than the public key size (N). DSA, however, requires the use of a hash. Note that, in the grand scheme of things, performing the public key operation is significantly slower than performing the hash, so it really doesn't hurt you computationally to perform the hash. OTOH, your signature strength still depends on the strength of your hash. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: building a true RNG (was: Quantum Computing ...)
"John S. Denker" <[EMAIL PROTECTED]> writes: > > Source --> Digitizer --> Simple hash --> Whitener (e.g., DES) > > OK, we have DES as an example of a whitener. > -- Can somebody give me an example of a "simple hash" > that performs "irreversible compression" of the required > kind? I can give you a number of examples: MD5, SHA-1, > -- Isn't the anti-collision property required of even > the simplest hash? Isn't that tantamount to a very > strong "mixing" property? If there's strong mixing in > the simple hash function, why do we need more mixing > in the later "whitening" step? More mixing is never bad in an RNG.. See RFC1750. > -- What is meant by "cryptologic strength"? Strength > against what kind of attack? If this means in particular > the one-way property, why do I need it? I can understand > why a !!pseudo!! random symbol generator needs the one-way > property, to protect its internal state, but since my > generator has no secret state to protect, why do I need > any cryptologic properties other than mixing? I think they probably meant cryptographic strength, but I don't know what was going through their minds. What do people mean by "authentification"? That's not even a real world but I see it all the time. To me, I think people just don't know the right term to use so they just put down something that sounds right to them, regardless of its correctness. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Ross's TCPA paper
I, for one, can vouch for the fact that TCPA could absolutely be applied to a DRM application. In a previous life I actually designed a DRM system (the company has since gone under). In our research and development in '96-98, we decided that you need at least some trusted hardware at the client to perform any DRM, but if you _did_ have some _minimal_ trusted hardware, that would provide a large hook to a fairly secure DRM system. Check the archives of, IIRC, coderpunks... I started a thread entitled The Black Box Problem. The issue is that in a DRM system you (the content provider) wants to verify the operation of the client, even though the client is not under your control. We developed an online interactive protocol with a sandbox environment to protect content, but it would certainly be possible for someone to crack it. Our threat model was that we didn't want people to be able to use a hacked client against our distributation system. We discovered that if we had some trusted hardware that had a few key functions (I don't recall the few key functions offhand, but it was more than just encrypt and decrypt) we could increase the effectiveness of the DRM system astoundingly. We thought about using cryptodongles, but the Black Box problem still applies. The trusted hardware must be a core piece of the client machine for this to work. Like everything else in the technical world, TPCA is a tool.. It is neither good nor bad; that distinction comes in how us humans apply the technology. -derek "Lucky Green" <[EMAIL PROTECTED]> writes: > Anonymous writes: > > Lucky Green writes regarding Ross Anderson's paper at: > > Ross and Lucky should justify their claims to the community > > in general and to the members of the TCPA in particular. If > > you're going to make accusations, you are obliged to offer > > evidence. Is the TCPA really, as they claim, a secretive > > effort to get DRM hardware into consumer PCs? Or is it, as > > the documents on the web site claim, a general effort to > > improve the security in systems and to provide new > > capabilities for improving the trustworthiness of computing platforms? > > Anonymous raises a valid question. To hand Anonymous additional rope, I > will even assure the reader that when questioned directly, the members > of the TCPA will insist that their efforts in the context of TCPA are > concerned with increasing platform security in general and are not > targeted at providing a DRM solution. > > Unfortunately, and I apologize for having to disappoint the reader, I do > not feel at liberty to provide the proof Anonymous is requesting myself, > though perhaps Ross might. (I have no first-hand knowledge of what Ross > may or may not be able to provide). > > I however encourage readers familiar with the state of the art in PC > platform security to read the TCPA specifications, read the TCPA's > membership list, read the Hollings bill, and then ask themselves if they > are aware of, or can locate somebody who is aware of, any other > technical solution that enjoys a similar level of PC platform industry > support, is anywhere as near to wide-spread production as TPM's, and is > of sufficient integration into the platform to be able to form the > platform basis for meeting the requirements of the Hollings bill. > > Would Anonymous perhaps like to take this question? > > --Lucky Green > > > --------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Schneier on Bernstein factoring machine
Russell Nelson <[EMAIL PROTECTED]> writes: > The union of the two sets of "cryptography users" and "paranoid > people" is necessarily non-empty. Who would bother to use > cryptography sans a threat model? And if you've got a non-empty > threat model, then by definition you're paranoid. I think it's really about degree. I don't agree that having a non-empty threat model implies you a paranoid. You could have a threat model of "I don't want my sister or parents to read this" which is very different than "I don't want the NSA or KGB to read this". I would certainly call both of these statements a "non-empty threat model". I would certainly call the latter threat model "paranoid"; I would NOT call the former threat model paranoid -- I would call it a "normal teenager" :) -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Schneier on Bernstein factoring machine
Anonymous <[EMAIL PROTECTED]> writes: > Bruce Schneier writes in the April 15, 2002, CRYPTO-GRAM, > http://www.counterpane.com/crypto-gram-0204.html: > > > But there's no reason to panic, or to dump existing systems. I don't think > > Bernstein's announcement has changed anything. Businesses today could > > reasonably be content with their 1024-bit keys, and military institutions > > and those paranoid enough to fear from them should have upgraded years ago. > > > > To me, the big news in Lucky Green's announcement is not that he believes > > that Bernstein's research is sufficiently worrisome as to warrant revoking > > his 1024-bit keys; it's that, in 2002, he still has 1024-bit keys to revoke. > > Does anyone else notice the contradiction in these two paragraphs? > First Bruce says that businesses can reasonably be content with 1024 bit > keys, then he appears shocked that Lucky Green still has a 1024 bit key? > Why is it so awful for Lucky to "still" have a key of this size, if 1024 > bit keys are good enough to be "reasonably content" about? I see no contradiction at all. Bruce believe that Lucky is one of "those paranoid enough" that "should have upgraded years ago". In other words, Bruce is surprised that Lucky didn't already upgrade to a key larger than 1024 bits, due to his "paranoia". No offense meant, Lucky... -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
"Enzo Michelangeli" <[EMAIL PROTECTED]> writes: > Anyway, IPSEC (plus Kerberos/PKINIT) is the security mechanism chosen by the > PacketCable initiative: > > http://www.packetcable.com/ > http://www.packetcable.com/specs/PKT-SP-SEC-I05-020116.pdf Actually, this was chosen only to protect signalling, not the actual VoIP data. If you read the spec carefully you will notice that the RTP stream is NOT using IPsec for data protection. > Enzo -derek -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
Matt Crawford <[EMAIL PROTECTED]> writes: > > There are other problems with using IPsec for VoIP.. In many cases > > you are sending a large number of rather small packets of data. In > > this case, the extra overhead of ESP can potentially double the size > > of your data. > > HOW small? You'd already be adding IP+UDP+RTP headers (20 [or 40] + > 8 + 12 = 40 [or 60] bytes). Using ESP with authentication would add > another 22, plus possible explicit IV and padding, if needed -- call > it 30? > > 20ms of uncompressed telephone quality data is 160 bytes ... 8-bit u-law (standard telephone quality) is 56kb/sec. 20ms at that rate is 140 bits (I guess you assumed 64kb/sec to get 160 bits?). However, many audio codecs in common use (e.g. G7.11) output a bit-rate much smaller than 8-bit u-law, to the point were we're really talking about 20-30 bytes of data for that same 20ms of audio. Yes, we're talking 8-12kb/sec codecs. This means that in order to send 20 bytes of data you're already adding 60 bytes (or a factor-of-three increase), not to mention the extra 22 (or more) for ESP. The other thing to keep in mind is that IP+UDP+RTP can be compressed using standard header-compression techniques, which pretty much eliminates most of that extra overhead. So, maybe your factor-of-three increase that we're seeing above is now reduced to a factor-of-one increase. The problem is that if you use ESP then your UDP and RTP headers are now encrypted within the ESP, thereby destroying your chance for any kind of header compression. -derek -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Fingerprints (was: Re: biometrics)
JI, Keep in mind that this is the _creation_ of the database entry. Yes, you want the data in the database to be as completely accurate as possible. Later, when they only have partial prints, they can perform a lookups of partial data using the complete database. I think the same would be true of mass-produced fingerprint scanners. So long as the backend-database has a full, complete data set, a partial read on the verification step can still match. The question is: what would be the rate of false-positive (or false-negative) readings? -derek [EMAIL PROTECTED] writes: > Last week I had to go to my local INS office to get fingerprinted > (part of the green card process is getting your fingerprints OK'ed by > the FBI (and also presumably stored for future reference)). The > process is computerised, with a low-res scan of all the fingers taken > once, and then each finger is individually rolled and scanned on a > much higher resolution scanner. > > The process took about 20-30 minutes; each finger had to be wiped > with some cleaning fluid, the glass on top of the scanner also had to > be wiped between scans, and a fingerprinting technician had to roll > each of my fingers with the right amount of pressure to get a clear > image of the fingerprint. Even with immediate feedback on a large > screen showing the fingerprint and how good the scan was, some fingers > took as many as five tries to get an acceptable fingerprint. > > Now, this was a special-built device whose only purpose is to scan > fingerprints, operated under ideal conditions by a trained > technician. Draw your own conclusions about the effectiveness of > mass-produced fingerprint scanners that would be integrated in other > devices. > > /ji > > -- > /\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department > \/campaign| AT&T Labs - Research * Florham Park, NJ 07932 * USA > /\against | "Intellectuals trying to out-intellectual > / \ HTML email. | other intellectuals" (Fritz the Cat) > > > > > ----- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, Internet and Computer Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
There are other problems with using IPsec for VoIP.. In many cases you are sending a large number of rather small packets of data. In this case, the extra overhead of ESP can potentially double the size of your data. In certain cases (such as cablemodem networks) this implies that using IPsec effectively halves the number of active VoIP sessions that a carrier can handle. "Enzo Michelangeli" <[EMAIL PROTECTED]> writes: > If everything is tunnelled inside SSH, its ultimate transport is TCP, which > is bad for data types like voice where reliability is less important than > low delay. The right thing to do is to build decent security into the RTP > layer (the standard transport for voice applications, RFC1889): the SRTP > draft (http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-02.txt) goes > in this direction. Authentication and key exchange are supposed to be > handled in the session initiation phase (e.g., through SIP or H.323). > > Alternatively, one could rely on IPSEC, but its support on the target > machine cannot (yet?) be taken for granted; the RTP stack, on the opposite, > is usually built into the application rather than the kernel. > > Enzo -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PGP & GPG compatibility
Actually, I've found it isn't quite that bad. Yes, there are some problems with some of the odd-man-out features. And yes, there are certainly problems that only get solved if users upgrade to PGP 6.5.8 or more recent versions of GPG. I will agree with your assessment of the origin of the problem. However I don't think it's quite as bad as you make it out to be -- I've been using PGP 6.5.8 successfully to talk to a few people. My biggest problem is that very few people actually use PGP. Question: How many users of PGP 2.x are still out there? If people have upgraded to more recent versions, then it's not quite as bad. OTOH, I have successfully interoperated with PGP 2.6 fairly recently. Then again, I still use my 1992-era RSA key (I should probably upgrade sometime soon). If all else fails, there is always S/MIME ;) -derek John Gilmore <[EMAIL PROTECTED]> writes: > These days, PGP is effectively useless for interoperable email. If > you have not prearranged with the recipient, you can't exchange > encrypted mail. And even if you have, one or the other of you will > probably have to change your software, which will produce other ripple > effects if you are trying to talk to TWO different people or groups > using encrypted email. > > PGP compatibility problems started with Phil Zimmermann's deliberate > decision to eliminate compatibility with RSA keys. Once that problem > existed, disabling communication with anyone who used PGP before late > 1997, nobody else seemed to mind introducing all sorts of lesser > incompatibilities, including many mere bugs. > > Having wrestled with these problems for years, my guess is that we > need to abandon PGP and spec something else, probably in the IETF. > (Perhaps we might be able to shortcut that process if the OpenPGP > standards effort actually produces many compatible implementations > including NAI's, and/or if NAI falls apart and every other > implementation meets the IETF specs.) > > Note, however, that there are many things that OpenPGP doesn't do, > making encrypted email still a pretty sophisticated thing to do. > Brad Templeton has been kicking around some ideas on how to make > zero-UI encryption work (with some small UI available for us experts > who care more about our privacy than the average joe). > > http://www.templetons.com/brad/crypt.html > > John > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PGP & GPG compatibility
Will Price <[EMAIL PROTECTED]> writes: > The SDK (which still includes little bits of your code Derek, and all > other crypto/network/passphrase and even all the UI code which > interacts with the crypto related code) has been published up through > 7.1.1. The Windows GUI was last published at 6.5.8. Does this include the Unix CLI? (And yes, I know a lot of my code is in there.. I was amused when I ported 6.5.8 to Tru64. I was also surprised (but relieved) at the re-write of the Ascii Parser). > > Worse, there are a couple of bugs I found in 6.5.8 when > > I was porting it to Tru64, but who knows if anyone is > > listening over at NAI. > > I don't know who you sent these to. You could always have sent diffs > directly to me to make sure they get handled. The official address > for these things remains [EMAIL PROTECTED] I am on that list so you > couldn't have sent it to that one either since I haven't seen any > diffs from you ever as far as I can recall. I sent patches to [EMAIL PROTECTED] Is [EMAIL PROTECTED] documented anywhere? The particular bug is the COMMENT handling in the binary parser. > Side note, this may all be a moot point if a "transition agreement > with a purchasing vendor" is not worked out RSN. So, um, what happens then? If NAI cannot find a buyer, will they bury the code? Or will NAI donate the code to the OpenSource community? If they cannot find a buyer will they relinguish the commercial rights to the OpenSource version (i.e. so that commercial entities can use the freeware)? > -- Will > > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PGP & GPG compatibility
Matt Crawford <[EMAIL PROTECTED]> writes: > > Is there even development on the PGP (product) line? AFAIK > > they (NAI) have not release PGP 7.x in source form. Worse, there > > are a couple of bugs I found in 6.5.8 when I was porting it > > to Tru64, but who knows if anyone is listening over at NAI. > > Years ago I bought a few copies of commercial PGP with support. I > sent in three separate bug reports, some of them dead simple to > reproduce, and never got anything back except placebo talk. I think people used to get better support when I personally answered [EMAIL PROTECTED] I stopped providing that service due to lack of time, and I'm afraid that PGP support went out the window. From my perspective, NAI never provided any support for PGP -- even when I submitting patches, they would ignore them. Even worse, when I *DID* respond to someone on pgp-bugs, I'd get a response from NAI saying that they couldn't help me! Yes, those bozos actually responded to my _answer_ with a "we cannot help you" message. Sigh. So, no, I'm not surprised to hear this from an actual paying customer. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PGP & GPG compatibility
Is there even development on the PGP (product) line? AFAIK they (NAI) have not release PGP 7.x in source form. Worse, there are a couple of bugs I found in 6.5.8 when I was porting it to Tru64, but who knows if anyone is listening over at NAI. It's a sad state of affairs. Perhaps I should go into "PGP consulting", but I don't know if anyone would pay me to support PGP for them -derek Werner Koch <[EMAIL PROTECTED]> writes: > On Sat, 3 Jan 1970 09:41:26 +1000, Nicholas Brawn said: > > > What's the state of the game with PGP and GPG compatibility? > > According to the bug reports I receive for GnuPG, it seems that even > the latest versions of PGP (7.0.3?) are still not OpenPGP compatible. > At least they still don't understand version 4 signatures on data > packets (only on keys). I had in mind that this was fixed some time > ago, but obviously this isn't the case. > > There is a problem wrt text mode signatures: no agreement was found on > what a line ending consists of. PGP translates a CR inside a line > (well, what most non Apple programmers consider a line ending) into a > CR,LF sequence for hashing. The proper solution is not to use > textmode signatures except for cleartext signed messages. > > About two years ago we agreed on a way to implement MDC and defined > new packet types for it. I did some tests with Hal Finney and it used > to work. The OpenPGP draft was later changed to introduce key flags > and use one to enable MDC mode. However, GnuPG uses MDC mode with all > ciphers of a block length other than 64 bits (i.e. Twofish and AES*). > The draft has still not been released as a new RFC so this may change > again :-(. > > The flaw in the secret key protection mechanism was discussed for a > short time but it seems that nobody is willing to continue with this. > I made several suggestion on how to do it. > > Interoperability tests should have happened last summer but for > unknown reasons they didn't. It is very sad to see that after 3 years > we have not achieved to get OpenPGP into draft status :-(. > > > Werner > > -- > Werner KochOmnis enim res, quae dando non deficit, dum habetur > g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. > Privacy Solutions-- Augustinus > > > > > --------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Michael Sierchio <[EMAIL PROTECTED]> writes: > Carl Ellison wrote: > > > If that's not good enough for you, go to https://store.palm.com/ > > where you have an SSL secured page. SSL prevents a man in the middle > > attack, right? This means your credit card info goes to Palm > > Computing, right? Check the certificate. > > To be fair, most commercial CA's require evidence of "right to use" > a FQDN in an SSL server cert. But your point is apt. Yes, but it only takes one of the hundreds of CAs to fail to make this check and the whole system fails. C.f. Verisign signing a fake MicroSoft cert last year -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Lynn, I think you should specify "confidentiality" as another issue to be addressed. Perhaps you include confidentiality in your "privacy" or "security" subsections, but I've found that many people think (and mean) different things when they use these two terms. For example, is privacy necessarily privacy of communicated data from eavesdroppers, or is it the privacy of personal information (perhaps the privacy of the authentication information) so an eavesdropper does not know who is communicating? Unfortunately your garlic.com URL (security.htm) does not work and returns an HTTP 404 error. -derek [EMAIL PROTECTED] writes: > sometimes the "principles" of security are referred to as PAIN or sometims > PAIIN > > see > http://www.garlic.com/~lynn/security.htm > > and click on PAIN & PAIIN in the acronym section of the glossary. > > Doing a threat model ... would include not only end-to-end issues but > what aspects of PAIIN are being addressed. > privacy, authentication, identification, integrity, non-repudiation (PAIIN) > (see also authentication, identification, integrity, non-repudiation, > privacy, security) > > an aspect of security can be integrity and and aspect of integrity can be > dependability leading to things like: > http://www.hdcc.cs.cmu.edu/may01/index.html > > which is then related back to my posting on sunday (with regard to > integrity) > http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop > > > > > > [EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote: > > > to which I would add: > > 3. Cryptography, and therefore PKI, is meaningless unless you first > define a threat model. In all the messages with this Subject, I've > only see one person even mention "threat model". Think about the > varying threat models, and the type of cryptography one would propose > to address them. Even the most common instance of encryption, > encrypted web forms for hiding credit card numbers, suffers from > addressing a limited threat model. There's a hell of a lot of known > plaintext there. > > > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: FreeSWAN Release 1.93 ships!
Note that to compile FreeS/WAN on Red Hat using the Red Hat kernel-source RPM you need to: rm include/linux/modules/*.ver before you 'make dep'. Otherwise you get module version brokenness. -derek "Lucky Green" <[EMAIL PROTECTED]> writes: > The big question is: will FreeS/WAN latest release after some 4 or 5 > years of development finally both compile and install cleanly on current > versions of Red Hat Linux, FreeS/WAN's purported target platform? > > --Lucky, who is bothered by the fact that most his Linux using friends > so far have been unable to get FreeS/WAN to even compile into a working > kernel, while just about every *BSD distribution - and for that matter > Windows XP - ship with a working IPSec implementation out-of-the-box. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Stewart > > Sent: Thursday, December 06, 2001 2:05 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: FreeSWAN Release 1.93 ships! > > > > > > From Claudia Schmeing <[EMAIL PROTECTED]>'s summary: > > <http://lists.freeswan.org/pipermail/briefs/> > > = > > > > 1. Release 1.93 ships! > > === > > 1 post Dec 3 > > > > http://lists.freeswan.org/pipermail/users/2001-December/005632 > .html > > A number of small improvements have been added to this release, which > was shipped on-time. > > Some highlights: > > * Diffie-Hellman group 5 is now the first group proposed. > * Two cases where fragmentation is needed will be handled better, thanks >to these two changes > > The code that decides whether to send an ICMP complaint back > about > a packet which had to be fragmented, but couldn't be, has gotten > smart enough that we now feel comfortable enabling it by > default. >and > > IKE (UDP/500) packets which were large enough to be fragmented > used > to be mishandled, with some of the fragments failing to bypass > IPsec > tunnels properly. This has been fixed; our thanks to Hans > Schultz. > > * If Pluto gets more than one RSA key from DNS, it will now try each > key. >This will help when a system administrator replaces a key. > * There is preliminary support for building RPMs. > * SMP support is better. > * The team has eliminated a vulnerability that might permit a denial of > service >attack. > > What can we expect from the next release? Henry Spencer writes: > > We are in the process of chasing down a couple of significant bugs > (which > have been there since at least 1.92 and possibly earlier), and we > *might* > ship another release quite shortly if we nail them down and fix > them. If > we don't, we won't. Barring that possibility, the next release is > planned > for the end of January; a more precise date will be announced > shortly. > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: private-sector keystroke logger...
Hrm, how about a worm with a built-in HTTP server that installs itself on some non-standard port, say TCP/28462 (to pick one at random)? -derek Steve Bellovin <[EMAIL PROTECTED]> writes: > It's not just the FBI, of course. There are press reports this morning > of a new worm, Badtrans.b, that not only leaves behind a Trojan horse, > it includes a keystroke logger. Now, that particular leakage isn't a > major concern, since it emails the stolen text to an account that's now > been shut down, but I'm sure we can all think of other ways to export > information like that. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Scarfo "keylogger", PGP
The same is true of, say, libX11.so, or worse, libpam.so, on Unix systems. -derek "Trei, Peter" <[EMAIL PROTECTED]> writes: > One of my continual gripes about Windows security has to do with the GUI > DLLs. An attacker could silently replace a component with one which has > the old version number and the same API as the normal one, but which > does something extra - for example, the component which handles the > textbox for entering passwords could check the system table to see if > the active program was PGP, and if so log the text entered. The user > would be none the wiser, and even re-installing PGP would not restore > security. > > A secure system would use crytographically signed components, > and an application would check the signatures before loading a > dynamic library. An attacker would then need to get the trojaned > components signed, which raises the bar. > > Windows XP at least checks for drivers not signed by MS, but > whose security this promotes is an open question. > > Peter Trei > > > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New encryption technology closes WLAN security loopholes
Heh. I've been arguing for YEARS that classic firewalls, as they have been used for even more years, have been a disservice to network security. You know, the whole "hard, crunchy exterior with soft, chewy interior" sort of thing. Instead if we had ubiquitous multi-level secure services (using IPsec, SSL, SSH, PGP, Kerberos, etc.) it would be a much better world. -derek [EMAIL PROTECTED] writes: > > Or in other words, the first requirement for perimeter security is a perimeter. > > In increasingly many environments, the term "perimeter" makes little sense. > See, for example, the CCS-2000 paper on Distributed Firewalls by Sotiris > Ioannidis et al. You can get it (among other places) from > http://www.research.att.com/~smb/papers/ccs-df.pdf > > /ji > > (for the curious, the Ioannidis on that paper is my brother, not I). > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: secure IRC/messaging successor
gale has scaling problems to large numbers of users, in particular for group messaging. -derek Eugene Leitl <[EMAIL PROTECTED]> writes: > Gale http://www.gale.org/ seems a well thought out infrastructure. Is the > consensus "this is it", or have I missed any alternatives? -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: moving Crypto?
There are many alternative conferences than Crypto, and many of them are already outside the US. Indeed, the IACR already runs EuroCrypt and AsiaCrypt. Personally, I think that trying to move Crypto is just an over-reaction to the current situation. If the situation really does get worse (and the egg-in-face arrest wasn't an abberation) then perhaps the conference should get moved to a more friendly North American country. -derek "Donald E. Eastlake 3rd" <[EMAIL PROTECTED]> writes: > So people will not be subject to the recent US laws purchased from > Congress against the public interest by some publishers? > > I don't know why anyone would care that much about my opinion since I > don't attend Crypto but I think Vancouver is a great location. > > Donald > > From: Derek Atkins <[EMAIL PROTECTED]> > To: Richard Schroeppel <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > References: <[EMAIL PROTECTED]> > Date: 31 Jul 2001 19:09:03 -0400 > In-Reply-To: Richard Schroeppel's message of "Tue, 31 Jul 2001 13:13:34 -0700 (MST)" > Message-ID: <[EMAIL PROTECTED]> > > >Why do you say it's time to move the conference? AFAIK, it's ALWAYS > >been in SB. Too bad I can't make it this year :( > > > >-derek > > > >Richard Schroeppel <[EMAIL PROTECTED]> writes: > > > >> It's time to consider moving the annual Crypto conference out of > >> Santa Barbara. The obvious places are Vancouver, Toronto, or > >> Mexico. I know zilch about these places as conference venues. > >> Could someone knowledgable summarize the relative merits? > >> > >> Rich Schroeppel [EMAIL PROTECTED] > >> > >> - > >> The Cryptography Mailing List > >> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > > > >-- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH > > [EMAIL PROTECTED]PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: moving Crypto?
Why do you say it's time to move the conference? AFAIK, it's ALWAYS been in SB. Too bad I can't make it this year :( -derek Richard Schroeppel <[EMAIL PROTECTED]> writes: > It's time to consider moving the annual Crypto conference out of > Santa Barbara. The obvious places are Vancouver, Toronto, or > Mexico. I know zilch about these places as conference venues. > Could someone knowledgable summarize the relative merits? > > Rich Schroeppel [EMAIL PROTECTED] > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Company Awarded Patent for "Digital Tickets" (was Re: GigaLaw.com Daily News, July 30, 2001)
This also looks very similar to my Master's Thesis, where I even use the term "digital ticket"! Sheesh. -derek Peter Wayner <[EMAIL PROTECTED]> writes: > I discuss this in both editiions of _Digital Cash_. I wonder if this > is prior art that reads against the patent. > > -Peter -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Crypto hardware
Are you talking about the BBN/GTE SafeKeyPer (I may have mis-spelled that)? I don't know if they are still on the market -- they were priced Really High. -derek Kent Crispin <[EMAIL PROTECTED]> writes: > A couple of years ago at the RSA conference one of the vendors was > exhibiting a tamperproof that would keep a secret key and perform > encryptions/signatures using the key. Since the key never left the > box, in theory security reduced to physical security around the box. > The intended use of the box was as a master for a CA. I thought the > vendor was GTE, but I didn't find anything definitive on their site. > > Does this description trigger any recollection? Are there similar > devices on the market from other sources? > > -- > Kent Crispin "Be good, and you will be > [EMAIL PROTECTED] lonesome." -- Mark Twain > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: crypto flaw in secure mail standards
This works fine in a peer-to-peer scenario, but not if you have a
one-to-many transmission. Just because you have a message signed in
the set {Alice,Bob,Charlie,Daniel,Eve,Fred,Greg}, there is no way to
know which of them sent it. All members of the set must be mutually
trusted, which means there is no way to sign a document that a set of
people can verify comes EXACTLY from you.
-derek
dmolnar <[EMAIL PROTECTED]> writes:
> So Alice signs document D as being from the set {Alice, Bob} and sends it
> to Bob. Now Bob knows he didn't write D, so he believes it's from Alice.
> If he passes D along to Charlene, she can't determine whether Alice
> wrote D or Bob came up with it himself.
>
> In fact, IIRC, the paper suggests the sorts of scenarios discussed in this
> thread explicitly as the motivation for this use of ring signatures. The
> paper then goes on to argue for the practicality of implementing ring sigs
> in mail clients.
>
> -David
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: crypto flaw in secure mail standards
This is not a crypto flaw. This is an engineering flaw. First, the timestamp of the message is certainly encoded in the signature. This is protection against your first suggested attack. The recipient, upon verifying the signature, notices that it was made, e.g., two months previously. Then one would have to wonder why a two-month-old message was being sent. The other obvious problem is that although the sender's identity is encoded in the message's signature (as well as the time the signature is purported to be made), the original intended recipient's are not encoded within the signed portion of the message. The simple fix would be to include the appropriate mail headers withing the signed portion of the message. In particular, including the 'To' and 'Cc' fields would immediately protect against both of these attacks. The problem is not at all with the crypto. The problem is with the integration of the crypto with applications like e-mail. Have a nice day, -derek Don Davis <[EMAIL PROTECTED]> writes: > All current secure-mail standards specify, as their "high- > security" option, a weak use of the public-key sign and encrypt > operations. On Thursday the 28th of this month, I'll present > my findings and my proposed repairs of the protocols, at the > Usenix Technical Conference here in Boston: > http://www.usenix.org/events/usenix01/usenix01.pdf > > Citation: > Don Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, > PEM, PGP, and XML." To appear in Proc. Usenix Tech. Conf. 2001, > Boston. June 25-30, 2001. > > A short summary: All current secure-mail standards have a > significant cryptographic flaw. There are several standard > ways to send and read secure e-mail. The most well-known > secure mail systems are PGP and S/MIME. All current public- > key-based secure-mail standards have this flaw. Here are some > examples of the flaw in action: > > Suppose Alice and Bob are business partners, and are setting > up a deal together. Suppose Alice decides to call off the > deal, so she sends Bob a secure-mail message: "The deal is off." > Then Bob can get even with Alice: > > * Bob waits until Alice has a new deal in the works > with Charlle; > * Bob can abuse the secure e-mail protocol to re-encrypt > and resend Alice's message to Charlie; > * When Charlie receives Alice's message, he'll believe > that the mail-security features guarantee that Alice > sent the message to Charlie. > * Charlie abandons his deal with Alice. > > Suppose instead that Alice & Bob are coworkers. Alice uses > secure e-mail to send Bob her sensitive company-internal > sales plan. Bob decides to get his rival Alice fired: > > * Bob abuses the secure e-mail protocol to re-encrypt and > resend Alice's sales-plan, with her digital signature, > to a rival company's salesman Charlie. > * Charlie brags openly about getting the sales plan from > Alice. When he's accused in court of stealing the plan, > Charlie presents Alice's secure e-mail as evidence of > his innocence. > > Surprisingly, standards-compliant secure-mail clients will > not detect these attacks. > > -- > Abstract >Simple Sign & Encrypt, by itself, is not very secure. > Cryptographers know this well, but application programmers > and standards authors still tend to put too much trust > in simple Sign-and-Encrypt. In fact, every secure e-mail > protocol, old and new, has codified na=EFve Sign & Encrypt > as acceptable security practice. S/MIME, PKCS#7, PGP, > OpenPGP, PEM, and MOSS all suffer from this flaw. > Similarly, the secure document protocols PKCS#7, XML- > Signature, and XML-Encryption suffer from the same flaw. > Na=EFve Sign & Encrypt appears only in file-security and > mail-security applications, but this narrow scope is > becoming more important to the rapidly-growing class > of commercial users. With file- and mail-encryption > seeing widespread use, and with flawed encryption in > play, we can expect widespread exposures. > > In this paper, we analyze the na=EFve Sign & Encrypt flaw, > we review the defective sign/encrypt standards, and we > describe a comprehensive set of simple repairs. The > various repairs all have a common feature: when signing > and encryption are combined, the inner crypto layer must > somehow depend on the outer layer, so as to reveal any > tampering with the outer layer. > > > > Once I've presented the paper, I'll make this link live: > http://world.std.com/~dtd/sign_encrypt/sign_e
Re: McNealy -- Get over it, Part Two (was Re: BNA's Internet Law News (ILN) - 05/30/2001)
Dan Geer <[EMAIL PROTECTED]> writes: > The point is not that there might be another way, the point is > that understanding the bargain to be as he describes it, Scott > finds it an acceptable one. He is far from alone, I'd wager. How many of you in the NY/NJ/MA area use FastLane/EZ-Pass? This is certainly an exchange of privacy for convenience. > --dan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: article: german secure phone
It's sad that these guys couldn't at least be compatible with the Starium guys. -derek Don Davis <[EMAIL PROTECTED]> writes: > http://www.newscientist.com/dailynews/news.jsp?id=3Dns819 > > Portable privacy > > A mobile phone that protects transmissions from > sophisticated eavesdropping is launched in Germany > > A mobile phone that protects transmissions from > sophisticated eavesdropping has been launched in > Germany. > > Communications company Rohde Schwarz created the TopSec > GSM phone by fitting military grade encryption hardware > into an ordinary S35i Siemens mobile phone. > > The company expects the device to appeal to businessmen > who want to protect themselves against industrial > espionage and government representatives concerned > about spying. "In both cases communications have to be > secure," says a company representative. > > Ex-Nato technical expert Brian Gladman told New > Scientist: "If done correctly, the encryption would be > effectively attack-proof." > > Although the GSM standard does protect transmissions by > encoding them, a number of weaknesses have been > discovered with the system. These could allow > sophisticated eavesdroppers to listen in. The TopSec > GSM phone is designed to provide an extra, robust layer > of security. > > The phone may not be for everyone, however. Each device > costs =A31800 and so far only 500 handsets have been > created. These must also be bought directly from Rohde > Schwarz. > > Private keys > > The handset works like any normal GSM mobile phone. But > users can establish a secure communications channel > when "Crypto" is selected from the customised display > menu. When a number is dialled and the Crypto function > selected, the phone checks to see if the device at the > other end is compatible. Currently, the phone works > only with other TopSec mobile phones and ISDN phones > produced by Rohde Schwarz. > > If the device at the other end is compatible, each > phone opens a data channel and exchanges its public > encryption key. Using mathematically-linked private > keys, the phones then establish a shared code for > securing voice communications at speed. > > It is theoretically possible to decipher messages > encrypted in this way by trying all possible keys in > succession. But in practice this would require a > formidable amount of computational power. Rohde Schwarz > estimates that it would take 100 average desktop > computers 10 years to decrypt a 10-minute phone call. > > Attack-proof > > Although the encryption itself may be secure, Gladman > says it might be possible to trick the phones into > giving up their secrets using a "man in the middle" > attack. This would involve carrying out a dummy key > exchange with both parties and creating two secure > channels. Each party would be communicating securely, > but only through a third eavesdropper. > > This technique would be beyond most industrial spies. > Gladman says it might be within the capabilities of > some government intelligence agencies, however. > > Devices that work along similar lines are already used > by the US military. And this is not the first attempt > to make a commercial encryption phone. US company > Starium has created a device that can be attached to > standard phone lines in order to secure voice > communications with encryption. > > Web link: > Rohde Schwarz http://www.rohde-schwarz.com/ > > 1630 GMT, 31 May 2001 > > > > - > > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
