December 2003 - cypherpunks-legacy

TEST
by apache＠bear.apana.org.au 17 Dec '03

17 Dec '03

latency test

1 0

Equinox/cypherpunks/www
by Andy Brown 17 Dec '03

17 Dec '03

Anyone that missed or was unable to get the UK TV programme Equinox might like to take a look at: http://www.cityscape.co.uk/channel4/big_bytes/cybersecrecy/cyber000.html - Andy

1 0

Secure Device 1.4 Question Secure Device 1.4 Question
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

I just installed Secure Device, v1.4 on a PC at work. After installing it, I looked at the encrypted volume and found the string "SECDEV " starting at the fourth byte of the file. I'd prefer that this file look like some temporary file that got left on the disk by a program that didn't clean up properly after itself, and not be identifiable as an encrypted volume. Is there a way to get Secure Device to not leave identifiable plaintext like that in the file? Will I do any harm to the file if I replace that string with blanks, or something more innocuous? If it's required to be there, then I'd like to put its removal on the "wish list" for the next version. (I copied the file, replaced the string "SECDEV" with blanks using a hex editor, and then mounted the copy as an encrypted volume, and it seems to be working OK, but I wanted to make sure this won't cause unforseen problems in the future.) As you've probably guessed, I'm not supposed to have any personal files on my work computer, and an entire encrypted volume would undoubtedly make someone go ballistic if they discovered it. When I want to use my encrypted file system, I reboot off of a floppy, and all Secure Device programs and drivers are kept on the floppy. The only thing that has to be left on the hard drive is the encrypted volume itself. Please post a copy of any replies to the Cypherpunks mailing list at "cypherpunks(a)toad.com". Thanks.

2 1

RE: Mathematics > NSA + GCHQ
by rab＠stallion.oz.au 17 Dec '03

17 Dec '03

This thread touches a memory of mine from 18 years ago when I was at university. While studying for a mathematics exam I became sidetracked by one of Fermat's Theorems (Last? or Little?) and am convinced to this day that I came up with an algorithm for determining if a number was prime by a "simple" combination of shifts and logical operations. The beast part was that the amount of calculation was linearly related to the number of bits in the binary representation of the number. I only ever spent a couple of hours on it, working through it on paper, and after the exams were finished and I went back to it I could not find the original notes and I could not remember exactly what I had done. However it seems like someone else has... > ---------- > From: Dr.Dimitri Vulis KOTM[SMTP:dlv@bwalk.dm.com] > Sent: Saturday, 23 August 1997 7:12 > To: cypherpunks(a)toad.com > Subject: Re: Mathematics > NSA + GCHQ > > > John Young <jya(a)pipeline.com> writes: > > > Along this line: > > > > A few days ago we received an 8-page excerpt from "Shift Register > > Sequences," by Solomon W. Golomb (at USC), Holden-Day, Inc., > > no date, with a handwritten note: > > > > NSA has tried to suppress knowledge of this stuff. Nearly all NSA > 'good' > > algorithms are based on this technology. > > > > IANAM, so would any of the mathematicians here give any credibility > to > > this claim? We'll scan and put the excerpt on our Web site if > worthwhile. > > It's composed of the book's 3 page preface and 5 pages of text and > > diagrams of Chapter 2 on The Shift Register as a Finite State > Machine, > > with principal focus on de Bruijn diagrams for shift registers. > > The NSA certainly did try to suppress much shift-register-related > stuff. > > The recent Sandia lawsuit is over shift register stuff. > > There are increasingly persistent rumor of a fast factoring algorithm > based on shift registers. > > Therefore anything mentioning them is of interest. > > But: Was there any info in the package other than the passages from > the book? > > I don't think it's a good idea to put up chunks of the book - the > publisher > might cry copyright infringement, and everybody probably has it > anyway. > > [I'm about to turn off this box, so I won't see any responses in a > while.] > > --- > > Dr.Dimitri Vulis KOTM > Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, > 14.4Kbps >

1 0

Re: Police and scientology visit XS4ALL Amsterdam
by Kari Laine 17 Dec '03

17 Dec '03

> PRESS RELEASE > ------------- > Police and members of Scientology church enter offices of XS4ALL > ================================================================ They really are not getting it - are they stupid or what? Scientology people are not behaving so I take a standing that I don't have to behave when I treat them as well. Good, remember they started it ... > Today at about 14:00, XS4ALL was visited by Mr. S. Braan, > bailiff. Sorry to hear that Mr. Braan >Religious Technology Centre O camoon - that name sounds great what's inside it? Research department of Brainwashing? Wast that the technology you tried to sell to CIA? And luckily CIA told you to piss off. >, better known as the Scientology Church, or > Scientology for short. He was assisted by a local police officer and Mr. > Hermans from the 'Nauta-Dutilh' legal firm that represents Scientology > in The Netherlands. We would need a list of all legal offices representing scienos in all countries. Also does anyone has a list of top scienos and some kind of organization flow chart of this evil emperium? >Also present were two computer experts (Mr. Ootjes > and Mr. Van Suchtelen) a locksmith (to enter had we not been present) and > two American employees of Scientology, Mr. Weightman and Ms. Jenssen. Does anyone has tel number to these Co$s? > Scientology is filing for seizure of XS4ALL's computer equipment. Under > dutch law, this means that a bailiff comes in to record your assets. In > real-life, the computer-experts that were present have recorded the > types and serial numbers of all the computers in our offices. They did > not take any equipment, the continuity of XS4ALL's services is not in > jeopardy. Good - you have civilised police there. > XS4ALL is not alone in receiving this kind of attention from > Scientology. Scientology, a semi-religious multinational, is at war with > a number of people on the Internet. They wan't a war - well let's give them one! I don't mean this bashing in the net - I mean a REAL WAR! Co$ has been on offensive for some time now and they must be got to the defence mode. > Until recently, the church has always managed to supress critical voices > by means of sheer intimidation and by engaging in endless legal battle. I think it would be a jolly good day if they would try that against me. I would make best of it... > One of these documents is a piece to which Scientology supposedly holds > the copyright and which has been added to the kit without the church's > permission. Screw with their permission. Sorry for the raw language but I get so damn angry when I even see these scienos mentioned. To fight them we need an organization to fight them. Todays situation is like uncontrolled and thefore unoptimised guerrilla operations. Results will be weak. Best Regards Kari Laine Kari Laine buster(a)klaine.pp.fi LAN Vision Oy Tel. +358-0-502 1947 Sinikalliontie 14 Fax +358-0-524 149 02630 ESPOO BBS +358-0-502 1576/1456 FINLAND

1 0

Searchable Crypto Paper Archive?
by David J. Bianco 17 Dec '03

17 Dec '03

[My apologies if this is a repost. The original was posted a a couple of days ago via a news gateway which may or may not have actually worked.] I was trying to dig up some cryptography papers cited as references today, when a thought hit me; there seem to be a fair amount of crypto papers available on the Net, but they're pretty scattered. Bell Labs has some online, which is great! The cypherpunks FTP archive has a few, though you can't perform keyword searches against them. In short, it's hard to find papers unless you already know what you want and where it might be. Having had some experience in designing and implementing technical report retrieval services, I naturally think there's room for improvement here. 8-) What I have in mind is something like NASA's NTRS ("NASA Technical Report Server", <http://techreports.larc.nasa.gov/cgi-bin/NTRS>), which I helped design and implement at my last job. The basic idea behind NTRS is that users submit a query to a sort of "search multiplexer" which queries a list of selected databases, merges the separate result sets and gives them back to the user. The results are typically bibliographic and abstract data about papers, which contain links to the papers themselves if they are available online, or ordering info if they're not. From past experience, I think this model could be applied here very successfully. One way to accomplish this would be to establish an archive where people could submit papers to be indexed. Larger institutions (such as Bell Labs) might run their own servers, so they would have control of their own content but could still be searched via the multiplexer. Users of the service could then search all the different archives they were interested in with one simple query. Anyway, this is what I'd like to see. I'm willing to work on such a system if there's enough positive feedback. Does anyone else think they'd like to use or contribute to such a system? -- ========================================================================== David J. Bianco | Web Wonders, Online Oddities, Cool Stuff iTribe, Inc. | Suite 1700, World Trade Center | email: <bianco(a)itribe.net> Norfolk, VA 23510 | URL : http://www.itribe.net/~bianco/

