December 2003 - cypherpunks-legacy

Review of APPLIED CRYPTOGRAPHY in Cryptologia
by schneier＠chinet.com 17 Dec '03

17 Dec '03

The following review of APPLIED CRYPTOGRAPHY appeared in the January 1994 issue of Cryptologia (v. 18, n. 1). Written by Louis Kruh. The past twenty years have seen an explosive growth in public research into cryptology, accompanied by an unprecedented public awareness of matters cryptologic. Programmers and engineers trying to benefit from the fruits of this research, to solve real-world problems, have often been stymied by not knowing where to start looking, let alone when to stop. This book is for them. Written as a "comprehensive reference work for modern cryptology" the book succeeds both as an encyclopedia survey of the past twenty hears of public research and as a hansom "how-to" cookbook of the state-of-the-art. It could well have been subtitled "The Joy of Encrypting." The author's style is colloquial and informal, but never imprecise. Theory takes a back seat to clarity and directness, without deliberate misrepresentation; unabashed informed opinion wins out over academic hesitations. Since the work is a practical snapshot of the field, circa mid-to- late 1993, several of the book's recommendations may prove timely: new results seem to be reported monthly. While his political axe is never concealed the book is written as a whetstone for others rather than a soapbox rant, and the focus is manifestly practical solutions and the tools with which to achieve them. After a forward from Whitfield Diffie the author explains foundations; examined protocols; discusses techniques; presents algorithms; explores the real world (including legal and political aspects); and finishes up by printing read-to-run C source code programs of several of the algorithms, including ENIGMA, DES and IDEA. Reflecting the confused nature of the real world, a set of IBM PC disks containing the sources published in the book is available from the author--but only to residents of the USA and Canada. Drawing on 908 references and the collected experience of contributors throughout the Internet and around the world, this book will be a useful addition to the library of any active or wouldbe security practitioner. It's the first review of the book that has appeared in print, and I am very pleased with it. The book has turned out to fill two very different niches. One, it is the book that people are being handed to read when they want to learn about the field. Two, it is the reference work that people are turning to first if they want to find out about some aspect of cryptography. The third important niche, which the book does not fill, is that of a textbook. This field sorely needs a textbook. Anyone interested? Bruce

1 0

Re: New remailer up.
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

>Before I start throwing out ideas that I'm sure aren't new to readers here, >I have a simple question that perhaps I should post to comp.unix.questions >or comp.lang.perl, but.... Can I, and how would I, get a perl script to >kick in and send out mail every few minutes when I am NOT logged in. Is this >possible on Netcom? Rather than try to run in some asynchronous mode as you suggest, why not do the following when each message arrives: place message in your queue, designating random hold time foreach message in the queue that's been held long enough send random number (1<=n<=3) dummy messages send the queued message send random number (1<=n<=5) dummy messages The whole thing remains data-driven while you're not logged in and can be manually flushed if you are logged in. So long as there is a steady stream of traffic, messages won't get stalled for long times. You could even send some 'activation' messages at controlled intervals from some comfortable site (where you can use cron), routed via another remailer. Just some ideas off the top of my head.

1 0

Practical Pencil & Paper Encryption (computerizable)
by richardr＠netcom.com 17 Dec '03

17 Dec '03

