- cypherpunks-legacy@lists.ogf.org

Re: CryptoStacker, long term vision
by RYAN Alan Porter 06 Jun '93

06 Jun '93

On Thu, 3 Jun 1993, A1 ray arachelian wrote: > > 2) does anybody know how the hell Stacker or DoubleStor or > > whatever executes the actual interception of the read/write > > routines and stacks them? I don't get it at all. I am > > more than willing to learn to get this thing working though. > > > > Anyhow to make the story short, if I wrote an image mounter device driver which > would be able to grab DIM files and pretend that they were on the A: or B: drive > then we could also install the programs without breaking out the recylced disk > box. :-) Couldn't you just do that with the assign command in DOS? or is that a new command? > I never got around to it because of other projects, but, what you need to do is > to write a device driver that becomes accessible via the IOCTL calls. That's > the way logical drivers (such as Stacker) install themselves. Yeah, I am assuming that is the way I will have to organize the system. I want it to be totally transparant, that seems like a good way. > Also, the program you're writing (I believe) has been already written and is > part of Norton Utilities, but uses either DES or some other weak form of > encryption. You might want to buy Norton Utilities and play with that program > and see what makes it tick. Basically a program like MSD (Microsoft Diags) > can tell you exactly what interrupts it patches itself into. I have heard this from someone else. It kind of takes the wind out of my enthusiasm, but not too much... I still think that there is a need for a good, strong system out there with some seriously dedicated password key protection and such. Also, it needs to be freeware (or shareware, depending on how long it takes to write) so that security won't just be in the hands of the people who can afford to buy it from companies. I also think that it would be a lot more valuable if it were distributed with code so that any user who wanted could inspect it for trapdoors. > On to the sector remapping. The way stacker and doubledisk and the other > suite of driver level compressors work is basically, they allocate a huge > file on the hard drive, and then do a remapping at the sector level. That > is you've got the data itself and an index table into the data for every > sector. When a sector is written to the drive, the driver compresses the > sector, so say, it was 512 bytes, it now becomes 128 bytes (if we're lucky) > so what Stacker does is, looks in its index table, finds 128 bytes free in > the huge file it allocated, writes the data there, and then sticks the > position of the data, and it's size (after compression) in the index table. > (Of course it also marks that 128 bytes as taken.) Umm, perhaps this is overly optimistic, but I was hoping that I would be able to use an algorithm that did 1 byte in / 1 byte out encryption so that I wouldn't have to deal with sector remapping. This would greatly speed up the process, make it more crashproof, and besides, it would be a hell of a lot easier... I was thinking that I would even basically leave the FAT and such intact, or at least only slightly modified. > I believe it also does some other funky stuff like changes the allocation > table or the bytes free to twice the space it's got left, so that DOS > doesn't choke when it thought it had 10,000 sectors free and the hard > drive ran out of space when it tried to write #4,999. :-) > > So you might want to do this with RSA. But better yet, why don't you > find a quick compressor algorithm (say some sort of LZ type method) > and stick that in as well. This way you are writing a public domain > version of stacker >WITH< encryption. (Since you'd have to remap > the sectors anyhow, you might as well compress them too...) I have been pointed in the direction of the IDEA engine in PGP, which will take 1 byte in / 1 byte out. This would be ideal (snicker) for the reasons that I mentioned before. As for compressing also, that is a really good idea, but I think that I will leave that one up to posterity, or at least to the next guy that tries to midofy the thing, I am concerned enough with getting it to work at all, and compression would add the problem of having to do sector remapping, which I would like to avoid at first. > The above is just a theory and hasn't been tested. I believe that > this is what Stacker does, but I'm not exactly sure. :-) But it > does sound logically right. Sounds good to me, and it is consistent with the advice of others (thanks a lot guys, I really appreciate the help) and the books that I have found since this started two days ago... > So if I'm wrong, let me know as you've got my curiosity up in this > matter. I'll keep everyone updated no problem. How else am I going to get suggestions and help? -Ryan the Bit Wallah

4 3

Re: Dig. Cash Question.
by J. Michael Diehl 06 Jun '93

06 Jun '93

According to smb(a)research.att.com: > > If I understand this correctly, if p is not a prime, then n may not be > unique. > > Well, n isn't unique even if p is prime. Consider a=10,p=11. > 10^2=10^4=10^6=10^8=10^10=1 mod 11. You only get a maximum-length > cycle if ``a'' is a primitive root, hence the restriction I stated > in the part I deleted... That is, if a is a generator of G, or as close to one as possible. My thinking was obviously clowded... Not that I have a beer in me, I remember that for any element, a of group G, a will have order n, such that n|ord(G). This implies that there are n different (positive) powers of a which yield a particular number, b in our case. Each of which would qualify as a log. I think I understand. > It doesn't matter that n isn't unique, though you do want a good > distribution. Primitive roots have a maximal distribution, which is Then which root are we to use in discussion? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl(a)triton.unm.edu | But, I was mistaken. |available| | mike.diehl(a)fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+

1 0

NitV is DOWN!
by Stanton McCandlish 06 Jun '93

06 Jun '93

> DON'T call for PGP toys from my system any time this week, and likely next. > The system is DOWN, due to a motherboard video-related problem (among others). > Serves me right for buying mailorder, with a 1yr warranty (it's been 1 > year and 2 months. Of course.) NitV should be up and running and all > the crypto files available again within a couple weeks. Blagh. > Of course, what REALLY must've happened is the SS sneaked into my house in > the middle of the night and ran a magnet over my BIOS... >;) > > -- > When marriage is outlawed only outlaws will be inlaws! > Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS > Internet anton(a)hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 > Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA > Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) > Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) > -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton(a)hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:)

1 0

Software infrastructure
by mmidboe＠cs.uah.edu 06 Jun '93

06 Jun '93

CY>Buzzword alert. What is "TPU"? And who makes "Async Pro", and what CY>exactly does that do? Well, in the PC world, a TPU is just a Turbo Pascal Unit. It's become kind of a standard for making easy add-ons to programs since a lot of programmers use Turbo Pascal. Async Pro is written by Turbo Power software. Anyways, does anyone have any basic ideas on what functions would be really important for some kind of programmers toolkit? To narrow things down you might want to make a PGP toolkit that manipulates PGP keys and makes using PGP easier from other programs. So, does anyone have feedback on some good general PGP encrypted file manipulation functions? Once you make them easy to integrate into other programs I'm sure more and more people will pick it up. Reading through the vast amounts of C code on PGP is quite a daunting task.

1 0

Re: CryptoStacker
by Doug Porter 06 Jun '93

06 Jun '93

The mother lode of source code for MSDOS redirectors, drivers, and related code appears to be the BCPPDOS forum on CompuServe. Some of the authors state that their software has been placed in the public domain, although for some reason they usually left in their copyright notices. It's a very good idea to have the author's explicit permission on file before redistributing any of this software. In the C programming library: CPHANT.ZIP C source for MSDOS network redirector DRIVER.ZIP C/Asm source for generic driver skeleton RDCF2.ZIP C source for complete MSDOS file system In the General library: CRAMDI.ZIP C source to RAM disk driver FDCBIOS.ZIP Asm source to floppy disk driver Doug

1 0

Re: Software infrastructure
by Pat Farrell 06 Jun '93

06 Jun '93

I beg to differ. Stanton McCandlish <anton(a)hydra.unm.edu> writes: >As for "is kermit good enough?" No. Almost NO ONE in the DOS world uses >it any more, ..flames elided... I agree that the PC-centric BBS world has decided that Kermit is obsolete. Kermit is continually improving and is very nearly as fast as ZMODEM. It is available for nearly all platforms, is free, and source is availilbe. It includes NASI support directly. It has a very nice (powerful) scripting language. It also works over TCP/IP networks for folks with the luck to be Ethernet'd into the Internet (like most of the faculty and staff here at GMU). It also has very strong backward compatibility. I expect that Kermit is good enuff if you are interested in commandline scripts for plain old DOS. And the scripting language is also supported by the C version that run on nearly all Unixs and most other boxes. This would allow a single script to support a lot of users. I'm not interestedin DOS and command lines, but if some other cypherpunk wants to try, I'm sure not going to complain. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

3 2

Re: Dig. Cash Question.
by smb＠research.att.com 05 Jun '93

05 Jun '93

> Anyway -- suppose that in some group, you know that a^n=b, where a > and b are members of the group, and n is an integer. a^n indicates > the group operation iterated n times. The discrete log problem is > recovering n, given ``a'' and a^n=b. > > In some groups, this is a very hard problem. The group most commonl y > used in cryptography is the field GF(p), i.e., the field of integers > modulo p, where p is some large number, preferably a prime, and ``a' ' If I understand this correctly, if p is not a prime, then n may not be unique. Well, n isn't unique even if p is prime. Consider a=10,p=11. 10^2=10^4=10^6=10^8=10^10=1 mod 11. You only get a maximum-length cycle if ``a'' is a primitive root, hence the restriction I stated in the part I deleted... It doesn't matter that n isn't unique, though you do want a good distribution. Primitive roots have a maximal distribution, which is why they're good. But a reduction by, say, a factor of 2 doesn't matter in practice. (For p=11, try a=3.) The implementation of secure RPC in SunOS uses Diffie-Hellman (which relies on the difficulty of the discrete log problem) with base that's not a primitive root. To be sure, their key exchange was cryptanalyzed, but that's because they picked a 192-bit modulus, not because of the exponentiation base. If I recall correctly, if p=kq+1, for q a prime and k a small integer, there are (q-1)/k primitive roots in GF(p). That suggests generating p=2q+1, p and q prime, which gives a very good density. And checking if a number is a primitive root is easy (again, to my recollection; I'm not a number theorist) if you know the factorization of p-1, which of course we do in this case.