1 0

Re: Mathematics > NSA + GCHQ
by Peter Trei 17 Dec '03

17 Dec '03

Lucky Green <shamrock(a)netcom.com> writes: > At 12:12 PM 8/23/97 -0400, nospam-seesignature(a)ceddec.com wrote: > >DEScrack was only done on a relatively few computers. If a really big > >prize was offered (In this lotto, you just run this screen saver which > >uses less bandwidth than pointcast... The chinese radio lottery via the > >internet), you could get almost every computer into the act. The number of machines working on DESCrack was probably in the 20-30,000 range. > This is a good point. It took $10,000 (plus some hope for fame) to motivate > thousands of computer users to participate in DESCHALL. But $10k is not > all that much money. Few people will go to extraordinary measures to get a > long shot chance at winning this relatively small sum. Note that there were > few DESCHALL participants from China, India, and other countries where > there is a substantial numbers of computers. Actually, most participants worked without any expectation of getting the full $10k. DESChall gave the finder of the magic key $4k, the organizers $2k, with the rest going to charity. In the European effort, aside from a few hundred dollars to cover expenses, the entire amount would have gone to Project Gutenburg (as it did in the 48 bit RC5 crack). Only people running uncoordinated searches, such as Mikkelsen's Bryddes or my Deskr, could look forward to receiving the entire prize. Interestingly, many of the European workers looked on the monetary award with disdain - they participated 'to show Internet user solidarity', and other such reasons. Also, many were using university owned machines, and were legally constrained from accepting money earned from their use. This came as quite a suprise to me. I had picked the $10k figure in my proposal to RSA because it fell in the range of other prizes they had offered, and seemed high enough to motivate people with no emotional or ideological interest in the issues to run free software. >BTW, I am thinking about organizing corporate sponsorships to beef up >the reward for the RC5-64 crack. I am quite certain that at a $1M >prize offering, I would be cracked faster than DES. I think the effort would be better spent on a factoring challenge. [...] > --Lucky Green <shamrock(a)netcom.com> Peter Trei trei(a)Process.com