Bruce Schneier <schneier(a)chinet.chinet.com> in Message-ID: <CEtKr4.7B7(a)chinet.chinet.com> Date: Wed, 13 Oct 1993 05:04:13 GMT Subject: Pencil and paper encryption algorithm proposed a pencil-and-paper encryption algorithm that could be used without computers, but was still secure against computer-aided attacks. I answered with what I felt were several practical usage problems with his proposed methodology that made it infeasible to reliably encrypt and decrypt messages in a finite time. During a much needed vacation from the practical realities of work and life, I have attempted to come up with a simplified message encryption algorithm that meets Bruce's criteria and is practical in use. I took as design constraints that an inexpensive (< $30) pocket calculator was acceptable for performing any necessary calculations, but that something as big and complex as an HP-48 or an Apple Newton was unacceptable. I also changed the requirement from "secure against computer-aided attacks" to "highly resistant against computer aided attacks". My first attempt used a simple, multiple memory, non-programmable Radio Shack checkbook pocket calculator. While the methodology met the "resistance" criterion, it failed the practical test of error- free calculation in a finite time. It turned out to be possible to get reliable encryption and decryption by applying the result cross-checking techniques used in hand pencil-and-paper calculation, however the time required for error-free encryption was exorbitant. By relaxing the design constraints to allow limited programmability in the pocket calculator, I was able to adequately address the problem of speed of error-free encryption calculations. The constraint that I adopted was that the calculator's program steps must be simple and compact enough for the user to be able to memorize and to be able to re-enter the program into the calculator each time that it was used to encrypt or decrypt a message. I believe that this satisfies the reasonable requirement that there be no incriminating evidence left lying around in the calculator between encryption sessions. The following encryption procedure was tested using an $18 Radio Shack Model EC-4021 programmable scientific calculator. The algorithms were modified as necessary to conform to the practical limitations of the calculator keypad and limited programming capabilities. With only moderate training time (a couple of hours) I was able to reliably encrypt and decrypt messages at a rate of 8-10 characters per minute. The primary speed limitation was the actual tran- scription on the results by pencil onto paper. I would appreciate any and all comments, criticisms, error corrections and suggestions for improvements. Richard Robertson richardr(a)netcom.com ------------------------------------------------------------ A "Pencil and Paper" Encryption Algorithm for Pocket Calculators Copyright 1993 Richard L. Robertson Contents A: Encryption Confusion Generators B: Substitution Cipher Technique C: Transposition Cipher Technique D: Encryption Key Management E: Cryptographic Hardness F: Message Encryption Example G: Sample Message Key Generation A: Encryption Confusion Generators The core confusion generator chosen is a variation on the non- linear equation Logistic Difference Equation (LDE). This is selected for its adequate PRNG properties and its simplicity of calculation. The standard basic LDE can be written as X[n+1] = R * X[n] * (1 - X[n]) where R = 4, and 0 < X[n] < 1 While the output of the LDE has reasonable unpredictability, this basic formulation has limited cryptographic usefulness, partly because of limited sequence length and partly because the seed can be derived with sufficient information about successive values, even if "jitterized" (as described by Terry Ritter). By revising the constraints slightly to 3.99 < R < 4.0 the resulting output is "sub-chaotic" but still has very good PRNG properties. Another advantage of using R < 4.0 is that rounding errors in calculations do not cause any numerical values that result in the PRNG sequence degenerating from calculation errors. Extensive numerical trials on a 486 PC with 15-digit (decimal) floating point calculations have not uncovered any values of R or X[n] that result in short or degenerate PRNG sequences. The average length of a pseudo-random sequence from a (modified) LDE is a function of the number of digits of precision used in the calculations. For 9-digit fractional numbers, the expected length of a pseudo-random sequence is ~ 3 * 10^4 and there are ~ 3 * 10^4 independent sequences. The sequence length is adequate for pencil and paper encryption since messages would rarely exceed 200 characters. To develop a reasonably secure cryptographic methodology using the modified LDE as the confusion generator, proceed as follows: 1 - Select two non-linear (LDE) confusion generators G1 = R * X * (1 - X), and G2 = R'* Y* (1 - Y) where R' = 0.999 * R (used because of limitations in the number of memory registers in the pocket calculator) 2 - The cryptographic key (or seed) consists of the values R, X[0] and Y[0], where 0 < X[0] < 1 is a 9-digit key 0 < Y[0] < 1 is a 9-digit key 3.99 < R < 4.0 is a 7-digit key The total key length is 25 digits, giving a key space size of 10^25. The keys are short enough to be easily memorized. (If you are not convinced of this assertion, consider how many phone numbers, PIN numbers, bank account numbers, etc that the average person routinely commits to memory) 3 - Select a non-linear combiner for the output of two confusion generators. This is the first level of serious cryptographic strength. We will chose the function K = G1 <*> G2 where <*> is the floating point multiplication operator with rounding (see Knuth, Seminumerical Algorithms for details). At little inspection will show that it is not possible to recover the values G1 and G2 from a given K because K is not uniquely factorable. The rounding performed during the multiplication discards information necessary for factoring. In fact, for any 0 < K < 1, *all* values of G1 > K are valid factors of K. Rephrased, for any K {0 < K < 1} and for any p {1 > p > K, there exists at least one q {1 > q > K} such that K = p <*> q. Note: Because of rounding, numbers of the form K = (1/b)^n (where b is the base) are the only exceptions to this statement. For K = (1/b)^n, q = 1-(1/b)^n is not a factor of K. Recovering a sequence of G1 and G2 values from a sequence of K values, and from that recovering the cryptographic keys R, X[0] and Y[0], requires solving a series of simultaneous non- linear high-order polynomial equations. I am not aware of any practical way to do this in the literature. Brute force recovery of the sequence of n-digit G1 and G2 values requires checking a minimum of 10^(n*3) n-tuples {G1,G2,G'1,G'2,G''1,G''2} to determine which are possible solutions for the generator functions G1 and G2. 4 - Choose a domain transformation from quasi-continuous floating point to the finite to select digits from K to use for data encryption. This is the second level of serious cryptographic strength. Choose any algorithm for selecting a cipher value K' of either 1 or 2 digits from "around the middle" of the value K to use for performing the encryption. Because the confusion generators G1 and G2 are independent and have reasonably uniform digit distributions, the nonlinear combination K = G1 <*> G2 also has a reasonably uniform digit distribution. For any particular 1-digit value K', there are 10^8 possible values of K that could have generated it. For any particular 2-digit value K', there are 10^7 possible corresponding values for K. 5a - Use the sequence {K'} as the key for a Vigenere cipher 5b - Use the sequence {K'} to control a pseudo-random transposition cipher. 5c - Combine (5a) and (5b). Use (5a) to "bit-level" the message text, then use (5b) to superencipher the output of (5a). This would require two complete encryption steps and is probably too labor and time intensive to be worth while for pencil and paper encryption. In summary, the steps for calculating the encryption sequence K' are as follows: X [n+1] = R * X[n] * (1 - X[n]) Y [n+1] = .999 * R * Y[n] * (1 - Y[n]) K [n+1] = X[n+1] * Y[n+1] K'[n+1] = 1 or 2 low-order digits of int (10^5 * K[n+1]) B: Substitution Cipher Technique In this system, the key consists of a series {K'} of 2-digit values that is as long as the message. These are added to the plaintext message characters modulo 100, considered the alphabet as numbered from Sp=00, A=01 to Z=26, etc. This is your basic Vigenere cipher with the cipher key as long as the message. Decryption performs the same series of steps on the ciphertext message characters except that subtraction modulo 100 is used. Given that the K' form an unpredictable sequence, this is equivalent to a one-time pad Vernam cipher where the one-time pad does not have to be transmitted to the receiver. The message recipient can regenerate the series {K'} from knowledge of the cipher key <R,X[0],Y[0]>. The only problems that need to be addressed are the resistance of the sequence {K'} to computer-assisted attack and how to manage the necessary set of secret keys {<R,X[0],Y[0]>}, since one key-tuple is consumed by each message. In summary, the steps for encrypting a message M are as follows: compute K[n] as described above C[n] = 2 low-order digits of int (10^5 * K[n]) + M[n] where M[n] is the nth plaintext character, and C[n] is the nth ciphertext character and the steps for decrypting a ciphertext C are as follows: compute K[n] as described above M[n] = 2 low-order digits of int (100001 - (10^5 * K[n]) + C[n]) where M[n] is the nth plaintext character, and C[n] is the nth ciphertext character C: Transposition Cipher Technique In this system, the key consists of a series {K'} of 1-digit values that is longer than the message. 1 - Write down the plaintext message into blocks of length 10 (because the calculator operates in decimal mode). Repeat the message at least once because the algorithm will encipher more characters than are in the message. The exact number of excess characters enciphered is random but bounded. If the message text is: "Now is the time for all good men to come to the aid of their party." then this is written in blocks of 10 as: 1234567890 |Now is the| | time for | |all good m| |en to come| | to the ai| |d of their| | party.Now| | is the ti| |me for all| Repeat the message text as required. 2 - Calculate the sequence of 1-digit numbers {K'} 3 - For each value K', select and output the next unused character in column K'. Mark the selected character as used. 4 - Repeat this process until all characters in the base message have been transmitted. Decryption proceeds as follows: 1 - Calculate the sequence of 1-digit numbers {K'} 2 - Get the next ciphertext character and place it in the next available column K' 3 - Repeat this process for all ciphertext characters. 4 - The row in which that last character is placed is the last row of the message. Discard any rows following that row because they are just random padding added by the encryption algorithm. Transposition ciphers are substantially harder to attack than substitution ciphers and normally require a lot of hand work. Normally they are attacked by anagramming when there is some knowledge of the expected message contents. I would assert, based on a moderate literature search, that this pseudo-random transposition has no known effective methods for attack because there are no fixed column boundaries and character positions are pseudo-random. If the cryptographic key <R,X[0],Y[0]> is changed with each message there should be no way short of brute force anagramming or a brute force key space search to break this cipher because the cryptographic cipher values are never exposed for cryptanalysis. D: Key Management To make the subsitution cipher encryption useful the key must be changed with each message because it is a one-time pad method. The encryption method has already addressed and eliminated the need for the sender to transmit a copy of the OTP to the receiver by having the receiver independently recreated the OTP used to encrypt the message. While having a separate, unique encryption key for each message is less important for the transposition cipher, it does strengthen the cipher against any attack if the key can be easily changed for each message. In order to not have to transmit each key used to generate the OTP for each message to the receiver, a technique must be developed that provides a similar facility. If this can be accomplished, then the only secret that the sender and receiver must share is a single, small master key. Sharing a small amount of secret information is a fairly easy problem to solve in practice. Inspection of the method for generating the encryption confus*ion sequence shows a way to accomplish the desired key management. Consider the sequence of values {K[i]}. It is obvious from the earlier discussion that there are only two ways to be able to predict subsequent values K[n+1] from the series of values {K[1] ... K[n]}: - obtain the generating seeds for G1 and G2 by brute force examining sets of possible values {G1[i],G2[i]} obtained by factoring {K[i]}. This would require examining at least ~ 10^24 (2^80) possible sets {G1[i],G2[i]} and as such is not feasible with current computing technology. - obtain the generating seeds for G1 and G2 by solving a set of simultaneous high-order nonlinear system of equations. This is an extremely hard problem that is not (as far as my literature search has taken me) amenable to solution at this time. In order to make the problem slightly harder for the crypt- analyst, the key generation algorithm chosen will not use the sequence {K[i]} directly so as not to expose the actual values K[n], but will use K[n] as a starting point for another nonlinear combiner. Again, the algorithms have been adjusted to compensate for the limitations of the pocket calculator. To generate a cryptographically (reasonably) secure sequence of encryption keys using the modified LDE as the confusion generator, proceed as follows: 1 - Select two non-linear (LDE) confusion generators G1 = R * X * (1 - X), and G2 = R'* Y* (1 - Y) where R' = 0.999 * R (used because of limitations in the number of memory registers in the pocket calculator) 2 - The master cryptographic key (or seed) consists of the values R, X[0] and Y[0], where 0 < X[0] < 1 is a 9-digit key 0 < Y[0] < 1 is a 9-digit key 3.99 < R < 4.0 is a 7-digit key The total key length is 25 digits, giving a key space size of 10^25. The keys are short enough to be easily memorized. (If you are not convinced of this assertion, consider how many phone numbers, PIN numbers, bank account numbers, etc that the average person routinely commits to memory) 3 - Select a non-linear combiner for the output of two confusion generators. This is the first level of serious cryptographic strength. We will chose the function K = G1 <*> G2 where <*> is the floating point multiplication operator with rounding (see Knuth, Seminumerical Algorithms for details). 4 - To generate the Nth message key iterate the basic sequence generator N times. Then use the values K[N] ... to alter the generator parameters R, X and Y as follows: R <- 3.99 + (K[n]/100) X <- K'[n+1] where K'[i] <> K[i] because the generating parameters are different Y <- K'[n+2] R <- 3,99 + (K'(n+3)/100) 5 - The final resulting values <R,X,Y> become the cryptographic key for the Nth message being encrypted or decrypted and are used as described above for message encryption and decryption. Only the value N must be transmitted with the message, not the values of the message key <R,X,Y>, because the receiver can recreate the message key from N and the master key shared by the sender and receiver. The only additional requirement for security is that no key be reused. This is easy to implement by having the sender number the messages as they are encrypted. The receiver verifies that a message is valid by rejected any message where the message number N is less than the message number of the last message received. This will prevent replay attacks in the event that an opponent obtains a message key. In summary, the steps for calculating the encryption key <R,X,Y> for the Nth message are as follows: Repeat N times: X [i+1] = R * X[i] * (1 - X[i]) Y [i+1] = .999 * R * Y[i] * (1 - Y[i]) K [i+1] = X[i+1] * Y[i+1] {end repeat} R <- 3.99 + (K[N]/100) calculate K[N+1] X <- K'[N+1] calculate K'[N+2] Y <- K'[N+2] calculate K'[N+3] R <- 3.99 + (K'[N+3]/100) The message encryption key conists of the values <R,X,Y> at the conclusion of this calculation. E: Cryptographic Hardness Key space searches: The key space size is ~ 10^25 (~ 2^80), which is too large for brute force search with currently available computing resources. Because the key values are random 9-digit numbers there is no possible dictionary attack. Known Plaintext: A known plaintext attack will immediately give the cipher sequence {K'}. However, an absolute minimum of 3 sequential values of the sequence {K} are needed to derive the encryption key <R,X[0],Y[0]>. For the 2-digit sequence {K'} used in the substitution cipher, this requires checking the validity of the encryption keys derived from the (at least) 10^21 (2^70) possible triples {K1,K2,K3}. This is well beyond current computational capabilities. Since each key <R,X[0],Y[0]> is used only once, possession of the key for one message does not give the opponent any direct value in a known plaintext attack. To determine the key for subsequent messages, at least 3 successive keys must be accumulated in order for the cryptanalyst to attack the key management. Chosen Plaintext: No advantage over known plaintext. Key Management: Same problems (or worse) for the cryptanalyst as aKnown Plaintext attack. Differential Cryptanalysis: I don't see that this is applicable because the key changes with each message. F: Message Encryption Example: Sample message to be enciphered "Now is the time for all good men to come to the aid of their party." Message buffer is padded with repeats of the message, but it would be better to pad with randomly chosen text. The encryption calculations were performed on a Radio Shack Model EC-4021 programmable scientific calculator. Image of Message Text Buffer ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | N | O | W | | I | S | | T | H | E | +---+---+---+---+---+---+---+---+---+---+ 1 | | T | I | M | E | | F | O | R | | +---+---+---+---+---+---+---+---+---+---+ 2 | A | L | L | | G | O | O | D | | M | +---+---+---+---+---+---+---+---+---+---+ 3 | E | N | | T | O | | C | O | M | E | +---+---+---+---+---+---+---+---+---+---+ 4 | | T | O | | T | H | E | | A | I | +---+---+---+---+---+---+---+---+---+---+ 5 | D | | O | F | | T | H | E | I | R | +---+---+---+---+---+---+---+---+---+---+ | | P | A | R | T | Y | . | N | O | W | <- Message ends at ========================================= this line 7 | | I | S | | T | H | E | | T | I | +---+---+---+---+---+---+---+---+---+---+ Buffer is loaded with 8 | M | E | | F | O | R | | A | L | L | repeated copies of the +---+---+---+---+---+---+---+---+---+---+ message text 9 | | G | O | O | D | | M | E | N | | +---+---+---+---+---+---+---+---+---+---+ 10 | T | O | | C | O | M | E | | T | O | +---+---+---+---+---+---+---+---+---+---+ 11 | | T | H | E | | A | I | D | | O | +---+---+---+---+---+---+---+---+---+---+ 12 | F | | T | H | E | I | R | | P | A | +---+---+---+---+---+---+---+---+---+---+ 13 | R | T | Y | . | N | O | W | | I | S | +---+---+---+---+---+---+---+---+---+---+ 14 | | T | H | E | | T | I | M | E | | +---+---+---+---+---+---+---+---+---+---+ 15 | F | O | R | | A | L | L | | G | O | +---+---+---+---+---+---+---+---+---+---+ 16 | O | D | | M | E | N | | T | O | | +---+---+---+---+---+---+---+---+---+---+ 17 | C | O | M | E | | T | O | | T | H | +---+---+---+---+---+---+---+---+---+---+ 18 | E | | A | I | D | | O | F | | T | +---+---+---+---+---+---+---+---+---+---+ 19 | H | E | I | R | | P | A | R | T | Y | +---+---+---+---+---+---+---+---+---+---+ ============================================================ Substitution Encipherment of Sample Text The Message Encryption Key X[0] = 0.123456789 register K1 R = 3.995678901 register K2 Y[0] = 0.234567891 register M Calculator set to No Rounding (2nd Fn - Tab - .) ie, show all decimal digits Substitution Cipher Character Translation Table Sp 00 J 10 T 20 A 01 K 11 U 21 B 02 L 12 V 22 C 03 M 13 W 23 D 04 N 14 X 24 E 05 O 15 Y 25 F 06 P 16 Z 26 G 07 Q 17 . 27 H 08 R 18 I 09 S 19 Plain Text converted to decimal representation ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | 14| 15| 23| 00| 09| 19| 00| 20| 08| 05| +---+---+---+---+---+---+---+---+---+---+ 1 | 00| 20| 09| 13| 05| 00| 06| 15| 18| 00| +---+---+---+---+---+---+---+---+---+---+ 2 | 01| 12| 12| 00| 07| 15| 15| 04| 00| 13| +---+---+---+---+---+---+---+---+---+---+ 3 | 05| 14| 00| 20| 15| 00| 03| 15| 13| 05| +---+---+---+---+---+---+---+---+---+---+ 4 | 00| 20| 15| 00| 20| 08| 05| 00| 01| 09| +---+---+---+---+---+---+---+---+---+---+ 5 | 04| 00| 15| 06| 00| 20| 08| 05| 09| 18| +---+---+---+---+---+---+---+---+---+---+ 6 | 00| 16| 01| 18| 20| 25| 27| * | <- * := EOM +---+---+---+---+---+---+---+---+ Cipher Text in decimal representation ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | 03| 96| 69| 02| 83| 49| 28| 31| 22| 13| +---+---+---+---+---+---+---+---+---+---+ 1 | 21| 63| 92| 03| 90| 45| 72| 08| 26| 34| +---+---+---+---+---+---+---+---+---+---+ 2 | 15| 65| 62| 01| 34| 84| 50| 12| 62| 83| +---+---+---+---+---+---+---+---+---+---+ 3 | 07| 41| 71| 33| 72| 64| 38| 96| 73| 25| +---+---+---+---+---+---+---+---+---+---+ 4 | 16| 96| 06| 57| 93| 39| 8 | 47| 60| 96| +---+---+---+---+---+---+---+---+---+---+ 5 | 29| 49| 88| 37| 39| 37| 61| 24| 68| 38| +---+---+---+---+---+---+---+---+---+---+ 6 | 60| 90| 25| 96| 67| 84| 65| * | <- * := EOM +---+---+---+---+---+---+---+---+ ============================================================ Transposition Encrypted Message Text The Message Encryption Key X[0] = 0.123456789 register K R = 3.995678901 register K2 Y[0] = 0.234567891 register M Set calculator rounding to 0 decimal digits (2nd Fn - Tab - 0) ie, show only integer portion of answer Encrypted message in blocks of 10 letters |HO T NR IT||AM ES OWOT| | FE D EMLD||IF LOG M | |HC ORN AE||OIOTOE MEI| |TFTN TA LO||TE APH. DR| |OSC ITW IE||Y|* <-* := EOM ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | H | O | | T | | N | R | | I | T | +---+---+---+---+---+---+---+---+---+---+ 1 | A | M | | E | S | | O | W | O | T | +---+---+---+---+---+---+---+---+---+---+ 2 | | F | E | | D | | E | M | L | D | +---+---+---+---+---+---+---+---+---+---+ 3 | I | F | | L | O | G | | | M | | +---+---+---+---+---+---+---+---+---+---+ 4 | H | C | | O | R | N | | | A | E | +---+---+---+---+---+---+---+---+---+---+ 5 | O | I | O | T | O | E | | M | E | I | +---+---+---+---+---+---+---+---+---+---+ 6 | T | F | T | N | | T | A | | L | O | +---+---+---+---+---+---+---+---+---+---+ 7 | T | E | | A | P | H | . | | D | R | +---+---+---+---+---+---+---+---+---+---+ 8 | O | S | C | | I | T | W | | I | E | +---+---+---+---+---+---+---+---+---+---+ 9 | Y | * | <- * := EOM +---+---+ ============================================================ Decrypted Transposition Message ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | N | O | W | | I | S | | T | H | E | +---+---+---+---+---+---+---+---+---+---+ 1 | | T | I | M | E | | F | O | R | | +---+---+---+---+---+---+---+---+---+---+ 2 | A | L | L | | G | O | O | D | | M | +---+---+---+---+---+---+---+---+---+---+ 3 | E | N | | T | O | | C | O | M | E | +---+---+---+---+---+---+---+---+---+---+ 4 | | T | O | | T | H | E | | A | I | +---+---+---+---+---+---+---+---+---+---+ 5 | D | | O | F | | T | H | E | I | R | +---+---+---+---+---+---+---+---+---+---+ 6 | | P | A | R | T | Y*| . | N | O | W | * := Last char +---+---+---+---+---+---+---+---+---+---+ received 7 | | I | S | | | | T | I | +---+---+---+---+ +---+---+---+ all partially 8 | M | E | | F | | A | L | filled rows +---+---+ +---+ +---+---+ after the row 9 | | | O | | E | with the last +---+ +---+ +---+ char received 10 | T | | C | | | are discarded +---+ +---+ +---+ 11 | | | D | +---+ +---+ 12 | | +---+ The actual shape of any particular received message block will vary randomly with the key and the length of the message transmitted. ============================================================ Transposition column selection table The Message Encryption Key X[0] = 0.123456789 register K1 R = 3.995678901 register K2 Y[0] = 0.234567891 register M Set calculator rounding to 0 decimal digits (2nd Fn - Tab - 0) ie, show only integer portion of answer ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | 9 | 2 | 7 | 2 | 4 | 1 | 9 | 1 | 5 | 8 | +---+---+---+---+---+---+---+---+---+---+ 1 | 1 | 4 | 4 | 1 | 6 | 6 | 6 | 3 | 8 | 4 | +---+---+---+---+---+---+---+---+---+---+ 2 | 4 | 4 | 0 | 1 | 8 | 9 | 5 | 9 | 2 | 1 | +---+---+---+---+---+---+---+---+---+---+ 3 | 3 | 7 | 1 | 3 | 7 | 5 | 6 | 1 | 1 | 0 | +---+---+---+---+---+---+---+---+---+---+ 4 | 6 | 7 | 1 | 8 | 4 | 2 | 3 | 8 | 9 | 8 | +---+---+---+---+---+---+---+---+---+---+ 5 | 5 | 9 | 3 | 2 | 9 | 7 | 4 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+---+---+ 6 | 1 | 4 | 5 | 8 | 8 | 9 | 8 | 2 | 9 | 3 | +---+---+---+---+---+---+---+---+---+---+ 7 | 6 | 8 | 5 | 3 | 2 | 7 | 7 | 8 | 8 | 0 | +---+---+---+---+---+---+---+---+---+---+ 8 | 4 | 3 | 4 | 1 | 2 | 5 | 0 | 8 | 0 | 2 | +---+---+---+---+---+---+---+---+---+---+ 9 | 6 | 7 | 2 | 1 | 1 | 2 | 6 | 4 | 1 | 3 | +---+---+---+---+---+---+---+---+---+---+ 10 | 2 | 6 | 6 | 1 | 8 | 9 | 5 | 1 | 2 | 8 | +---+---+---+---+---+---+---+---+---+---+ G: Sample Message Key Generation The Master Encryption Key X[0] = 0.567890123 register K1 R = 3.998901234 register K2 Y[0] = 0.345678912 register M Calculator set to No Rounding (2nd Fn - Tab - .) ie, show all decimal digits Calculate the Message Encryption Key for the 5th message Repeat calculation of K[i] 5 times K[1] = 0.886684581 K[2] = 0.025546435 K[3] = 0.246545962 K[4] = 0.268216342 K[5] = 0.589846665 R <- 3.99 + (K[5]/100) = 3.995898467 K'[6] = 0.337260078 X <- K'[6] = 0.337260078 K'[7] = 0.83623299 Y <- K'[7] = 0.83623299 K'[8] = 0.208478335 R <- 3.99 + (K'[8]/100) = 3.992084783 The resulting Message Encryption Key for message #5 is: X[0] = 0.381353099 register K1 R = 3.992084783 register K2 Y[0] = 0.546680583 register M

1 0

removing a key from the keyserver. (eeps)
by Sameer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I seem to have a bit of a problem-- There's about 4 different public keys with my name on them, and I only use of them these days. I don't have the secret keys for the unused keys-- they've been retired to the great bit bit bucket in the sky.. Is there some way I can get these keys off the servers? -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVKIAni7eNFdXppdAQGhcwQAgzqGzRmirI/7hfkcZj1UzXdloM1PjWw1 M+GbREctd4pkUTTZNQQI15bOFf7OQRNvE3/Yi7HqlqNlEbXGjS/RYG262SX+zi+5 QLF8fs2kzQc5gH/CRQUHMhnr8tceokhFzTU1sF2yDRb/h+5hJbFG4cTYv+W0A0se IDCzSfgBa00= =UDOy -----END PGP SIGNATURE-----

1 0

Information
by PURTEB＠vaxc.hofstra.edu 17 Dec '03

17 Dec '03

To Whom It May Concern: I'd like some information/literature on you cryptography software. My friend, Brian, is the one who is actually interested, so please send any info to: BRIAN T.L. STRAUSS 357 Doris Avenue Franklin Square, NY 11010 Or, if necessary, you may email any info to the vax account listed at the bottom of this letter. Thank you. Theresa Barley _______________________________________________________________________________ Theresa Barley Hofstra University "Only visiting this planet." Purchasing Department purteb(a)vaxc.hofstra.edu

1 0

CERT advisory
by Alan (Miburi-san) Wexelblat 17 Dec '03

17 Dec '03

[Some items of interest to C-punks include CERT's advocacy of stopping cleartext transmission of password (no shit sherlock), and their proposed solutions, including the use of one-time passwords which I had queried about on this list a few months back. Of course they don't mention any sort of real encryption, let alone PGP. How hard would it be to build in PGP security to the transmission layer of something like FTP? Seems like a fairly simple problem, given that any site which supports anonymous FTP can publish a public key. Even if we assume that encryption would slow down the file transmission too much, we could still use it for the login/authentication part of the session... --AW] Begin forwarded message: From: CERT Advisory <cert-advisory-request(a)cert.org> Date: Thu, 3 Feb 94 21:14:40 EST To: cert-advisory(a)cert.org Subject: CERT Advisory - Ongoing Network Monitoring Attacks Organization: Computer Emergency Response Team : 412-268-7090 ============================================================================= CA-94:01 CERT Advisory February 3, 1994 Ongoing Network Monitoring Attacks ----------------------------------------------------------------------------- In the past week, CERT has observed a dramatic increase in reports of intruders monitoring network traffic. Systems of some service providers have been compromised, and all systems that offer remote access through rlogin, telnet, and FTP are at risk. Intruders have already captured access information for tens of thousands of systems across the Internet. The current attacks involve a network monitoring tool that uses the promiscuous mode of a specific network interface, /dev/nit, to capture host and user authentication information on all newly opened FTP, telnet, and rlogin sessions. In the short-term, CERT recommends that all users on sites that offer remote access change passwords on any network-accessed account. In addition, all sites having systems that support the /dev/nit interface should disable this feature if it is not used and attempt to prevent unauthorized access if the feature is necessary. A procedure for accomplishing this is described in Section III.B.2 below. Systems known to support the interface are SunOS 4.x (Sun3 and Sun4 architectures) and Solbourne systems; there may be others. Sun Solaris systems do not support the /dev/nit interface. If you have a system other than Sun or Solbourne, contact your vendor to find if this interface is supported. While the current attack is specific to /dev/nit, the short-term workaround does not constitute a solution. The best long-term solution currently available for this attack is to reduce or eliminate the transmission of reusable passwords in clear-text over the network. ----------------------------------------------------------------------------- I. Description Root-compromised systems that support a promiscuous network interface are being used by intruders to collect host and user authentication information visible on the network. The intruders first penetrate a system and gain root access through an unpatched vulnerability (solutions and workarounds for these vulnerabilities have been described in previous CERT advisories, which are available anonymous FTP from info.cert.org) The intruders then run a network monitoring tool that captures up to the first 128 keystrokes of all newly opened FTP, telnet, and rlogin sessions visible within the compromised system's domain. These keystrokes usually contain host, account, and password information for user accounts on other systems; the intruders log these for later retrieval. The intruders typically install Trojan horse programs to support subsequent access to the compromised system and to hide their network monitoring process. II. Impact All connected network sites that use the network to access remote systems are at risk from this attack. All user account and password information derived from FTP, telnet, and rlogin sessions and passing through the same network as the compromised host could be disclosed. III. Approach There are three steps in CERT's recommended approach to the problem: - Detect if the network monitoring tool is running on any of your hosts that support a promiscuous network interface. - Protect against this attack either by disabling the network interface for those systems that do not use this feature or by attempting to prevent unauthorized use of the feature on systems where this interface is necessary. - Scope the extent of the attack and recover in the event that the network monitoring tool is discovered. A. Detection The network monitoring tool can be run under a variety of process names and log to a variety of filenames. Thus, the best method for detecting the tool is to look for 1) Trojan horse programs commonly used in conjunction with this attack, 2) any suspect processes running on the system, and 3) the unauthorized use of /dev/nit. 1) Trojan horse programs: The intruders have been found to replace one or more of the following programs with a Trojan horse version in conjunction with this attack: /usr/etc/in.telnetd and /bin/login - Used to provide back-door access for the intruders to retrieve information /bin/ps - Used to disguise the network monitoring process Because the intruders install Trojan horse variations of standard UNIX commands, CERT recommends not using other commands such as the standard UNIX sum(1) or cmp(1) commands to locate the Trojan horse programs on the system until these programs can be restored from distribution media, run from read-only media (such as a mounted CD-ROM), or verified using cryptographic checksum information. In addition to the possibility of having the checksum programs replaced by the intruders, the Trojan horse programs mentioned above may have been engineered to produce the same standard checksum and timestamp as the legitimate version. Because of this, the standard UNIX sum(1) command and the timestamps associated with the programs are not sufficient to determine whether the programs have been replaced. CERT recommends that you use both the /usr/5bin/sum and /bin/sum commands to compare against the distribution media and assure that the programs have not been replaced. The use of cmp(1), MD5, Tripwire (only if the baseline checksums were created on a distribution system), and other cryptographic checksum tools are also sufficient to detect these Trojan horse programs, provided these programs were not available for modification by the intruder. If the distribution is available on CD-ROM or other read-only device, it may be possible to compare against these volumes or run programs off these media. 2) Suspect processes: Although the name of the network monitoring tool can vary from attack to attack, it is possible to detect a suspect process running as root using ps(1) or other process-listing commands. Until the ps(1) command has been verified against distribution media, it should not be relied upon--a Trojan horse version is being used by the intruders to hide the monitoring process. Some process names that have been observed are sendmail, es, and in.netd. The arguments to the process also provide an indication of where the log file is located. If the "-F" flag is set on the process, the filename following indicates the location of the log file used for the collection of authentication information for later retrieval by the intruders. 3) Unauthorized use of /dev/nit: If the network monitoring tool is currently running on your system, it is possible to detect this by checking for unauthorized use of the /dev/nit interface. CERT has created a minimal tool for this purpose. The source code for this tool is available via anonymous FTP on info.cert.org in the /pub/tools/cpm directory or on ftp.uu.net in the /pub/security/cpm directory as cpm.1.0.tar.Z. The checksum information is: Filename Standard UNIX Sum System V Sum -------------- ----------------- ------------ cpm.1.0.tar.Z: 11097 6 24453 12 MD5 Checksum MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155 This archive contains a readme file, also included as Appendix C of this advisory, containing instructions on installing and using this detection tool. B. Prevention There are two actions that are effective in preventing this attack. A long-term solution requires eliminating transmission of clear-text passwords on the network. For this specific attack, however, a short-term workaround exists. Both of these are described below. 1) Long-term prevention: CERT recognizes that the only effective long-term solution to prevent these attacks is by not transmitting reusable clear-text passwords on the network. CERT has collected some information on relevant technologies. This information is included as Appendix B in this advisory. Note: These solutions will not protect against transient or remote access transmission of clear-text passwords through the network. Until everyone connected to your network is using the above technologies, your policy should allow only authorized users and programs access to promiscuous network interfaces. The tool described in Section III.A.3 above may be helpful in verifying this restricted access. 2) Short-term workaround: Regardless of whether the network monitoring software is detected on your system, CERT recommends that ALL SITES take action to prevent unauthorized network monitoring on their systems. You can do this either by removing the interface, if it is not used on the system or by attempting to prevent the misuse of this interface. For systems other than Sun and Solbourne, contact your vendor to find out if promiscuous mode network access is supported and, if so, what is the recommended method to disable or monitor this feature. For SunOS 4.x and Solbourne systems, the promiscuous interface to the network can be eliminated by removing the /dev/nit capability from the kernel. The procedure for doing so is outlined below (see your system manuals for more details). Once the procedure is complete, you may remove the device file /dev/nit since it is no longer functional. Procedure for removing /dev/nit from the kernel: 1. Become root on the system. 2. Apply "method 1" as outlined in the System and Network Administration manual, in the section, "Sun System Administration Procedures," Chapter 9, "Reconfiguring the System Kernel." Excerpts from the method are reproduced below: # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf # cp CONFIG_FILE SYS_NAME [Note that at this step, you should replace the CONFIG_FILE with your system specific configuration file if one exists.] # chmod +w SYS_NAME # vi SYS_NAME # # The following are for streams NIT support. NIT is used by # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, # NIT is almost always needed on a server and almost never # needed on a diskless client. # pseudo-device snit # streams NIT pseudo-device pf # packet filter pseudo-device nbuf # NIT buffering module [Comment out the preceding three lines; save and exit the editor before proceeding.] # config SYS_NAME # cd ../SYS_NAME # make # mv /vmunix /vmunix.old # cp vmunix /vmunix # /etc/halt > b [This step will reboot the system with the new kernel.] [NOTE that even after the new kernel is installed, you need to take care to ensure that the previous vmunix.old , or other kernel, is not used to reboot the system.] C. Scope and recovery If you detect the network monitoring software at your site, CERT recommends following three steps to successfully determine the scope of the problem and to recover from this attack. 1. Restore the system that was subjected to the network monitoring software. The systems on which the network monitoring and/or Trojan horse programs are found have been compromised at the root level; your system configuration may have been altered. See Appendix A of this advisory for help with recovery. 2. Consider changing router, server, and privileged account passwords due to the wide-spread nature of these attacks. Since this threat involves monitoring remote connections, take care to change these passwords using some mechanism other than remote telnet, rlogin, or FTP access. 3. Urge users to change passwords on local and remote accounts. Users who access accounts using telnet, rlogin, or FTP either to or from systems within the compromised domain should change their passwords after the intruder's network monitor has been disabled. 4. Notify remote sites connected from or through the local domain of the network compromise. Encourage the remote sites to check their systems for unauthorized activity. Be aware that if your site routes network traffic between external domains, both of these domains may have been compromised by the network monitoring software. --------------------------------------------------------------------------- The CERT Coordination Center thanks the members of the FIRST community as well as the many technical experts around the Internet who participated in creating this advisory. Special thanks to Eugene Spafford of Purdue University for his contributions. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). Internet E-mail: cert(a)cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. --------------------------------------------------------------------------- Appendix A: RECOVERING FROM A UNIX ROOT COMPROMISE A. Immediate recovery technique 1) Disconnect from the network or operate the system in single- user mode during the recovery. This will keep users and intruders from accessing the system. 2) Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such as cmp(1) located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIX sum(1) program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups. -- or -- Reload your system from the vendor's media. 3) Search the system for new or modified setuid root files. find / -user root -perm -4000 -print If you are using NFS or AFS file systems, use ncheck to search the local file systems. ncheck -s /dev/sd0a 4) Change the password on all accounts. 5) Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder. B. Improving the security of your system 1) CERT Security Checklist Using the checklist will help you identify security weaknesses or modifications to your systems. The CERT Security Checklist is based on information gained from computer security incidents reported to CERT. It is available via anonymous FTP from info.cert.org in the file pub/tech_tips/security_info. 2) Security Tools Use security tools such as COPS and Tripwire to check for security configuration weaknesses and for modifications made by intruders. We suggest storing these security tools, their configuration files, and databases offline or encrypted. TCP daemon wrapper programs provide additional logging and access control. These tools are available via anonymous FTP from info.cert.org in the pub/tools directory. 3) CERT Advisories Review past CERT advisories (both vendor-specific and generic) and install all appropriate patches or workarounds as described in the advisories. CERT advisories and other security-related information are available via anonymous FTP from info.cert.org in the pub/cert_advisories directory. To join the CERT Advisory mailing list, send a request to: cert-advisory-request(a)cert.org Please include contact information, including a telephone number. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Copyright (c) Carnegie Mellon University 1994 --------------------------------------------------------------------------- Appendix B: ONE-TIME PASSWORDS Given today's networked environments, CERT recommends that sites concerned about the security and integrity of their systems and networks consider moving away from standard, reusable passwords. CERT has seen many incidents involving Trojan network programs (e.g., telnet and rlogin) and network packet sniffing programs. These programs capture clear-text hostname, account name, password triplets. Intruders can use the captured information for subsequent access to those hosts and accounts. This is possible because 1) the password is used over and over (hence the term "reusable"), and 2) the password passes across the network in clear text. Several authentication techniques have been developed that address this problem. Among these techniques are challenge-response technologies that provide passwords that are only used once (commonly called one-time passwords). This document provides a list of sources for products that provide this capability. The decision to use a product is the responsibility of each organization, and each organization should perform its own evaluation and selection. I. Public Domain packages S/KEY(TM) The S/KEY package is publicly available (no fee) via anonymous FTP from: thumper.bellcore.com /pub/nmh directory There are three subdirectories: skey UNIX code and documents on S/KEY. Includes the change needed to login, and stand-alone commands (such as "key"), that computes the one-time password for the user, given the secret password and the S/KEY command. dos DOS or DOS/WINDOWS S/KEY programs. Includes DOS version of "key" and "termkey" which is a TSR program. mac One-time password calculation utility for the Mac. II. Commercial Products Secure Net Key (SNK) (Do-it-yourself project) Digital Pathways, Inc. 201 Ravendale Dr. Mountainview, Ca. 94043-5216 USA Phone: 415-964-0707 Fax: (415) 961-7487 Products: handheld authentication calculators (SNK004) serial line auth interruptors (guardian) Note: Secure Net Key (SNK) is des-based, and therefore restricted from US export. Secure ID (complete turnkey systems) Security Dynamics One Alewife Center Cambridge, MA 02140-2312 USA Phone: 617-547-7820 Fax: (617) 354-8836 Products: SecurID changing number authentication card ACE server software SecureID is time-synchronized using a 'proprietary' number generation algorithm WatchWord and WatchWord II Racal-Guardata 480 Spring Park Place Herndon, VA 22070 703-471-0892 1-800-521-6261 ext 217 Products: Watchword authentication calculator Encrypting modems Alpha-numeric keypad, digital signature capability SafeWord Enigma Logic, Inc. 2151 Salvio #301 Concord, CA 94520 510-827-5707 Fax: (510)827-2593 Products: DES Silver card authentication calculator SafeWord Multisync card authentication calculator Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as other OS versions. Supports one-time passwords and super smartcards from several vendors. --------------------------------------------------------------------------- Appendix C: cpm 1.0 README FILE cpm - check for network interfaces in promiscuous mode. Copyright (c) Carnegie Mellon University 1994 Thursday Feb 3 1994 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 This program is free software; you can distribute it and/or modify it as long as you retain the Carnegie Mellon copyright statement. It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z. This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED WARRANTY of merchantability or fitness for a particular purpose. This package contains: README MANIFEST cpm.1 cpm.c To create cpm under SunOS, type: % cc -Bstatic -o cpm cpm.c On machines that support dynamic loading, such as Sun's, CERT recommends that programs be statically linked so that this feature is disabled. CERT recommends that after you install cpm in your favorite directory, you take measures to ensure the integrity of the program by noting the size and checksums of the source code and resulting binary. The following is an example of the output of cpm and its exit status. Running cpm on a machine where both the le0 and le2 interfaces are in promiscuous mode, under csh(1): % cpm le0 le2 % echo $status 2 % Running cpm on a machine where no interfaces are in promiscuous mode, under csh(1): % cpm % echo $status 0 %

