February 2003 - cypherpunks-legacy

DOJ worried about domestic-int'l terror links
by Declan McCullagh 10 Feb '03

10 Feb '03

http://www.dailyrotten.com/source-docs/patriot2draft.html The limitation to international terrorism in existing law is an impediment to the effective use of national security letters because it may not be apparent in the early stages of a terrorism investigation-or even after it has continued for some time-whether domestic or international terrorism is involved. The Oklahoma City bombing and the anthrax letter incidents illustrate this point. Moreover, in the current circumstances, domestic terrorists who attempt to ally with or are inspired to emulate international terrorists are an increasing concern. The dangers posed to the national security by such persons may be comparable to those posed by international terrorists, and national security letters should likewise be an available tool in the investigation of their criminal activities.

1 0

Re: Putting the "NSA Data Overwrite Standard" Legend to Death... (fwd)
by Dave Howe 10 Feb '03

10 Feb '03

Jim Choate wrote: > On Sun, 9 Feb 2003, Dave Howe wrote: > >> Jim Choate wrote: >>> Yes, it can mount the partition. That isn't the problem. The problem >>> is that for lilo to do this it has to have access to the key in >>> plaintext. That makes the entire exercise moot. >> not if you have to type it every time. > Then I'd say lilo isn't mounting it, you are. no, lilo is. if you you can mount a pgpdisk (say) without software, then you are obviously much more talented than I am :) for virtual drives, the real question is at what point in the boot process you can mount a drive - if it is not until the os is fully functional, then you are unable to protect the os itself. if the bootstrap process can mount the drive before the os is functional, then you *can* protect the os. Win9x uses dos as its bootstrap (and drivespace gives a good example of a virtual drive system that can hand over to a 32bit driver as the os starts). lilo *could* kick a virtual drive into existence during the kernel boot, given such a driver and some patches to both kernel and lilo itself. that it would need a password from somewhere during this process is both obvious and not a major issue.

1 0

Re: Forced Oaths to Pieces of Cloth
by Bill Frantz 10 Feb '03

10 Feb '03

