Cryptography-Digest Digest #537
Cryptography-Digest Digest #537, Volume #14 Wed, 6 Jun 01 17:13:01 EDT Contents: Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen) Re: AES question (Tom McCune) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen) Re: AES question (Joseph Ashwood) Re: AES question (Mok-Kong Shen) Re: Def'n of bijection ([EMAIL PROTECTED]) Re: Def'n of bijection (Mok-Kong Shen) Re: Def'n of bijection ([EMAIL PROTECTED]) Re: And the FBI, too (Re: National Security Nightmare?) (Matthew Montchalin) Re: Def'n of bijection (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Def'n of bijection (John Myre) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Def'n of bijection ([EMAIL PROTECTED]) Re: Def'n of bijection (SCOTT19U.ZIP_GUY) Re: Best, Strongest Algorithm (gone from any reasonable topic) ([EMAIL PROTECTED]) Re: RSA's new Factoring Challenges: $200,000 prize. (my be repeat) (Michael Brown) From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) Date: Wed, 06 Jun 2001 20:25:50 +0200 Tim Tyler wrote: Mok-Kong Shen [EMAIL PROTECTED] wrote: : Tim Tyler wrote: : Mok-Kong Shen [EMAIL PROTECTED] wrote: : : You probably question whether such usage leads to : : Shannon's perfect security which, as you said, is claimed : : to be a property of OTP. However, I don't see where in the : : literature about OTP (in connection with perfect security) : : the length enters into the argumentation, i.e. plays a role : : in the proof. : : I also think that it's not mentioned. I beleive it is common to : consider the domain where all plaintexts are the same length - : perhaps in order to get the perfect secrecy result. : : : My memory of Shannon's paper is no good, but I don't think that he : : considered the length of the messages. : : I don't think it was mentioned either - all the messages were the same : length in the system in question. : From what you said, I don't think it is valid to consider : that the constant length of messages underlies the : proof of Shannon (unless one can demonstrate the : contrary). Without such an assumption, there's no proof of perfect secrecy, because the system doesn't exhibit it. My admittedly now poor memory of Shannon's argument is roughly the following: Given a message of n bits. If it is xored with a perfect random source, then each of the possible 2^n sequences could result as ciphertext. Hence the a-posteriori probabability of (the content) of the message is the same as its a-priori probability. Now this is general for 'any' n. It certainly has no implication to the effact that, after sending a message of a certain length, the next following message should have the same n. Otherwise, given an OTP sequnce of m bits (m can usually be very large), one could have asked the question of which size (particular, fixed, constant n) of messages one is allowed to send with that resource in order that the perfect security according to Shannon could be achieved, in issue which seems to be apparently absurd. M. K. Shen -- From: Tom McCune [EMAIL PROTECTED] Subject: Re: AES question Date: Wed, 06 Jun 2001 18:36:39 GMT In article 3b1e561c$[EMAIL PROTECTED], ajd [EMAIL PROTECTED] wrote: Hi All, I was wandering about the algorithms that were nominated for the Advanced Encryption Standard, it seems obvious that Rijndael will be used a lot as it is the replacement for 3DES, but what about the other finalists. Does anyone know of any companies using TwoFish, RC6, Mars, or Serpent in products. Would they be used in addition to or instead of the older algorithms like IDEA, RC4, RC5 etc. The current PGP versions (7.0.1 and above) include AES and Twofish (both 256 bit), and also retain usage of IDEA, CAST5, and Triple DES. Tom McCune My PGP Page FAQ: http://www.McCune.cc -- From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) Date: Wed, 06 Jun 2001 20:37:54 +0200 Tim Tyler wrote: Tim Tyler [EMAIL PROTECTED] wrote: : Mok-Kong Shen [EMAIL PROTECTED] wrote: : : From what you said, I don't think it is valid to consider : : that the constant length of messages underlies the : : proof of Shannon (unless one can demonstrate the : : contrary). : Without such an assumption, there's no proof of perfect secrecy, : because the system doesn't exhibit it. I looked up what Bruce Schneier has to say about perfect secrecy in A.C. He
Cryptography-Digest Digest #537
Cryptography-Digest Digest #537, Volume #13 Wed, 24 Jan 01 02:13:00 EST Contents: Re: Fitting Dynamic Transposition into a Binary World (Kenneth Almquist) Re: TSEPRNG, a secure RNG ? (Bryan Mongeau) Re: Dynamic Transposition Revisited (long) (Terry Ritter) Re: Dynamic Transposition Revisited (long) (Terry Ritter) Re: Dynamic Transposition Revisited (long) (Terry Ritter) Re: Dynamic Transposition Revisited (long) (Terry Ritter) From: [EMAIL PROTECTED] (Kenneth Almquist) Subject: Re: Fitting Dynamic Transposition into a Binary World Date: 24 Jan 2001 05:41:18 GMT [EMAIL PROTECTED] (John Savard) wrote: 2^160 equals 1461501637330902918203684832716283019655932542976 and the number of 164-bit balanced strings is 1454706556296192477283016662986999417820887445240 so one way to use Dynamic Transposition on arbitrary binary sequences would be to have a coding for 160-bit arbitrary sequences into 164-bit balanced sequences. Some sequences of 160 bits wouldn't have an equivalent, and so would have to be converted to something else; either to shorter balanced sequences, which could also be enciphered by Dynamic Transposition, or to some other kind of object to be enciphered in another way. This means that your encoding is effectively variable length. For each 160-bit sequence, you need to transmit an indication of whether it has been encoded as a 164-bit balanced sequence, or some other way. This wastes communication bandwidth (though not a lot) and also complicates the encoding because the indication cannot be transmitted in the clear (or you leak information). Might I suggest coding 158-bit arbitrary sequences as 162-bit balanced sequences? There number of 162-bit balanced sequences is 365907784099042279561985786395502921046971688680 while 2^158 is slightly less: 365375409332725729550921208179070754913983135744 This would create a fixed overhead of four additional bits for every 158-bit block, which would add a communication overhead of about 2.53%. If you decided to use a block size of 128 bits (in order to interface to standard 32 and 64 bit hardware more easily), adding four bits per block amounts to a communication overhead of 3.125%, which is still quite reasonable. Of course, this kind of begs the question of how to devise an efficient coding for arbitrary strings into balanced strings. From arbitrary binary strings, one could use a simple numeration of balanced strings... = 01 0001 = 10 0010 = 110111 0011 = 111011 ... 1011 = 10 1100 ... coded to something else and maybe there *might* be a simple algorithm to do this for strings too large to put in a table Finding an algorithm to do this is an interesting challenge. The arbitrary strings can be regarded as binary numbers. We define a mapping between balanced strings and numbers by listing the balanced strings in lexical order and numbering them starting from zero, as you have done above. The first thing to note is that we can compute the number of balanced strings with a given prefix relatively efficiently. For example, let's say that our balanced strings are 162 bits long, meaning they contain 81 "1" bits and 81 "0" bits. If we want to know how many strings have the prefix "110", we count the number of zeros and ones in the prefix. There are two "1" bits and one "0" bits. This means that the remainder of the string must have 79 "1" bits and 80 "0" bits. The number of possibilities is (79+80)! / (79! * 80!). This allows us to process a balanced string from left to right, keeping track of the number of the first (or last) balanced string beginning with the bits we have seen so far. This minimum starts out as zero. As we scan the string, if the next bit is zero, then the minimum is unchanged. If we encounter a one, then we know that all the balanced strings which have a zero where the string we are scanning has a one must lexically precede the string we are scanning. Therefore, we add the number of such strings to the minimum. To compute the number of a balanced string, we perform the operation described in the preceding paragraph, counting the number of "0" and "1" bits as we go along. When we have seen 81 of either type of bit, then there is only one possible value for the remaining bits. (They must be all zeros or all ones.) At that point there is only one balanced string beginning with the bits we have seen so far, and we know what the number of that balanced string is, so we are done. To generate the balanced string corresponding to a number, we modify the algorithm to generate bits rather than reading them. At each step, we first try outputting a "1" bit. If that would make the minimum exceed the number whose bit string we are trying to
Cryptography-Digest Digest #537
Cryptography-Digest Digest #537, Volume #12 Fri, 25 Aug 00 17:13:01 EDT
Contents:
Re: Bytes, octets, chars, and characters (Steve Summit)
Re: Bytes, octets, chars, and characters (Steve Summit)
Re: "Warn when encrypting to keys with an ADK" (commodore at gci-net dot com)
Re: "Warn when encrypting to keys with an ADK" (commodore at gci-net dot com)
Re: 1-time pad is not secure... ("Douglas A. Gwyn")
Re: SHA-1 program, wrongo ! (S. T. L.)
Re: SHA-1 program (cool!) (S. T. L.)
Re: My unprovability madness. ("Bob May")
Re: Steganography question (zapzing)
Re: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Offical word from PRZ on ADK issue ("Kurt Mueller")
Re: DES: Say it or spell it? (Newbie question) (Jim Reeds)
Re: SHA-1 program (cool!) (S. T. L.)
Re: Bytes, octets, chars, and characters (Kevin D. Quitt)
Re: My unprovability madness. ("Douglas A. Gwyn")
Re: 1-time pad is not secure... ("Tony T. Warnock")
Re: Questions about stream cipher ([EMAIL PROTECTED])
Re: PROMIS-software for worldwide spy network by US/Isreal (Mok-Kong Shen)
Re: UNIX Passwords (Eric Lee Green)
From: [EMAIL PROTECTED] (Steve Summit)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 19:11:07 GMT
In article 8o5c1t$1jk$[EMAIL PROTECTED],
[EMAIL PROTECTED] writes:
The most common 64 bit solution appears to be:
char 8-bit
short 16-bit
int 32-bit
long64-bit
And a dandy solution it is, too. Four different types,
four different sizes. Just the way it should be.
Steve Summit
[EMAIL PROTECTED]
--
Programming Challenge #6: Don't just fix the bug.
See http://www.eskimo.com/~scs/challenge/.
--
From: [EMAIL PROTECTED] (Steve Summit)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 19:18:31 GMT
Benjamin Goldberg evidently wrote:
It's too bad that integers weren't initially called int8, int16, etc...
No, it isn't.
Steve Summit
[EMAIL PROTECTED]
--
Programming Challenge #6: Don't just fix the bug.
See http://www.eskimo.com/~scs/challenge/.
--
From: commodore at gci-net dot com
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 19:27:43 GMT
Reply-To: commodore at gci-net dot com
In 8o5n05$kiv$[EMAIL PROTECTED] S.R. Heller wrote:
-BEGIN PGP SIGNED MESSAGE-
What the option means is, "If I encrypt to a public
key with an ARR, and then try to remove the ADK from the recipient's
list [i.e., from the lower pane in the select recipients dialog],
warn me that this might be 'violating the policy' established for the
key with the ARR." That's a mouthful, but you can test it yourself to
see what I mean.
Is there a function in the PGP SDK to detect and return the value of
an ARR on a key?
I couldn't seem to locate anything appropriate in the doc set.
Thanks.
--
From: commodore at gci-net dot com
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 19:45:21 GMT
Reply-To: commodore at gci-net dot com
In [EMAIL PROTECTED] commodore at gci-net dot com wrote:
In 8o5n05$kiv$[EMAIL PROTECTED] S.R. Heller wrote:
-BEGIN PGP SIGNED MESSAGE-
What the option means is, "If I encrypt to a public
key with an ARR, and then try to remove the ADK from the recipient's
list [i.e., from the lower pane in the select recipients dialog],
warn me that this might be 'violating the policy' established for the
key with the ARR." That's a mouthful, but you can test it yourself to
see what I mean.
Is there a function in the PGP SDK to detect and return the value of
an ARR on a key?
I couldn't seem to locate anything appropriate in the doc set.
Thanks.
Following up to my own post, a more careful examination of the docs
show a function named PGPCountAdditionalRecipientRequests() that
seems to do what I want.
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: 1-time pad is not secure...
Date: Fri, 25 Aug 2000 18:52:33 GMT
"Tony T. Warnock" wrote:
It's more like using a colorless jawbreakers, opening one bag, if it's red, the
other is blue, if the first one is blue, the other is red. The experiment may be
repeated, half the time one gets red-blue, the other half blue-red.
Well, one doesn't know what color until the observation is made,
but it's always red or blue when observed, so "
Cryptography-Digest Digest #537
Cryptography-Digest Digest #537, Volume #10 Wed, 10 Nov 99 07:13:04 EST
Contents:
Re: Bracking RSA Encryption. Is it possible. (Tom St Denis)
Re: NOVA Program (Sundial Services)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Passwords - the weak link ([EMAIL PROTECTED])
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Encryption Placement ("Lassi Hippeläinen")
Re: Signals From Intelligent Space Aliens? Forget About It. (Gurripato)
S/MIME plug-in for Eudora? Strong Encryption (SkinD)
multiple valid passphrases? ("Craig Inglis")
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Bracking RSA Encryption. Is it possible.
Date: Wed, 10 Nov 1999 05:49:33 GMT
In article 8080ps$10f$[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
I have a big problem. I have a lap top sniffer on a small unix LAN and
have managed to read packages. The packages are in RSA Encryption. I
have timed the time it takes to encrypted the e mials. To try to get
an
idea as what the private key is . Brute force attacks on the code off
line are impossible to brake. Have come to the conclusion that RSA
encryption is unbrakable and it is a waiste of time using sniffer as I
cannot brake encryption. Putting the crimminality of it asside the
question is can RSA code be broken. I do not think it can and is good
security against sniffer attacks.
KM jr what you think.
First, like the egg, you can break it by hand if you hold it properly.
[my cool saying I just thought of, and I am proud of it.]
Second, his name is Kevin Mitnick not Kelvin.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
Date: Tue, 09 Nov 1999 23:08:16 -0700
From: Sundial Services [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: NOVA Program
Certainly a nicely produced program, lavishly produced in fact. It was
quite a nice touch how they had actors precisely re-creating the motions
leading up to the historical photographs. (The fact that so many of the
scenes were intentionally blurred and sepia-toned got a bit tedious
after a while.)
It is interesting to see how the later stories of the Bletchley Park
saga are bringing out more and more of the human side, both British and
German, of what it was like to be there. The story of the blood-stained
intercept was absolutely stunning in its bluntness.
It was exceptionally interesting to see the interview with the radioman
of the U-150. They seemed to want to be sure you understood, and HE
certainly wanted you to understand, that he did not abandon his duty
when ordered by his captain to "abandon the papers and get out." As
usual, the story of German codebreaking (B-Dienst) still remains untold.
All in all, it's a very nice addition to the library of videography on
the subject. The people involved in producing it (and the web-site as
well) should be justifiably proud of their work.
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
Got Paradox/Delphi database headaches? ChimneySweep{tm} can help, FAST!
http://www.sundialservices.com/cs3web.htm
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Can the SETI@home client be protected?
Date: 09 Nov 1999 23:04:45 PST
In article 809rli$ogv$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
In article 809h4h$[EMAIL PROTECTED],
Guy Macon [EMAIL PROTECTED] wrote:
High stats cheater protection is already in place. The SETI@home team
takes any result that in any way looks odd and sends it to several
other participants in different parts of the world. In addition,
right now each work unit is sent out and processed an average of 2.8
times. This is because the horde of PCs are processing data faster
than the Arecibo radiotelescope can generate it.
Sounds like you're in a great position to detect cheaters, then.
Randomized cross-checking is a powerful technique.
Why don't you track reputation using long-term client identities?
New clients should be considered relatively untrusted; but if a client
has built up a good name over time and shown itself to consistently
answer correctly, you start trusting it more.
Inject a small percentage of fake positives into the data you send
out to new clients, and also send the same data to a randomly-chosen
trusted client or three (and possibly to your own, known-good local
implementations). If the new client's answer differs from the trusted
client's answers, trash the new guy. If the new guy consistently
detects the fake positives, you can upgrade his reputation over time.
The better the reputation of the client is, t
Cryptography-Digest Digest #537
Cryptography-Digest Digest #537, Volume #9 Wed, 12 May 99 17:13:03 EDT Contents: Re: Time stamping (complete) (Helger Lipmaa) a source for random number generation (Patricia Gibbons) Re: [Q] Are all encryption algorithms based on primes? (DJohn37050) Re: Random permutation ([EMAIL PROTECTED]) Re: Crypto export limits ruled unconstitutional (Jerry Coffin) Re: [Q] Are all encryption algorithms based on primes? (Jerry Coffin) Re: Newbie: Encrypting short strings (Matthias Bruestle) Re: True Randomness The Law Of Large Numbers ([EMAIL PROTECTED]) Layered Design (John Savard) Re: Crypto export limits ruled unconstitutional ([EMAIL PROTECTED]) Re: Crypto export limits ruled unconstitutional (Serge Paccalin) An apology to Tom St. Denis; also, Terry Ritter is not very bright ([EMAIL PROTECTED]) DES analysis paper (Jayant Shukla) From: [EMAIL PROTECTED] (Helger Lipmaa) Subject: Re: Time stamping (complete) Date: 12 May 1999 19:16:47 GMT Jean Marc Dieu ([EMAIL PROTECTED]) wrote: : Of course you need a third trusted party, whose clock is the one that will : time stamp your document. My question in fact was: can you simoutaneously : time-stamp AND sign a document through a one-way hash function, using a TTP? : Have a look at http://www.surety.com The problem of connecting a digital document with an absolute time of its creation is unsolvable by several reasons (starting from physics). All you can do is to get some relative stamping, where any issued time certificate is provably one-way dependent (in one or in the other direction) with every other certificates. Haber Stornetta pioneered this work, and it has been continued by several working groups, including ours. (I guess this was more an answe to another guy) For more you probably have to reword your question... like what do you mean by time-stamping AND signing? and have a look at http://home.cyber.ee/helger/crypto/link/timestamp.html Helger http://home.cyber.ee/helger : At 18:33 10/05/99 -0500, you wrote: : You could sign the document with a date stamp, humm..but then a problem I : want to know. : : Where can you get such a time stamp? I mean, looking at your computer and : it says 6:17pm then signing the message, how does the receiver KNOW it was : signed at 6:17pm? Are there any time stamp authorities? -- From: Patricia Gibbons [EMAIL PROTECTED] Crossposted-To: alt.security.pgp Subject: a source for random number generation Date: Wed, 12 May 1999 13:16:17 -0700 Reply-To: [EMAIL PROTECTED] I've found some info on random number generation at "Aware Electronics" website, and thought this may be of interest to readers. This is a radiation-decay method that outputs either hex or ascii random text to a filename or to a printer: http://www.aw-el.com/random.htm -- Patricia E. Gibbons Acting Chief Communications Technician City of San Jose - ITD/communications ... My Public Key is available at: http://pgp5.ai.mit.edu/pks-commands.html Key ID: 0xEDECB44F This key is RSA, NOT Diffie-Hellman !! -- From: [EMAIL PROTECTED] (DJohn37050) Subject: Re: [Q] Are all encryption algorithms based on primes? Date: 12 May 1999 19:50:47 GMT ANSI X9.63 draft contains ECAES (Elliptic Curve Augmented Encryption Scheme), based on work of Bellare-Rogaway and which is not based on the difficulty of factoring, but rather based on the ECDLP. This is a variant of ElGamal encryption. Don Johnson -- Date: Wed, 12 May 1999 16:32:11 -0400 From: [EMAIL PROTECTED] Subject: Re: Random permutation Bryan Olson wrote: This isn't going to be threaded in the right place. My internet provide doesn't get all the posts, and Dejanews hasn't worked since they revised it a few days ago. [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: If efficient means we want to use the fewest calls to our random number generator, use the same idea as we used to generated a uniform choice in [0..n) given a uniform and independent bit source. Suppose rand16() returns a random choice from [0..15]. endRange = 1 randInRange = 0 while true while endRange 16! endRange = endRange * 16 randInRange = randInRange * 16 + rand16() if randInRange 16! return randInRange else endRange = endRange - 16! randInRange = randInRange - 16! This returns a uniform choice from [0, 16!-1], which we cam map one-to-one to the possible permuations. It's optimal in the expected number of calls to rand16(). I question the characterization of this approach as efficient. It requires use of numbers well over 32-bits in length due to the computation of 16 factorial. True, but be fair. I stated exact