5 7

Announcing SecureDrive 1.3A
by edgar＠spectrx.saigon.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is to announce the availability of Version 1.3A of SecureDrive. This is a maintenance release of SecureDrive 1.3. It mainly fixes reported problems and has minimal new function. See file BUGS13.DOC. The only visible functional change from 1.3 is the appearance of msg Check bytes in Disk x: Boot Sector need updating from 1.3 to 1.1/1.3A. Proceed? which will be issued by both LOGIN and CRYPTDSK when they attempt to verify a passphrase on a hard disk or diskette encrypted by version 1.3 CRYPTDSK operating in version 1.1 compatability mode. This corrects the error in computing the check bytes used to verify the passphrase and updates the check bytes to the correct 1.1 value and WRITES back the boot sector. Note that once this update has taken place, this disk cannot be decrypted by release 1.3 anymore. Releases 1.3 and 1.3A of Secure Drive are based on releases 1.0 and 1.1, mostly written by Mike Ingle <mikeingle(a)delphi.com> and version 1.2, with significant new code by myself. The code which we wrote is not copyrighted, but the program contains GNU Copylefted code, and therefore may be freely distributed under the terms of the GNU General Public Licence. See file COPYING for legalese. Version 1.2 and 1.3 add significant new function. As of Version 1.2, you may use an operand /PGP with LOGIN, either by itself, or with other operands. By itself, LOGIN /PGP will prompt for a passphrase and set the PGPPASS environment variable with whatever is entered. If PGPPASS is already set then LOGIN D: /PGP or LOGIN /F /PGP will use whatever PGPPASS is set to as the passphrase. For the hard disk partition, LOGIN will test the PGPPASS passphrase. If it is incorrect, then it will prompt you for another passphrase. If PGPPASS is NOT set when these forms of LOGIN are used, than a passphrase is prompted for AND PGPPASS is set to this passphrase. This is more secure than using the SET command since LOGIN only echoes "*"'s when entering the passphrase. As of Version 1.2, typing LOGIN /C /PGP will clear the SecureDrive crypto keys from memory AND clear the PGPPASS environment variable. This is done in a manner less likely to leave your passphrase in memory than just using the DOS SET command. In addition, Version 1.2 clears all the free memory it can find, which is likely to include some plaintext. However, if you want to be absolutely sure all traces of sensitive data are erased from memory then turning off the computer is still recommended. As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK will ask to use the value of PGPPASS for the passphrase before prompting you (for encryption), or try PGPPASS (for decryption). Obviously, if you encrypt or decrypt a lot of diskettes at once, this feature can save you a lot of typing. The purpose of these changes is to allow you to enter a single passphrase only once per boot IF you choose to use the same passphrase for your PGP secret key, your SecureDrive encrypted hard disk partition, and SecureDrive encrypted floppies. Version 1.3 supports up to four hard drive partitions in "safe" mode, only one of which may be active at any given time. One purpose of having multiple encrypted hard disk partitions is so that up to four users (perhaps members of a family) can each have their own encrypted partition with its own unique passphrase. This allows up to four users to have privacy from each other, even if they all use the same PC and physical hard disk(s). Version 1.3 gives you a choice of whether to use the version 1.1 passphrase digest or to use the (faster but perhaps slightly less secure) 1.0 version. If you select 1.0 compatiblity, it's unnecessary to decrypt and re-encrypt your 1.0-encrypted hard disk partition(s) and floppies. If you decide to switch to 1.1 passphrases, Version 1.3 CRYPTDSK will allow you to convert in one pass with no plaintext stored on disk. Version 1.3 includes the 1.2 changes for using PGPPASS. There are additional ehhancements to allow you to use the hard disk passphrase for the floppy disks without typing it in, even if PGPPASS is not set or is something different. Version 1.3 CRYPTDSK will operate on hard drives with SECTSR loaded. It uses SECTSR to protect the disk during conversion and will leave an encrypted disk partition in protected mode. Mike Ingle and I have different opinions on the distribution of SecureDrive. Under the GNU General License (copyleft) I do not need Mike's permission to distribute version 1.3 and I have not asked for same. My policy on distribution is in the version 1.3 doc: Exporting this program. Cryptography is export controlled, and sending this program outside the country may be illegal. Don't do it. The "author" of versions 1.2 and 1.3, Edgar Swank, says that the export ban should not prevent you from placing this program on public BBS's and anonymous FTP sites in the US and Canada. If individuals outside the US/Canada use the internet or international long distance to obtain copies of the program, THEY may be breaking US law. Any such foreign individuals should be aware that US law enforcement may legally (under US law) apprehend individuals who break US laws even if such individuals are not on or even have never been on US soil. Such apprehension may remove such individuals directly to US jurisdiction without benefit of extradition proceedings in such individuals' home country(ies). This has actually happened in at least two cases, Mexico -- suspect in murder of US drug agent, Panama -- Noriega -- indicted in absencia for drug smuggling. As is well known, after a small war with Panama, Noriega was brought to the USA, tried and convicted. He is now a guest of the US Government in a Florida prison. SecureDrive Version 1.3A is already available for download on the following public BBS's as SECDR13A.ZIP: Eagle's Nest (408)223-9821 Flying Dutchman (408)294-3065 Also I have a report (unverified so far) that Version 1.3 may now be obtained from a mailserver. Send mail to Server(a)Star.Hou.TX.US with body text that looks like this get /files/public/secdr13a.zip quit Please attempt to use the mailserver or the two BBS's above before requesting a copy directly from me. I will send a FEW more copies via E-mail to persons with a US/Canada net address who request a copy AND promise to upload it to a USA/Canada e-mail fileserver or anonymous FTP site. (I don't have access to FTP from my account here). I will announce here as I learn of Version 1.3A availability via additional automated e-mail or FTP sites. Here is the contents of SECDR13A.ZIP: Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 18321 DeflatX 6914 63% 06-14-93 22:27 0767480b --w- COPYING 1332 DeflatX 518 62% 01-30-94 09:30 bbb5655c --w- MAKEFILE 1632 DeflatX 1260 23% 12-04-93 00:43 980125ec --w- KEY.ASC 19664 DeflatX 4183 79% 11-19-93 21:42 22c2502c --w- CRYPT2.ASM 1355 DeflatX 629 54% 01-21-94 08:44 db63ade4 --w- RLDBIOS.ASM 24652 DeflatX 7740 69% 01-29-94 14:51 d0f5feaf --w- SECTSR.ASM 7507 DeflatX 2581 66% 12-29-93 21:15 ceda9b20 --w- SETENV.ASM 33 Stored 33 0% 07-16-93 06:09 aa6151a5 --w- M.BAT 16175 DeflatX 3949 76% 01-29-94 17:57 88215957 --w- CRYPTDSK.C 12260 DeflatX 3167 75% 01-29-94 18:27 7b10d96f --w- LOGIN.C 11557 DeflatX 3277 72% 05-09-93 19:38 e71f3eea --w- MD5.C 10860 DeflatX 2878 74% 01-29-94 18:07 3a9154c0 --w- SDCOMMON.C 1778 DeflatX 1160 35% 01-30-94 09:31 48688ff7 --w- SECTSR.COM 1152 DeflatX 586 50% 01-30-94 10:15 e44c593f --w- BUGS13.DOC 31425 DeflatX 10610 67% 01-30-94 09:59 235f457a --w- SECDRV.DOC 35024 DeflatX 16598 53% 01-30-94 09:31 99417b77 --w- CRYPTDSK.EXE 34072 DeflatX 16021 53% 01-30-94 09:31 26a2fb82 --w- LOGIN.EXE 3407 DeflatX 1097 68% 05-11-93 12:49 f1f58517 --w- MD5.H 3020 DeflatX 909 70% 01-24-94 03:32 8ee1c1f6 --w- SECDRV.H 1254 DeflatX 541 57% 05-09-93 19:39 182978aa --w- USUALS.H 152 Stored 152 0% 01-30-94 10:03 68a2560c --w- SECTSR.SIG 152 Stored 152 0% 01-30-94 10:04 a1d33655 --w- LOGIN.SIG 152 Stored 152 0% 01-30-94 10:04 845de45f --w- CRYPTDSK.SIG ------ ------ --- ------- 236936 85107 65% 23 Also note that the ZIP file contains PGP detached signatures (*.SIG) for the executable files. Finally here is my public key, also available on many public keyservers; note who has signed it. Type bits/keyID Date User ID pub 1024/87C0C7 1992/10/17 Edgar W. Swank <edgar(a)spectrx.saigon.com> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIF ECwAALo04ip/MkW/XQEBmNQD/0jUVqT0LMoVvw7Zz2FXyWrdBn6bRlyGxeqQWhig DXRipZ824/fHbA2vkbAczEayw8ZpwRVmhWNsxxWhjYFIi92KYJbAP/XIbr+rEuTI hPKKKKhuuGLUWhfXhCFluHjs3CA6ZQwnT4jnu1NlCkcnWLbL4ktqub2zLwrHCPUe 31L1iQCUAgUQK9Y50xgzoWUItwfFAQHPrAPzBbf6lQyzwbUwdxayzLDoh3Hygnun Looi+yzziEVQchOgSt3sLe2I108DLxTgp+26lJYTAZB+Gg8HGyB+Nz6263D0XlVU XQi9/7CSRyd8bhYFeuFPwFzHPWZlyLDAIsuaEfBsmp2DBLgffvhUCqiiWYmP9oa+ rOA+5IHS+xN8tIkAVQIFECu5dYOzvL/Jh3qmYQEBYDICAI5KdaTiPr2Y1OtRCTi6 xMG6hnRNalvK9C5d/bxrKnUYqsfSpKayX+Ts9psmq6a6doOrX3AAtgcZuTCYUfQk d22JAJUCBRArlzITocE4X0qvAOUBAahdA/4rRoSVp3G+Ki0wvkcAvpnwt7vSEYpH XSkyoC8LdAqs9bft5NDTOykgw5H1qFG1Doqk6oR0yxY0k91eVoBVclLWDb94sNO3 JjHJKO/QdODik5DpmXEnQhBfLlujuYkCtJjoBv1+QdImnnv9aNidGuLAneNvZ+UN NqfE3IRShzNw3IkAlQIFECtj5iw2VpfGMt2Y2QEBDEYD/2iMMml65eFaNWrNP7ab Yh8QW3+Mnjyl5CNpAjGkxejmIm4nZKqUHN5DuGzpJDnstRwbz6daXK15XcoM1m8g uhu6UzIwHs9+hbKE6inTCz4C0mE55PSmvF/ejjexnGzsiFpuFnjN/sRrSHc57flO IUWBCZD8Hizz3aYBxmvwJ863iQCVAgUQKxEXHOJ13g7/Z/cLAQGyYgP/apcv9V2M bHFgU0hl0D4MLqGjBReUfDroxQCsgsTb/0nr1W9yltBMqYPgD7ThLAf2rxIPNbGy D7VUA27LTwQTS6n2mbtkHOvGQVw7J2GwTA6319Gf0Qne0M1h7VJWjFX0Vzjuh/nk 6btxM2uTLSF2nUsDXe5/9N5XeesFhrbXNrM= =4fGE - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVFwE94nNf3ah8DHAQEkVQP/QzHZ0oqDW3XYrpYANTfeA7hIMgweKz8N 7/UpkV5XHhePwEfJA3fFn2Gs/BwF6Oy0xsJOk16AIE5JtAWqp5x3jzQ6BuJhkhhk RcVrmtqqBfj8PMnpm3rdQRUMC9CftxA/m06y3Cw5FHgxvrOXcZfyrsBIR26UejsI 4fOY+JjlglQ= =sBOp -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