At 6:55 AM -0800 2/9/03, Sunder wrote: >And also freedom of religion. Forcing someone to say "Under God" for >example. Back in the dark ages (the 1950s, and don't anyone get nostalgic for them), when the phrase "under god" was added to the pledge, I was a student in school. From what they had taught me, I knew then that this addition violated the establishment of religion clause. The solution I devised was to simply remain silent when this phrase was said. Unfortunately having started to question the relation between the pledge and the ideals of the country, I started to wonder why I was pledging to the flag, instead of the country. So over the years, I have a somewhat edited version (removed parts in brackets): I pledge allegiance to [the flag of] the United States of America [and to the republic for which it stands], one nation [under god], indivisible, with liberty and justice for all. Except for the fact that one should not trust pledges that are made under coercion, I am reasonably comfortable with this edited version. It expresses the ideal nation that I wish the United States would become. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the Ameican | 16345 Englewood Ave. frantz(a)pwpconsult.com | way. | Los Gatos, CA 95032, USA

3 2

Re: Putting the "NSA Data Overwrite Standard" Legend to Death... (fwd)
by Dave Howe 10 Feb '03

10 Feb '03

Jim Choate wrote: > Yes, it can mount the partition. That isn't the problem. The problem > is that for lilo to do this it has to have access to the key in > plaintext. That makes the entire exercise moot. not if you have to type it every time. if you take that as criteria, then *all* encryption is moot, as I can't think of any you don't have to supply a key or passphrase for. you could also have lilo look at a dongle (a usb drive, say) for its key.

1 0

RE: Forced Oaths to Pieces of Cloth
by Trei, Peter 10 Feb '03

10 Feb '03

> Bill Frantz[SMTP:frantz@pwpconsult.com] [...] > Unfortunately having started to question the relation between the pledge > and the ideals of the country, I started to wonder why I was pledging to > the flag, instead of the country. So over the years, I have a somewhat > edited version (removed parts in brackets): [...] One interesting variation {and a suggestion of an alternative) comes from naval diplomacy. When there's an official US/UK naval dinner, toasts are drunk (at least on shore or on British ships - I think US ships are dry). The Americans always toast the British Monarch. The Brits in return propose a toast to the US Constitution. While I have a lot of problem with the Pledge in any form, I think it would be greatly improved if it were made to the Constitution, rather than the flag. Peter Trei

1 0

Re: Putting the "NSA Data Overwrite Standard" Legend to Death... (fwd)
by David Howe 10 Feb '03

10 Feb '03

at Monday, February 10, 2003 3:09 AM, Jim Choate <ravage(a)einstein.ssz.com> was seen to say: > On Mon, 10 Feb 2003, Dave Howe wrote: >> no, lilo is. if you you can mount a pgpdisk (say) without software, >> then you are obviously much more talented than I am :) > Bullshit. lilo isn't doing -anything- at that point without somebody > or something (eg dongle) being present that has the -plaintext- key. > Without the key the disk isn't doing anything. So no, lilo isn't > mounting the partition. It -is- a tool to do the mount. I don't understand why this concept is so difficult for you - software *must* perform the mount; there is absolutely no way you could personally inspect every byte from the disk and pass decrypted data to the os at line speed yourself. lilo is the actor here. If you gave a program spec to a programmer and said "write this" you wouldn't be able to claim you wrote the code yourself, no matter how good or essential the program spec was. > As to mounting the disk without software, not a problem it could be > done all in hardware. Though you'd still need the passphrase/dongle. you couldn't *mount* a disk in hardware; you *could* decrypt on-the-fly and make the physical disk look like a unencrypted one, but you would still need non-crypto software to mount it. >> for virtual drives, the real question is at what point in the boot >> process you can mount a drive - if it is not until the os is fully >> functional, then you are unable to protect the os itself. if the >> bootstrap process can mount the drive before the os is functional, >> then you *can* protect the os. > No you can't. If the drive is mounted before the OS is loaded you can > put the system into a DMA state and read the disk (screw the OS) > since it's contents are now in plaintext. no, you can't. data from the hardware is *still* encrypted; only the output of the driver is decrypted, and a machine no longer running bootstrap or os is also incapable of decryption. you *could*, if good enough, place the processor in a halt state and use DMA to modify the code to reveal the plaintext, but it would be a major pain to do so and would require both physical access to the machine *while powered up and without triggering any anti-tamper switches* after the password has been supplied. This is actually a weakness in firmware cryptodrives (as I have seen advertised recently) - once the drive is "unlocked" it can usually be swapped over to another machine and the plaintext read. > You can also prevent the > default OS from being loaded as well. Indeed so, yes. however, usually that decision has to be made before the password would be entered - so making more awkward. you *could* finangle the bootstrap though; there must *always* be part of the code outside the crypto envelope (but of course this can be removable media such as the usb drive mentioned, and stored securely when not in use) > Clue: If you own the hardware, you own the software. indeed so. however, if that applied to machines not already running, the police wouldn't be so upset when they find encrypted files on seized hardware.

1 0

RE: Columbia crypto box
by bear 09 Feb '03

09 Feb '03

On Sat, 8 Feb 2003, Lucky Green wrote: >In July of 1997, only days after the Mars Pathfinder mission and its >Sojourner Rover successfully landed on Mars, I innocently inquired on >the Cypherpunks mailing list if any subscribers happened to know if and >how NASA authenticates the command uplink to what at the time was >arguably the coolest RC toy in the solar system. ... >Apparently, my original inquiry had been copied and forwarded several >times. By the time my inquiry had reached the office of the President, >just as in a children's' game of telephone, my question of "are they >using any decent crypto" had turned in to "hackers ready to take over >Mars Rover". ... >Needless to say and regardless of anyone's intent, such concern >would be entirely unfounded if the uplink were securely authenticated. > >Which I believes represents an answer to my initial question as to >whether the uplink is securely authenticated. Actually, I don't think it does. It's been my experience that the decision-makers never even *KNOW* whether their systems are secure. They've been sold snake-oil claims of security so many times, and, inevitably, seen those systems compromised, that even when responsible and knowledgeable engineers say a system is secure, they have to regard it as just another claim of the same type that's been proven false before. So I can easily imagine them just not knowing whether the link was secure, thinking that the NASA engineer's job of "securing" uplinks might be no better than Microsoft's job of "securing" communications or operating systems, because they've had it demonstrated time and again that even when they hear words like "secure", the system can be compromised. The fact is that the NASA engineer has a huge advantage; s/he's not working for a marketing department that will toss security for convenience, s/he's not working on something whose code has to be copied a million times and distributed to people with debuggers all over the world, s/he's not trying to "hide" information from people on their own computer systems, and s/he's not complying with deals made with various people that require backdoors and "transparency to law enforcement" in every box. So the NASA engineer's actually got a chance of making something secure, where the Microsoft engineer didn't. Microsoft has to claim their junk is secure, but in their case it's just marketing gas. But all this is below the notice of the decision makers; they *LIVE* in a world where marketing gas is indistinguishable from reality, because they don't have the engineer's knowledge of the issues. So having the decision makers get real nervous was likely to happen, whether the link is secure or not. There's no information there except that the decision makers have finally realized they don't really *know* whether the link is secure. That's progress, of a sort. >[Remind me to some time recount the tale of my discussing key management >with the chief-cryptographer for a battlefield communication system >considerably younger than the shuttle fleet. Appalling does not being to >describe it]. Battlefield systems have been that way forever. Battlefield information only has to remain secure for a few seconds to a few hours, and they exploit that to the max in making the systems flexible and fast enough for actual use. You want appalling? In the civil war, they used monoalphabetic substitution as a "trench code" -- on both sides. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG
by Steve Schear 09 Feb '03