1 0

Re: Dig. Cash Question.
by J. Michael Diehl 05 Jun '93

05 Jun '93

According to smb(a)research.att.com: > > I'm reading the paper that was announced on this list about > Digital Cash last week. It was writen by Stefan Brands. I > think I have a strong Math background, but I don't know what is > meant by a "descrete log" in a group G. I understand what a > group is. I just don't know what properties an element, a, > would have if it were the log sub p of e. Can someone help > me. Otherwise, this is a very interesting article. Thanx in > advance. > > You might want to fix your mailer; according to the strict letter of > RFC822, human-readable names shouldn't contain periods unless quoted.... I sent word to those "in charge." ;^) Maybe after I graduate, they will fix it.... > Anyway -- suppose that in some group, you know that a^n=b, where a > and b are members of the group, and n is an integer. a^n indicates > the group operation iterated n times. The discrete log problem is > recovering n, given ``a'' and a^n=b. > > In some groups, this is a very hard problem. The group most commonly > used in cryptography is the field GF(p), i.e., the field of integers > modulo p, where p is some large number, preferably a prime, and ``a'' If I understand this correctly, if p is not a prime, then n may not be unique. > is a ``primitive root'' of the field. The problem is thus to find > n, given ``a'' and a^n modulo p. Other instances of discrete log > are useful as well; NeXT, for example, uses the same basic equation > in a field over some family of elliptic curves. Their much-ballyhooed > invention was to find a set of such curves for which the exponentiation > operation can be performed very efficiently. > Thanx for the (very!) clear explaination. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl(a)triton.unm.edu | But, I was mistaken. |available| | mike.diehl(a)fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+