STEG: a real-life use for steganography
by hughes＠ah.com 17 Dec '03

17 Dec '03

I had an extremely interesting conversation with a fellow last night, say, X. A mutual friend of ours had steered him towards me. X has contacts in a country C which will remain nameless. The government of C is extremely repressive and has a large internal police force. The situation, evidently, is one similar to the old USSR, where masks behind masks were used in daily life, little is exactly as it appears, and the default discourse is sideways speaking. The scenario is almost worst-case. There is a need for steganography, since the use of cryptography is grounds for suppression; likewise there is a need for covert channels. There is a need for double-blinding of identities, since one's friends may be difficult to detect. And so on. The aspect that _is_ good is that C is not the whole world, and there are plenty of us not in C. The first most useful facility to set up, X thinks, is simply news from outside of C as a bypass of the media in C--wire service articles about C, for example, as well as a feed of the newsgroup "soc.culture.<C>". Here's the technique we came up with last night. C has an indigenous music M which is periodically performed in the United States. We were thinking about pressing short-run CD's of these live performances. We all know where the news feeds go. The CD's would be distributed via standard music channels and would be surprisingly brisk sellers. The costs of the project can evidently be footed by willing members of the M industry in C. Now let me address the standard comment "Oh, steganography completely solves that problem." Please. That's like saying, "Oh, just use an internal combustion engine to solve your long distance transport problems." Such statements are a failure of imagination and seriousness. A practical system to carry this project out is quite large. I see at least the following pieces needed: -- A facility to gather the data being put on the disks. This by itself is no trivial task, since it involves the collection of many disparate sources. -- An authoring system to arrange the data, once collected, into a usable structure. -- An encryption system for the arranged data. Such a system can't treat the data as one long stream, because of the segmented nature of the data. The ability to mount the CD as a file system would be good leverage for other programmers. -- A mastering system to combine a music master CD (done separately) and a data master (in some format) into a new music master CD. This will, at the least require a machine with a CD reader and writer. Blank media, FYI, for a CD writer are about $20/disk. The CD writer is about $5K. These numbers are approximate and falling rapidly. -- A CD pressing facility. These are commercially available at quite reasonable cost in quantities in the 100's. -- A CD distribution system. This will likely be the M industry, and thankfully the details of international shipping and customs will be taken care of, as well as retail distribution. -- A decryption system to get the data off the CD. -- Client software to make use of the information. It need not all be in text format. -- A key distribution system. A secret key per CD and word of mouth may be sufficient. A system to make rememberable sentences out of an arbitrary 128 bits (and the inverse) would be useful to facilitate word of mouth. This is no small task. Those interested in participating may start working on any of the above. The tasks are fairly separable. Here are some that I can identify as critical. -- A standard for encoding data into the low bits of an audio CD. This will likely require a lot of specific knowledge of the low level encoding and error correction systems used in CD's. I do know that they are not simple, being much more than bit-correcting linear codes. -- A standard for the encoding of file system data onto these low bits. This should be a separate document, even though the design of this will be influenced by the bit encoding standard. Some adaptation of existing file system standards may be appropriate. -- A standard for the encryption format for the file system. It may be that Matt Blaze's CFS cryptograpy can be lifted wholesale. -- Multiplatform software support for all of the above. I am pleased to have a real example to work on, rather than a lot of wixering about hypotheticals. I welcome discussion of this topic. Eric

5 4

Re: San Jose BBS subject to M
by freeman＠MasPar.COM 17 Dec '03

17 Dec '03

> Hmm... wish I had the exact original handy to mis-quote ... Is this the one you mean? First they came for the Communists, and I didn't speak up, because I wasn't a Communist. Then they came for the Jews, and I didn't speak up, because I wasn't a Jew. Then they came for the Catholics, and I didn't speak up, because I was a Protestant. Then they came for me, and by that time there was no one left to speak up for me. by Rev. Martin Niemoller, 1945.

1 0

UNSUB
by MCALVINK＠ccmail.sunysb.edu 17 Dec '03

17 Dec '03

UNSUBSCRIBE m calvinkoons

2 1