RE: NONSTOP Crypto Query
I've seen an existance proof which indicates that this is possible. Back when I was first getting involved with computers (circa 1972), some digitizer tablets worked by speed-of-sound measurements. The stylus tip contained a small spark gap which was energized when the stylus pressed on the tablet. This created a spark, and the spark a minuscule roll of thunder. Microphones situated along the edges of the tablet recorded the arrival times of the sound, and the location of the stylus calculated within a millimeter or two. This was a peripheral for a DEC PDP-8E. This was calculating a position over about 20 cm to a millimeter, in real time, in 1972. Doing so to a resolution of a centimeter or two, in 2001, ever several meters sounds feasible. Peter Trei -- From: Ray Dillinger[SMTP:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 4:37 PM To: John Young Cc: [EMAIL PROTECTED] Subject: Re: NONSTOP Crypto Query On Fri, 12 Jan 2001, John Young wrote: Wright also describes the use of supersensitive microphones to pick up the daily setting of rotors on cryptomachines of the time, in particular the Hagelins made by CryptoAG. Hmmm. That sounds like a trick that could be brought up to date. If you get two sensitive microphones in a room, you should be able to do interferometry to get the exact locations on a keyboard of keystrokes from the sound of someone typing. I guess three would be better, but with some reasonable assumptions about keys being coplanar or on a surface of known curvature, two would do it. Interesting possibilities. Bear [A quick contemplation of the wavelength of the sounds in question would put an end to that speculation I suspect. --Perry]
Spark gap digitizers (was NONSTOP Crypto Query)
I remember those. They were made by Summagraphics. We purchased a large format one (about 4 feet X 5 feet) to digitize apparel patterns. They had linear microphones along the top and left sides of the table. You had to be careful not to put your free hand between the spark pen and the microphones. I recall reading about 3-D versions. The tablets were accurate to a few hundredths of an inch but were not that reliable. I think they simply started two counters when the spark went off and stopped each when the microphone registered a sound. If I remember right the did around 5 points per second. We eventually switched to mechanical technology. The noise from a spark probably has a much faster rise time than a keyboard click, but with modern signal processing it might well be feasible to resolve key presses. Of course, if one can get access to the room where the computer is used, it is probably easier to bug the keyboard directly. Still it may be time to add mouse-based passphrase input as an option to programs like PGP. Arnold Reinhold At 10:24 AM -0500 1/15/2001, Trei, Peter wrote: I've seen an existance proof which indicates that this is possible. Back when I was first getting involved with computers (circa 1972), some digitizer tablets worked by speed-of-sound measurements. The stylus tip contained a small spark gap which was energized when the stylus pressed on the tablet. This created a spark, and the spark a minuscule roll of thunder. Microphones situated along the edges of the tablet recorded the arrival times of the sound, and the location of the stylus calculated within a millimeter or two. This was a peripheral for a DEC PDP-8E. This was calculating a position over about 20 cm to a millimeter, in real time, in 1972. Doing so to a resolution of a centimeter or two, in 2001, ever several meters sounds feasible. Peter Trei -- From:Ray Dillinger[SMTP:[EMAIL PROTECTED]] Sent:Friday, January 12, 2001 4:37 PM To: John Young Cc: [EMAIL PROTECTED] Subject: Re: NONSTOP Crypto Query On Fri, 12 Jan 2001, John Young wrote: Wright also describes the use of supersensitive microphones to pick up the daily setting of rotors on cryptomachines of the time, in particular the Hagelins made by CryptoAG. Hmmm. That sounds like a trick that could be brought up to date. If you get two sensitive microphones in a room, you should be able to do interferometry to get the exact locations on a keyboard of keystrokes from the sound of someone typing. I guess three would be better, but with some reasonable assumptions about keys being coplanar or on a surface of known curvature, two would do it. Interesting possibilities. Bear [A quick contemplation of the wavelength of the sounds in question would put an end to that speculation I suspect. --Perry]
efdtt source
[Moderator's Note: I point out that this version of this code actually
does fit on a T-shirt, unlike other versions that only partially
fit. As for possible controversy: I take the position that the first
amendment continues to be in force in the U.S. and that this is a
scholarly discussion list. --Perry]
I call this program `efdtt'. It may or may not decrypt certain MPEG
system streams which may or may not be found on certain types of media
which may or may not be available for purchase in numerous stores that
may or may not have sold antiquated tape-based media in the past.
Usage is:
cat key input.vob | efdtt output.vob
Shar and enjoy. If you redistribute this, please credit me somewhere.
If you're interested in making T-shirts, please contact me. B-)
#include unistd.h
#define K(i) (k[i]^s[i+84])
u_int r(u_int);int main(){u_char*x="\331\231\321\0I\tA\220\6\202\0$\4\200\2",y
=0,z,t[256],k[5],s[2048];do z=x[y7]^x[y4|8]^(y/817)*11161,t[y]=z^(zz*234
)*6;while(++y);read(0,k,5);while(read(0,s,2048)){if(s[20]48){u_int a=r(K(1)9
^256^K(0))15,b=r((K(4)17^K(3)9^K(2)*2)+8-(K(2)7))7,c=0,i=128;for(;i
2048;i++){y=a^a14;y^=y*8^y6;z=b^b/8^b4^b12;a=a8|y9;b=b8|z17;s[i
]=t[s[i]]^z+c+~y;c=z+cy;}s[20]=143;}write(1,s,2048);}}
SHA-1 testing
Hello, Can somebody tell me if the following statements are correct. Thank you very much. According with the DSSVS User's Guide document that can be find on http://csrc.nist.gov/cryptval/ under SHA-1 topic, for Type III testing (Pseudorandomly Generated Messages) the appendix E provides a procedure. In the procedure j can go from 0 to 99, "i" is a 32 bit word, the size of the seed is 416 bits, and the result of an SHA processing has a size of 160 bits. Based on that the size of M that is passed to SHA for processing will be as follow. 416 + 0 + 24 + 32 = 472 bits 160 + 0 + 24 + 32 = 216 bits Then as j increments the size of M will increment with a byte length up to 408 bits. That means that after padding only for the M = 472 bits will have two blocks of 512 bits, and for the M = 216 408 bits will have just one block of 512 bits. Is may understanding correct or I am missing something, because I really have the feeling that I missed something. Again, thank you very much for any advice. Marius Corbu.
SHA-1 testing
Hello,
Sorry for sending this message again, but I fought that adding the APENDIX E to the
message will make it more clear.
Can somebody tell me if the following statements are correct. Thank you very much.
According with the DSSVS User's Guide document that can be find on
http://csrc.nist.gov/cryptval/ under SHA-1 topic,
for Type III testing (Pseudorandomly Generated Messages) the appendix E
provides a procedure.
***
APPENDIX E: Description of the SHS Type 3 Test
This test determines whether the DUT can compute message digests for messages that are
generated using a
given seed, which is provided in "sha.req". A sequence of 100 message digests is
generated by the DUT using this
seed. The DUT portion of the testing procedure is as follows:
The DUT:
1.Obtains SHS Request Type 3 message M (416 bits) from the "sha.req" file (this is
the "seed").
2.Performs the following test, using M as input:
procedure testSHS(M,D[0], . . . D[99])
string M,D[0], . . . D[99];
{
integer i, j, a;
for j = 0 to 99 do
{
for i = 1 to 5 do
{
for a = 1 to (j/4*8 + 24) do M := M || '0';
/* '0' is the binary zero bit. */
M := M || i;
/* Here, the value for 'i' is expressed as a 32-bit word and concatenated with
'M'. The first bit
concatenated with 'M' is the most significant bit of this 32-bit word. */
M := SHA(M);
}
D[j] := M;
}
}
NOTE: In the above procedure, || denotes concatenation. Also, M || i denotes
appending the 32-bit word
representing the value 'i', as defined in section 2 of the SHS. Within the
procedure, M is a string of variable
length, determined by the DSSVS; its initial value is assumed to be input.
Together, the initial length of
416 bits and the expression "j/4*8 + 24" (where j/4 is integer division) ensure
that messages will be of a
byte length. Each element of the resulting sequence {D[j]} should be 160 bits in
length.
3.Forwards the resulting 100 message digests stored in D[0], . . . D[99] as a
sequence in SHS Response Type 3
with Di = D[j]. This is the last section of the "sha.rsp" file.
***
In the procedure j can go from 0 to 99, "i" is a 32 bit word, the size of the
seed is 416 bits, and the result of an
SHA processing has a size of 160 bits.
Based on that the size of M that is passed to SHA for processing will be as
follow.
416 + 0 + 24 + 32 = 472 bits
160 + 0 + 24 + 32 = 216 bits
Then as j increments the size of M will increment with a byte length up to 408
bits.
That means that after padding only for the M = 472 bits will have two blocks of
512 bits, and for the M =
216 408 bits will have just one block of 512 bits.
Is may understanding correct or I am missing something, because I really have the
feeling that I missed something.
Again, thank you very much for any advice.
Marius Corbu.
NSPW 2001 CFP
--- begin forwarded text From: [EMAIL PROTECTED] Subject: NSPW 2001 CFP To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Mon, 15 Jan 2001 18:21:48 -0500 Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Call For Papers New Security Paradigms Workshop 2001 An ACM/SIGSAC sponsored workshop 11 - 13 September 2001 Cloudcroft, New Mexico, USA http://www.nspw.org 2001 is the tenth anniversary of the New Security Paradigms Workshop (NSPW), which has provided a productive and highly interactive forum for innovative new approaches to computer security. The workshop offers a constructive environment where experienced researchers and practitioners work alongside newer participants in the field. The result is a unique opportunity to exchange ideas. NSPW 2001 will take place September 11 - 13, 2001 at the Cloudcroft Lodge, Cloudcroft, New Mexico, 20 miles from Alamogordo/White Sands. In order to preserve the small, focused nature of the workshop, participation is limited to authors of accepted papers and conference organizers. Because we expect new paradigms we accept wide-ranging topics in information security. Any paper that presents a significant shift in thinking about difficult security issues or builds on a previous shift is welcomed. NSPW is highly interactive in nature. Authors are encouraged to present ideas that might be considered risky in some other forum. All participants are charged with providing feedback in a constructive manner. The resulting brainstorming environment has proven to be an excellent medium for furthering the development of these ideas. Many authors have mentioned that they received more useful feedback and ideas than from any other conference. The proceedings, published after the workshop, have consistently benefited from the inclusion of workshop feedback. What makes a paper acceptable for NSPW? While we reject plenty of excellent papers that would do very well at other venues, our eclectic program committee particularly looks for new paradigms, innovative approaches to older problems, early thinking on new topics that are not necessarily fully polished, and controversial issues that might not make it into other conferences but deserve to have their try at shaking and breaking the mold. Conversely, a great paper that does not have a new paradigm, does not challenge the status quo, or does not critique an older paradigm will almost certainly get rejected. To participate, please submit your paper, justification, and attendance statement, preferably via e-mail, to both Program Chairs -- Brenda Timmerman [EMAIL PROTECTED] and Darrell Kienzle [EMAIL PROTECTED] -- by Friday, March 30, 2001 (hardcopy submissions must be received by Friday, March 23, 2001). Further details on the required format of submissions follow. 1 - Your Paper You should submit either a research paper, a 5 - 10 page position paper, or a discussion topic proposal. Submissions of any type must not have been published elsewhere. Discussion topic proposals should include an in-depth description of the topic to be discussed, a convincing argument that the topic will lead to a lively discussion, and any other supporting materials. Softcopy submissions should be in Postscript, PDF, Word/RTF or ASCII format. Papers may be submitted as hardcopy. To submit hardcopy, please mail 5 (five) copies to Program Co-chair Brenda Timmerman. Please allow adequate time for delivery. 2 - Justification You should describe, in one page or less, why your paper is appropriate for the New Security Paradigms Workshop. A good justification will describe the new paradigm being proposed, explain how it is a departure from existing theory or practice, and identify those aspects of the status quo it challenges or rejects. 3 - Attendance Statement You should state how many authors wish to attend the workshop. Accepted papers require the attendance of at least one author. In order to ensure that all papers receive equally strong feedback, all attendees are expected to stay for the entire duration of the workshop. The program committee will referee the papers and notify the authors of acceptance status by June 8, 2000. We expect to be able to offer a limited amount of financial aid to those who require it. More information will be provided on our web site http://www.nspw.org as it becomes available. Workshop General and Vice Chairs Steven J. Greenwald Cristina Serban Independent Consultant ATT Labs 2521 NE 135th Street 307 Middletown-Lincroft Rd. North Miami, FL 33181 USALincroft, NJ 07748 USA Email: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] Voice: +1 (305) 944-7842
early registration deadline for Financial Cryptography '01
--- begin forwarded text Resent-Date: Mon, 15 Jan 2001 21:40:34 -0400 Date: Tue, 16 Jan 2001 02:40:21 +0100 (MET) From: "R. Hirschfeld" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: early registration deadline for Financial Cryptography '01 Reply-to: [EMAIL PROTECTED] Resent-From: [EMAIL PROTECTED] Resent-Sender: [EMAIL PROTECTED] Just a reminder that the next few hours are the last chance to register for the FC01 conference for the early registration fee. After that the price will increase by $150. A preliminary program is available on the conference website, http://fc01.ai. --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The Shining Cryptographers Net
The Shining Cryptographers Net Here is a rough idea for a quantum-cryptography variant on the DC Net, the Dining Cryptographers Net invented by David Chaum. It does not provide as much anonymity as the DC Net, but perhaps will inspire others to look for a more powerful design. In a simple version of the DC Net, each pair of cryptographers initially shares a unique, secret random string (or perhaps they share a seed for a stream cipher). A token carrying a bit is passed around the net, and each cryptographer who has nothing to say XORs the bit with the XOR of the next bit of each of his random strings. After passing through all the cryptographers, each random bit has been XORed in twice (once for each of the two cryptographers who share the string holding that bit) and so the bit value has not changed in total. If a cryptographer wants to send a message, when he does his XOR he also XORs in the next bit of the message. At the end the value of the message bit will equal the bit which was sent (as long as two people don't try to talk at once). The source of the message is hidden as each party sees only random data arriving. For the quantum version, a photon is passed around the ring instead of a logical bit. These are thus dubbed the Shining Cryptographers. The photon starts off with vertical polarization. Each cryptographer manages a station through which the photon passes, which can be configured to either rotate the photon polarization 90 degrees, or to leave it alone. If the cryptographer has nothing to say he leaves the photon alone. If he wants to say something he uses the next bit of his message to determine whether to rotate the photon 90 degrees or not. At the end, the photon polarization is measured by attempting to pass it through a vertical polarizer. If it passes, the photon has not been rotated, while if it is absorbed, it was rotated. In this way the message bit is recovered. Anonymity derives from the inability of an attacker to measure the photon without destroying it, unless he can guess its state. The attacker can confirm a guess at the state, but as soon as he guesses wrong, the photon will be destroyed. This will allow the attacker's presence to be detected as soon as he makes a wrong guess. Unfortunately the attacker may be able to get lucky and acquire considerable information before he is detected. Here is a way to strengthen the anonymity. Let the photon go around the ring twice. Each cryptographer randomly chooses whether to rotate the photon or leave it alone. He does the same transformation both times, if he has nothing to say. These will then cancel out. However if he wishes to transmit a 1, he does a different transformation each time, so there is no canceling. In fact with this system, the cryptographers are not restricted to 90 degree rotations, but they can choose any pair of rotations which will add as required. The attacker now has to guess how much his target is going to rotate the beam and put probes before and after, and hope he guessed right. In itself this tells him nothing. He has to further guess whether the target will rotate by the same or different amount on the second pass, adjust his probes accordingly, and again hope for a correct guess. The same principle can be extended by letting the photon go around the ring multiple times. Players must arrange to rotate the photon by varying amounts which add to an even multiple of 90 degrees if they are not sending, or an odd multiple if they are sending a 1. By increasing the number of times through the loop, the chance of an attacker guessing right on every transformation can be reduced to a low level. Hal Finney