09 Feb '03

[Apologies if this item was passed through the list. It was news to me.] Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG K. Jallad, J. Katz, and B. Schneier Information Security Conference 2002 Proceedings, Springer-Verlag, 2002, to appear. ABSTRACT: We recently noted that PGP and other e-mail encryption protocols are, in theory, highly vulnerable to chosen-ciphertext attacks in which the recipient of the e-mail acts as an unwitting "decryption oracle." We argued further that such attacks are quite feasible and therefore represent a serious concern. Here, we investigate these claims in more detail by attempting to implement the suggested attacks. On one hand, we are able to successfully implement the described attacks against PGP and GnuPG (two widely-used software packages) in a number of different settings. On the other hand, we show that the attacks largely fail when data is compressed before encryption. Interestingly,the attacks are unsuccessful for largely fortuitous reasons; resistance to these attacks does not seem due to any conscious effort made to prevent them. Based on our work, we discuss those instances in which chosen-ciphertext attacks do indeed represent an important threat and hence must be taken into account in order to maintain confidentiality. We also recommend changes in the OpenPGP standard to reduce the effectiveness of our attacks in these settings. http://www.counterpane.com/pgp-attack.html "Reality must take precedence over public relations, for nature cannot be fooled." -- Richard P. Feynman --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

The Crypto Gardening Guide and Planting Tips
by pgut001＠cs.auckland.ac.nz 07 Feb '03

07 Feb '03

After much procrastination I recently put the Crypto Gardening Guide and Planting Tips online at http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, this may be of interest to readers. From the introduction: There has been a great deal of difficulty experienced in getting research performed by cryptographers in the last decade or so (beyond basic algorithms such as SHA and AES) applied in practice. The reason for this is that cryptographers don't work on things that implementors need because it's not cool, and implementors don't use what cryptographers design because it's not useful or sufficiently aligned with real-world considerations to be practical. As a result, security standards are being created with mechanisms that have had little or no security analysis, often homebrew mechanisms or the standards editor's pet scheme. The problem is a lack of communication: Cryptographers often don't seem aware of the real-world constraints that their design will need to work within in order to be successfully deployed. The intent of this document is to cover some of those real-world constraints for cryptographers, to point out problems that their designs will run into when attempts are made to deploy them. Also included is a motivational list of extremely uncool problems that implementors have been building ad-hoc solutions for since no formal ones exist. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

3 2

Re: Feds pull plug on suspicious "cyberwarfare" .gov site
by Mike Rosing 05 Feb '03

05 Feb '03

On Wed, 5 Feb 2003, Declan McCullagh wrote: > Wonder if any current .gov domains are owned by individuals pulling a prank? > > -Declan > > >Date: Wed, 5 Feb 2003 08:46:20 -0500 > >From: Declan McCullagh <declan(a)well.com> > >To: politech(a)politechbot.com > >Subject: FC: Feds pull plug on suspicious "cyberwarfare" .gov site > > > >I've placed a mirror of AONN.gov here: > >http://www.politechbot.com/docs/aonn/ I followed down the page and found a name, then googled for it. Check this out and laugh your butt off! http://www.manhunt.com/features/html/89.shtml Patience, persistence, truth, Dr. mike

1 0