1 0

Re: Dig. Cash Question.
by smb＠research.att.com 05 Jun '93

05 Jun '93

I'm reading the paper that was announced on this list about Digital Cash last week. It was writen by Stefan Brands. I think I have a strong Math background, but I don't know what is meant by a "descrete log" in a group G. I understand what a group is. I just don't know what properties an element, a, would have if it were the log sub p of e. Can someone help me. Otherwise, this is a very interesting article. Thanx in advance. You might want to fix your mailer; according to the strict letter of RFC822, human-readable names shouldn't contain periods unless quoted.... Anyway -- suppose that in some group, you know that a^n=b, where a and b are members of the group, and n is an integer. a^n indicates the group operation iterated n times. The discrete log problem is recovering n, given ``a'' and a^n=b. In some groups, this is a very hard problem. The group most commonly used in cryptography is the field GF(p), i.e., the field of integers modulo p, where p is some large number, preferably a prime, and ``a'' is a ``primitive root'' of the field. The problem is thus to find n, given ``a'' and a^n modulo p. Other instances of discrete log are useful as well; NeXT, for example, uses the same basic equation in a field over some family of elliptic curves. Their much-ballyhooed invention was to find a set of such curves for which the exponentiation operation can be performed very efficiently. Oddly enough, solving discrete log in GF(p) seems to be vaguely akin to factoring. p doesn't have to be a prime, but you can use smaller numbers if it is. Early attempts used 2^n, since that makes the modulus operation trivial, but if you do that, you need such a large n that it doesn't pay. For p a prime, 512 bits is probably secure now, though possibly not against NSA. 1024 bits is likely to be secure forever, barring major theoretical breakthroughs. --Steve Bellovin

1 0

Re: DISKREET--Norton
by hkhenson＠cup.portal.com 05 Jun '93

05 Jun '93

Norton might let interested people exhamine the code, far as I know nobody has asked, but one mode is DES. It seems to me if Norton were ok, you could encrypt with Norton and decrypt with any other hardware/software implimention of DES. Unless Norton does something really dumb like stashing the key on disk somewhere, it would seem to me that this would varify Norton doing DES per the book. Have I missed something? Keith

2 1