Cryptography-Digest Digest #815, Volume #13 Tue, 6 Mar 01 05:13:00 EST
Contents:
Thank You Everyone! ([EMAIL PROTECTED])
Re: Monty Hall problem (was Re: philosophical question?) (Shawn Willden)
Re: One-time Pad really unbreakable? (John Savard)
What is SRT ? ("Marc")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?) (Paul
Crowley)
Re: How good is the KeeLoq algorithm? (Paul Crowley)
Re: Thank You Everyone! (Paul Rubin)
Re: How good is the KeeLoq algorithm? ("r.e.s.")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: passphrase question (Harri Haanpaa)
Re: One-time Pad really unbreakable? ("Mxsmanic")
Re: Crypto security of pseudo-random sequences (Mok-Kong Shen)
Re: Super strong crypto ("Bryan Olson")
Re: How good is the KeeLoq algorithm? ("Jakob Jonsson")
On encryption through bit permutations (Mok-Kong Shen)
Re: What is SRT ? (Malte Borcherding)
Re: What is SRT ? (Malte Borcherding)
Re: Monty Hall problem (was Re: philosophical question?) (Joe H. Acker)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Thank You Everyone!
Date: Tue, 06 Mar 2001 04:57:14 GMT
Hello Everyone,
I just wanted to thank everyone who posts here. Being a complete
newby to this type of work, I'm learning something daily from all your
posts. I was injured at work (I was an Emergency Medical Technician)
and because of it, have had to realign my work type. I'd rather use
brains instead of brawn anyday! But, once again I thank everyone for
their support for us newbys out here and those of us just learning the
basics.
Thanks Again,
George
P.S. Feel free to e-mail me with any suggestions or comments. All
are welcome.
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Date: Mon, 5 Mar 2001 22:15:31 -0700
Benjamin Goldberg wrote:
> Shawn Willden wrote:
> [snip]
> > int carPos = r.nextInt(3);
> > int choice = r.nextInt(3);
>
> I'm not going to comment on anything else, but nextInt(3) returns 3
> random bits, or a number in the range 0..7. To get an unbiased int in
> the range 0..2, you have to write your own ranmod type function.
No, you're thinking of Random.next(int bits). Random.nextInt(int n)
"Returns a pseudorandom, uniformly distributed int value between 0
(inclusive) and the specified value (exclusive), drawn from this random
number generator's sequence."
Check out:
http://java.sun.com/j2se/1.3/docs/api/java/util/Random.html#next(int)
and
http://java.sun.com/j2se/1.3/docs/api/java/util/Random.html#nextInt(int)
for further details.
Shawn.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 06 Mar 2001 05:19:00 GMT
On Tue, 06 Mar 2001 03:13:40 GMT, [EMAIL PROTECTED] (Steven Smolinski)
wrote, in part:
>If you can break a one-time pad if you get two ciphertexts made with the
>same key, why can't you divide one ciphertext in half and apply the same
>analysis?
Well, the one time pad uses a key as long as the ciphertext. So no
part of that key is used twice. Since the whole key is random, the
second half of that key has no relationship to the first half of the
key.
If you use the same key on two ciphertexts, that means the part of
that key corresponding to the shorter of the two messages is used
twice.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Marc" <[EMAIL PROTECTED]>
Crossposted-To: alt.computer.security,comp.security
Subject: What is SRT ?
Date: Tue, 6 Mar 2001 19:18:52 +1300
Hi,
I'm researching a E-commerce package which says it uses SRT to secure the
web browser
connection to the server.
I have found that SRT appears to be a Java implementation of SSL, to enable
128bit encryption outside of US. Also optimised to E Banking.
What I'm trying to find out is who did it, and has it been reviewed by the
wider
internet community. Other attempts to "optimise" SSL have resulted in it's
being
broken.
Anyone know about this product!
Thanks
Marc
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 06 Mar 2001 06:33:16 GMT
David Wagner wrote:
> If lack of known attacks is our criteria, we don't need new systems.
No, you missed the point. There is *no* possible attack against
the phase 3 straw man in the classes noted, which include those
that are usually the most promising avenues for cryptanalysis.
The space of all possible cryptanalytic attacks (under the standard
scenario as previously described) can conceptually be covered
by a handful of such general classes, and if evolution of the
design eventually blocks every one of those classes, then that
would reach the ultimate goal (i.e., a practical system immune to
*unknown* specific cryptanalytic attacks). I've addressed the
historically most important classes first. The next class would
be just about the last needed to complete the story; it involves
chaining of the shared information between adjacent blocks
(portion of PT of one block used in key in next block, also same
"IV" mask in each block) in conjunction with known unmasked PT
(all-0 is an acceptable assumption) to uncover some of the shared
information. A detailed method for that would depend on the
specific block cipher (the only requirement so far is that that
cipher mixes well). This is where one really needs a good theory
of the way that system structure interacts with information, in
particular how to compute a lower bound on the expected work factor
for the solution of such a problem. (The case for unknown unmasked
PT would be harder, involving information statistics.) Looking
just at the "information content" without consideration of how
much work is required to extract the information is a waste of
time (unless it shows extraction to be impossible, which is not
the case here). Is there a well-developed theory into which we
could plug the problem parameters and turn the crank to get the
lower bound? (I'm not aware that any have been published.)
> ... What is our criteria for success, and how do we gain
> confidence that the new proposal is any better than existing
> techniques? In the absence of any _proof_ of security (which
> we do not at present have), this seems to be the part that has
> to be justified quite carefully.
One could concoct proofs of the specific security claims I have
made so far; I'm not doing that here because once I see that the
requisite property is in fact attained, I'm more interested in
working on the next phase than in filling in academic details.
I've indicated above what the most important remaining question
is for assessing the "super strength" of the straw-man design;
an investigation of that might discover another class of
vulnerability and suggest a way to deal with it, which would
pretty much conclude the structural design.
------------------------------
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 06:32:33 GMT
Vince Adams <[EMAIL PROTECTED]> writes:
> How do you say it in the UK? Go bugger yourself wanker <g>.
Use of British insults is a more subtle art than it might seem and
should not be attempted by the uninitiated. You big pillock.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: How good is the KeeLoq algorithm?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 06:32:33 GMT
"Simon Johnson" <[EMAIL PROTECTED]> writes:
> > Why can't they use a standard algorithm such as DES or RC4 ???
> > Sounds like the russian car mafia should have a look at that :-))
>
> RC4 is not an official standard as far as I am aware.
There's an RFC that describes it, under the name "ARCFOUR".
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Thank You Everyone!
Date: 05 Mar 2001 22:47:17 -0800
[EMAIL PROTECTED] writes:
> I just wanted to thank everyone who posts here. Being a complete
> newby to this type of work, I'm learning something daily from all your
> posts.
Me too. Thanks to Anthony Szopa, Dave Scott, and Monty Hall, I've
learned to use a kill file. Thanks guys!
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: How good is the KeeLoq algorithm?
Date: Mon, 5 Mar 2001 23:21:40 -0800
"Paul Crowley" wrote ...
| "Simon Johnson" writes:
| > RC4 is not an official standard as far as I am aware.
|
| There's an RFC that describes it, under the name "ARCFOUR".
Where can that be found?
(Web searches came up empty.)
--r.e.s.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 06 Mar 2001 08:34:14 GMT
"Frodo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The same number as your "local cops always
> getting into trouble".
How often is that?
> Sorry, that's a secret.
Then how would you know about it?
------------------------------
From: Harri Haanpaa <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: passphrase question
Date: 06 Mar 2001 10:57:12 +0200
Anonymous <[EMAIL PROTECTED]> writes:
> I was thinking about using a decryption passphrase for software like PGP
> and the like that would consist of a very long string of characters like:
>
> ......aaaaaaaaaa$$$$$$$$$$$fffffffffffDDDDDDD5555
After having thought about how to create a passphrase, I decided to
settle for random characters. After all, a passphrase shouldn't be
very long, or it will take a long time to type.
Also I decided against using special characters or capital
letters. The location of special characters may vary, and some special
characters and all capital letters take at least two keypresses, which
is inefficient.
That left me with the English alphabet, a..z and the numbers 0..9.
Conveniently, that is a total of 36 characters, easily generated by
dice (since obviously I wouldn't want to trust a pseudo-random number
generator).
Just create as many characters as you want by rolling two dice.
First die
1 2 3 4 5 6
2 1: a b c d e f
n 2: g h i j k l
d 3: m n o p q r
4: s t u v w x
d 5: y z 0 1 2 3
i 6: 4 5 6 7 8 9
e
In this way, each characters gives a bit more than 5 bits of
entropy. So to get, say, 75 bits of security, you could create 15 random
characters. Then, of course, you must memorize them. But even that isn't
as hard as you might think. Take, for example, the sequence I just generated:
3 9 4 i s 0 p 0 q w t f 1 6 x 2
Don't try to memorize that as a string of characters, but try to make some
sense of it. How about this:
394 is zero p, zero q. What the f..??? sixteen times two.
or
h d 4 1 c m l 9 f j 0 x r 1 8 y
which could be "Harley-Davidson, 41 centimeters".. hm, right now I
can't think of anything for the "l 9 f j 0" part, but the "x r 18 y"
could be "X-rated, 18 years". I don't think you have to invent the
short cut right away; it'll come to you as you use the passphrase a
bit.
Comparison with Diceware: the passphrases generated with this method
are shorter. From 10 rolls of a die, Diceware generates two English
words, but this method generates only 5 random characters. So they are
faster to type in. Of course, the passphrases generated with Diceware
may be easier to remember, since they consist of real English words;
however, they are also longer, so there is more to memorize.
I can't take credit for inventing this method, but I don't remember
where I saw it. Somewhere on the WWW, I presume.
Harri H.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 06 Mar 2001 09:16:53 GMT
"Steven Smolinski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> If you can break a one-time pad if you get two
> ciphertexts made with the same key, why can't
> you divide one ciphertext in half and apply the same
> analysis?
What analysis do you have in mind that would be applicable to both
situations?
One-time pads are indeed unbreakable, and provably so. The only
conditions are that the key be kept secret, that it be at least as long
as the plaintext, that it only be used once, and that it be totally
random.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crypto security of pseudo-random sequences
Date: Tue, 06 Mar 2001 10:17:43 +0100
Simon Johnson wrote:
>
[snip]
> > (3) Using groups of n bits (e.g. n=24) to index the binary
> > digits of Pi.
>
> No, Pi is a well known determistic sequence and this would simply act as a
> monoalphabetic substitution. The attack against the good prng would still
> work with only minor change.
It is not a monoalphabetic substitution but the inverse
of a homophonic substitution, i.e. n bits to 1 bit. In
general, analysis of a PRNG depends on having groups of
bits (each group being part of a single output) that stem
from consecutive outputs of the PRNG, as far as I am aware.
Here, the chance of getting from the one bit obtained from
Pi correctly to any bits of the PRNG that was used to index
it very rapidly decreases with n. So I don't yet see a
promising practical way of prediction with n sufficiently
large.
M. K. Shen
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Super strong crypto
Date: Tue, 06 Mar 2001 09:32:37 GMT
Douglas A. Gwyn wrote:
>Bryan Olson wrote:
>> ... One result I stated, and can show, is that the key
>> changes do not extend the amount of plaintext we can
>> send with information theoretic security.
>
>Sure, if you're using an unrealistic theory in which there is no
>cost of computation.
Do you forget who chose to base this on information theory?
Wagner:
| | Also, what is the relevance of unicity distance?
Gwyn:
| This thread was apparently about provably strong encryption,
| which forces an information-theoretic approach.
I suggested information theory was _not_ the approach you
were taking, but you disagreed:
Olson:
: : You [do]
: : not have information theoretic security, and don't seem to
: : be taking that approach, or even seeking to demonstrate
: : security.
: I've been proposing a *line of thought* via straw-man
: designs in several phases, that is consistent with such
: an approach.
>I've been ignoring those responses since
>I'm not interested in impracticalities, just security in real
>systems. If you can show that the sucessive phases of my straw-
>man design fail to address the real-world threats that I claimed
>for them, that would be useful.
And I'm not interested in yet another scheme conjectured to
be computationally secure and neither proven nor disproven.
I got interested because you said this was about provable
security, and you suggested information theory in
particular. Here's the result we can prove: the schemes in
your line of thought are _not_ information theoretically
secure. I cannot tell for sure what you meant or in what
you are interested, but in response to what you wrote, that
result is the answer.
You also mentioned you had another criterion for provable
security. If you would precisely state it, then maybe we
could tell if it's useful in demonstrating security.
--Bryan
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: How good is the KeeLoq algorithm?
Date: Tue, 6 Mar 2001 10:49:06 +0100
"r.e.s." <[EMAIL PROTECTED]> wrote in message
news:98233i$mnm$[EMAIL PROTECTED]...
>
> "Paul Crowley" wrote ...
> | "Simon Johnson" writes:
> | > RC4 is not an official standard as far as I am aware.
> |
> | There's an RFC that describes it, under the name "ARCFOUR".
>
> Where can that be found?
> (Web searches came up empty.)
Search for
ARCFOUR Thayer Kaukonen
at Google or Altavista and you may be lucky to find any of the expired
drafts (draft-kaukonen-cipher-arcfour-XX.txt). Yet, "ARCFOUR Algorithm" was
never published as an RFC (if you don't believe me, check for yourself at
ftp://ftp.isi.edu/in-notes/rfc-index.txt or
http://www.faqs.org/rfcs/index.html).
Jakob
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On encryption through bit permutations
Date: Tue, 06 Mar 2001 10:49:18 +0100
Permutations (transpositions) are nowadays commonly performed
with the aid of PRNGs on units of 8-bit bytes or 4-bit hex
digits for reasons of processing efficiency. A more thorough,
though more costly, diffusion can, however, evidently be
obtained through permutations at the bit level. An encryption
scheme that is based on bit permutations has recently been
designed by Terry Ritter, where the stream of plaintext bits
is first examined to generate (through appropriately
introducing additional bits) blocks such that in each of them
the total number of 0-bits is equal to that of 1-bits. The
bits in each such blocks are then subject to a pseudo-random
permutation.
This idea of bit balancing of plaintext, while favourable in
respect of security, has however the disadvantage of leading
to a ciphertext that is longer and of a (variable) length
dependent on the bit distribution of the plaintext, besides
being somewhat complicated in implementation due to the
bit balancing operations. This would, in particular, render
working with additional encryption operations that need a
constant block size difficult.
The following variation, which is also based on bit
permutations and bit-balancing, doesn't lead to a longer
ciphertext, though involves the trade-off of requiring two
bit permutations instead of one, i.e. more computing work.
Suppose we process blocks of n bits (n assumed to be even).
For each plaintext block P to be encrypted, first use the
PRNG to generate a bit-balanced pseudo-random block B.
Then we perform a pseudo-random permutation on P and a
pseudo-random permuation on B and then xor the two to result
in the ciphertext block C.
As pointed out by Terry Ritter in his proposal, each of the
above two pseudo-random permutations may be done twice in
order to more effectively prevent any predictability of the
output of the PRNGs used from being exploited by the
opponent. We mention that, due to the fact that the values
output from the PRNG are only indirectly 'present' in the
result of a permutation, it is hard for the opponent to
start from the result of the permutations to reach useful
informations about the outputs of the PRNG for prediction
purposes. Since B is balanced, the arguments advanced by
Terry Ritter on bit balancing in his proposal concerning
the security apply also to the present scheme. Note also
that for permuting P and B and for doing the double
permutations separate (independent) PRNGs may be employed.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Malte Borcherding <[EMAIL PROTECTED]>
Crossposted-To: alt.computer.security,comp.security
Subject: Re: What is SRT ?
Date: Tue, 06 Mar 2001 10:53:09 +0100
Marc wrote:
> I'm researching a E-commerce package which says it uses SRT to secure
> the web browser connection to the server.
>
> I have found that SRT appears to be a Java implementation of SSL,
> to enable 128bit encryption outside of US. Also optimised to
> E Banking.
>
> What I'm trying to find out is who did it, and has it been reviewed
> by the wider internet community. Other attempts to "optimise" SSL
> have resulted in it's being broken.
>
> Anyone know about this product!
SRT is an implementation by Brokat Technologies (dated back from 1996)
that was essentially SSL plus an additional connection id in the
transmitted messages. The connection id is used to identify messages
related to a particular connection, thus making the communication
independent of any underlying transport protocol mechanism (such as TCP
sockets). Also, SRT suppots only a subset of the full SSL functionality
(no client authentication, no compression, but only strong cipher
suites). Otherwise, ot is identical to SSL. The implementation is still
used in many Java-based banking applications, although it is no longer
offered in current Brokat products.
You can contact me directly if you need any further information.
Malte
--
===============================================================
Malte Borcherding Technical Research Manager
Brokat Technologies WWW: http://www.brokat.com
Germany email: [EMAIL PROTECTED]
------------------------------
From: Malte Borcherding <[EMAIL PROTECTED]>
Crossposted-To: alt.computer.security,comp.security
Subject: Re: What is SRT ?
Date: Tue, 06 Mar 2001 10:53:34 +0100
Marc wrote:
> I'm researching a E-commerce package which says it uses SRT to secure
> the web browser connection to the server.
>
> I have found that SRT appears to be a Java implementation of SSL,
> to enable 128bit encryption outside of US. Also optimised to
> E Banking.
>
> What I'm trying to find out is who did it, and has it been reviewed
> by the wider internet community. Other attempts to "optimise" SSL
> have resulted in it's being broken.
>
> Anyone know about this product!
SRT is an implementation by Brokat Technologies (dated back from 1996)
that was essentially SSL plus an additional connection id in the
transmitted messages. The connection id is used to identify messages
related to a particular connection, thus making the communication
independent of any underlying transport protocol mechanism (such as TCP
sockets). Also, SRT suppots only a subset of the full SSL functionality
(no client authentication, no compression, but only strong cipher
suites). Otherwise, ot is identical to SSL. The implementation is still
used in many Java-based banking applications, although it is no longer
offered in current Brokat products.
You can contact me directly if you need any further information.
Malte
--
===============================================================
Malte Borcherding Technical Research Manager
Brokat Technologies WWW: http://www.brokat.com
Germany email: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 6 Mar 2001 11:01:06 +0100
Mxsmanic <[EMAIL PROTECTED]> wrote:
> "Joe H. Acker" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Interestingly, this can be tested empirically. All
> > you need is a good TRNG based on radioactive-decay
> > and a function that takes input from the TRNG to
> > produce an unbiased random number in an integer range.
>
> I've done it, with a standard PRNG. The empirical results still say
> that you should switch doors; you double your chances of winning that
> way.
>
> > If I'm wrong, the first iterated run should create
> > a 33% and the second run a 66% winning rate.
>
> In my tests, it did.
>
> > Any volunters? (I don't have a TRNG...)
>
> It doesn't have to be a TRNG; a PRNG will do.
My tests are contradicting to your test. They give a 50:50 result.
Actually, I did not expect anyone to take this seriously, but as you
must have implemented the algorithm in a wrong way, here is an
inefficient implementation of Monty's algorithm in a dialect similar to
VisualBasic, whereas Random(i) returns a PRNG random number between 0
and i (inclusive):
Function MontyHall(iterations as Integer, alwaysSwitching as Boolean) As
Integer
Dim doors(2) as Integer
Dim choice, monty_choice, car_door,i, j, counter as Integer
CONST goat = 0
CONST car = 1
for j = 1 to iterations
// assign car randomly to one of the doors
car_door = Random(2)
doors(car_door) = car
// contestand picks out a door
choice = Random(2)
// Monty's algorithm
if doors(choice) = car then
// contestant has picked out the car door
// Monty picks out any of the two remaining doors
// deterministically, but could also be randomly chosen
monty_choice = choice + 1
if monty_choice > 2 then
monty_choice = 0
end if
else
// contestant has chosen a goat door
// Monty determines the remaining door that is not the car door
// the loop is indeed a stupid way to do this...
for i = 0 to 2
if i<>choice and i<>car_door then
monty_choice = i
exit // only one door can be the correct one, exit loop
end if
next
end if
// evaluate the result
if alwaysSwitching then
for i = 0 to 2
if i<>choice and i<>monty_choice then
choice = i
exit
end if
next
end if
if doors(choice)=car then
counter = counter + 1
end if
// reset
doors(car_door) = 0
next
return counter
End Function
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