1 0

Re: Lotus Notes vs. the Web and the Net
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 11:29 PM 9/5/95, Timothy C. May wrote: >On this one I agree...and I've said this here on this list. Local groups, >such as university departments, corporate departments, even entire >corporations, can use the Web/Net in ways similar to what Lotus Notes >provides (using their own LANs, or even the Internet, with suitable >security steps). My favorite financial application for small multinationals (one of my clients is a haircutter with 50 salons and 4 schools worldwide) is nightly remittances to the home office in e$, especially in cash. The consequences for the banking and tax systems are obvious. But it's possible to imagine interesting changes in the foriegn exchange markets as well ... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

TEST
by apache＠bear.apana.org.au 17 Dec '03

17 Dec '03

latency test

1 0

the S-1 Algorithm
by Bruce Schneier 17 Dec '03

17 Dec '03

[I just posted this to sci.crypt. I don't normally read Cypherpunks, so please forward any substantive replies directly to me. Thanks. -Bruce] I was in Europe while S-1 was posted, so I missed most of the discussion. Better late than never.... Over the last year, I have spent considerable effort collecting SKIPJACK information. I have gone through the published literature, the rumors, and a large stack of documents received by EPIC through Freedom of Information Act (FOIA) lawsuits. At Crypto last week I gave a Rump Session talk entitled "Reverse Engineering SKIPJACK from Open Sources." I prepared the slides before I left for Europe. Here is what I said: What the government told us: Single-key block cipher. Can be used in ECB, CBC, CFB, or OFB. 64-bit block size. 80-bit key size. What the review committee told us: 32 rounds. No weak keys (like DES has). No key complementation property (like DES has). What the hardware specifications tell us: The latency of the Mykotronx chip has 64 clock cycles. This means two clock cycles per round. Assorted rumors (excuse me if I don't reveal sources): SKIPJACK does not have rounds in the same sense that DES does: i.e., half of the text block is not encrypted in each round. SKIPJACK has half the total S-box data as DES. SKIPJACK has a 48-bit internal structure analogous to a 32-bit internal structure in DES. The masks for the Clipper/Capstone chip are unclassified and the chips can be produced in an unclassified foundry. Part of the programming in the secure vault includes installing part of the SKIPJACK algorithm. The part of the algorithm installed in the secure vault are the "S-tables", suggesting that perhaps unprogrammed Clipper chips can be programmed to implement other 80-bit key, 32 round ciphers. Trying to puzzle out the meaning of the third rumor, Matt Blaze and I invented something called an Unbalanced Feistel Network. These are Feistel networks where the source and target blocks are of different size. For example, in each round 48 bits might be used as an input into the F function, and produce 16 output bits to be XORed with the remainder of the bits. We called this a 48:16 UFN, and we proposed a design at last year's Algorithms Workshop in Leuven. Our design was broken, but I am still examining the structure. A 48:16 UFN satisfies the first and third rumor above, and I think it as good a guess as any regarding SKIPJACK. A few months ago, I found some additional information in the form of documents released under FOIA. One document was a Mykotronx design review for "Project Capstone" dated 10 December 1991. The design review was unclassified. Among the details about the modular multipliers and the SHA code was the following page about SKIPJACK: ECB Processing Rate 2 clocks per G-Box operation x 1 G-box per shift x 32 shifts per ECB encryption ______________________________ 64 clocks per ECB 64 clocks per ECB / 64 bits out per ECB = 1 clock per bit Yields 40 Mbit encryption using a 40 MHz clock. The only other thing I found was a SECRET memo. The organization name (either from or to) is blacked out. The date is 25 August 1992. The subject is "SKIPJACK Revision." Paragraph 2 is blacked out, but paragraph 1 reads: 1. (U) The enclosed Informal Technical Report revises the F-table in SKIPJACK 3. No other aspect of the algorithm is changed. That's it. Rounds are called "shifts," which seems to indicate that they are not "rounds" in the DES sense. A shift consists of a "G-box" operation, which includes not only what we call the F- F-function but the XOR as well. And there is something called an F-table, which could be a table of constants or perhaps a table of functions. In any case, it is something that can be revised without changing the rest of the algorithm. Now let's look at S-1. The most probable explanation is that it is a hoax. But it is a very good hoax: The hoaxer knew enough about algorithm design to make a cipher that was not obviously lousy, while at the same time not unduly complicated. The hoaxer knew enough to make a design that included three novel ideas not seen anywhere else: S-boxes that are created according to no known criteria, a G-table that chooses a rotation of S-boxes to use in a given round, and a bizarre key schedule. The hoaxer knew enough about how algorithms are used in the military to make a spookish interface. I am particularly interested in the "zeroize" function, the separation of the key creation and key loading functions, and the key masking. Blaze said that the interface was similar to the Fortezza interface, but not the same. The hoaxer knew about Blaze's and my MacGuffin paper and that we thought SKIPJACK was a 48:16 UFN. We made no secret about this, and our paper is on Blaze's web page. The hoaxer knew to use the term F-table. I haven't shown many people what I found in EPIC's documents, so the hoaxer either had to look through them himself or get them by some other means (maybe an independent FOIA request). It's not a perfect hoax, though. The classification markings look odd: NSA algorithms are SECRET, not TOP SECRET, and the codeword restriction sentence is strange. The key schedule is hopelessly flawed (David Wagner posted an attack to sci.crypt). The coding style is amateurish, like it was translated from one language to another. (Maybe this is clever on the hoaxer's part.) And there's even a typo in the code. And maybe the hardware latency is wrong. Clearly the design facilitates parallelization. You can precompute all possible F- table outputs in previous shifts, and then use the G-table result to select between them; I am not sure you can get a shift down to two clock cycles. I don't have the hardware background, and would appreciate comments from others. And why are there not bitwise permutations? If SKIPJACK is designed for hardware, it makes sense to put them in. They're free, after all. Anyway, it's a real good hoax. Blaze estimated that he could have done it, but it would have taken him a month of effort. I agree with his assessment: one man-month. It's a lot of time to spend on a hoax, especially one where the hoaxer doesn't get any credit. So, maybe it's SKIPJACK. It has a 64-bit block size and an 80- bit key size. It's a 48:16 UFN with 32 rounds (or shifts, or whatever). And it has an F-table. This is really interesting, because the structure really is an S-box. Everyone knows it's an S-box, and it makes no sense for a hoaxer to call it something else. But in S-1 it's called an F-table. (I think this is very significant, but others find it less convincing.) And the F-table has been revised at least once. In the code it says that the F-table entries "differ in the S-2 version." The code is dated 1 February 1989 and 31 July 1991, and I have a memo dated 25 August 1992 that says the F-table has been revised in "SKIPJACK 3." Pretty convincing, I think. (Of course this means that we can't confirm anything by testing the hardware, since the F-table entries are different.) Maybe there are no bit permutations because they make analysis harder, and perhaps they don't add all that much. Maybe the algorithm was designed for both hardware and software, or maybe it was designed for specialized cryptographic hardware with several parallel microprocessors and some cryptographic primitives. If it is real, we have a lot to learn about S-box design. The S- boxes are not even balanced. Maybe they are created just so to avoid some bizarre attack we can only dream about, but I kind of doubt it. But the key schedule is just plain wrong. So, here's a theory. Let's assume the code is real. (Not that it's SKIPJACK, but that it's a real algorithm from some military or some corporation.) Clearly the code is not designed to test the cryptographic algorithm, but to simulate some kind of hardware interface: it's called a "software chip simulator." If I were the NSA and I designed an algorithm whose security rested on some tables of constants, I might replace them with phony constants before giving them to another organization to test. I might call the phony version S-1 and the real version S-2. Maybe the code was originally written in FORTRAN, and then translated into C. (NSA doesn't use ADA.) NSA algorithms are classified SECRET, put perhaps algorithms in development are classified TOP SECRET. (We know cryptanalytic techniques can be TOP SECRET, so perhaps commented code falls under that category as well.) And maybe the code originally didn't have an 80-bit key schedule. Maybe it had a longer key schedule. The poster then modified this key schedule to make it look more like SKIPJACK. (This might also explain the bug in the code, which might not be a bug if it still had the original key schedule.) Which leaves us precisely nowhere. The most likely explanation is that it is a hoax, but I am hard-pressed to imagine a hoaxer with the requisite combination of skills, resources, and attitude. I also don't believe that it is SKIPJACK. It might be a preliminary design for SKIPJACK, but if both the key schedule and F-table entries are wrong, we really haven't learned anything. If we suddenly discovered that unbalanced S-boxes are far superior to balanced ones, then all best are off. Bruce ************************************************************************ * Bruce Schneier 2,000,000,000,000,000,000,000,000,002,000, * Counterpane Systems 000,000,000,000,000,000,002,000,000,002,293 * schneier(a)counterpane.com The last prime number...alphabetically! * (708) 524-9461 Two vigintillion, two undecillion, two * 730 Fair Oaks Ave. trillion, two thousand, two hundred and * Oak Park, IL 60302 ninety three. ************************************************************************

1 0