Cryptography-Digest Digest #553
Cryptography-Digest Digest #553, Volume #13 Fri, 26 Jan 01 03:13:00 EST
Contents:
Re: Durstenfeld Transpositions & ARC4 ("r.e.s.")
Re: What do you do with broken crypto hardware? (Nicol So)
Re: Durstenfeld Transpositions & ARC4 (David Wagner)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation (Anthony Stephen
Szopa)
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Thu, 25 Jan 2001 23:11:02 -0800
"Terry Ritter" wrote...
| "r.e.s." wrote:
| >In 1964 Durstenfeld published his well-known Shuffle algorithm
| >that generates a random N-permutation by means of successive
| >pairwise transpositions, which seems to be the "dynamic" part
| >of Terry Ritter's "Dynamic Transposition" cipher. Has there
| >been substantive improvement in such algorithms since 1964, or
| >does Durstenfeld's remain about as good as any?
|
| There exist other permutation techniques of similar age. Shuffle
| seems about as good as any, and is widely understood. For the
| state of the art up to 1991, see:
|
|http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect6.7
Thanks, I'll take a look.
| >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
|
| The ARC4 state is awfully small for Dynamic Transposition,
| especially
| if we shuffle twice. We want more active state in the RNG than is
| used in a single encryption, and probably do want at least 128 bits
| in
| the block. Since rejection in Shuffle (to achieve variable-range)
| throws away values (and may throw away a lot), probably it is not
| large enough.
I wasn't proposing to use Dynamic Transposition, but what you
say is interesting -- especially since the Ciphersaber FAQ says...
"RC4 is a powerful pseudo-random number generator, with a much
bigger internal state, then [sic] the ones that come with most
programming systems."
| >If
| >so, is there a straightforward way to adapt such a byte-stream
| >to generate PRNs uniformly distributed on 1..n?
|
| The conventional technique is "rejection." I have described this
| many times. See, for example:
|
|http://www.io.com/~ritter/KEYSHUF.HTM
|
| in "The Shuffling Subsystem" section.
Ah, well... I had hoped there might be something more efficient
than rejection methods -- they can be so inefficient that I had
ruled them out without saying so.
| >If the answers to these last questions are in the affirmative,
| >then I wonder whether it might be reasonable to have a 2-stage
| >cipher that first uses ARC4 as usual (e.g. as in Ciphersaber),
| >followed by Durstenfeld Transpositions (Shuffles or equivalent)
| >whose rand(1..n) procedure also uses ARC4's stream. (?)
|
| Durstenfeld did not invent bit-permutation ciphers, nor did he
| invent
| the idea of bit-balancing the data for a bit-permutation cipher.
| That type of cipher is called Dynamic Transposition.
The Shuffle algorithm is for generating random permutations
of *anything*, right? So surely you don't consider that
simply using it for bit-permutations is proprietary? (One
could also use Shuffle for byte-permutations, but I believe
both to be non-proprietary uses. NB: I'm specifically *not*
referring to other cipher components such as bit-balancing.)
--r.e.s.
--
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 02:40:10 -0500
Reply-To: see.signature
Nicol So wrote:
>
> Paul Rubin wrote:
> >
> > Nicol So <[EMAIL PROTECTED]> writes:
> > > What you want to do with a failed security module is to retire it--stop
> > > encrypting information for it and obsolete any information stored on it.
> > > What you don't want to do is to store global/shared secrets directly in
> > > the non-volatile memory on a security module. Any such secrets should be
> > > stored off the module in encrypted form and loaded in volatile memory
> > > when they are needed. This way, the security module by itself is not
> > > enough to perform any sensitive operation, and can be sent to the
> > > manufacturer for replacement.
> >
> > This doesn't make sense--the whole point of the tamper resistant
> > module is to securely store keys internally. Any keys stored outside
> > the module are vulnerable to copying and therefore must be encrypted;
> > but then in order to load them into the module, the decryption key
> > must be stored inside the module. So if the module is sent back to
> > the manufacturer, all the keys are potentially compromised.
>
> You're assuming that encrypted versions of these keys are easily
> obtainable, which need not be true. Note that these keys are uniquely
> encrypted for a particular security module, there's no reason for the
> encrypted keys to be floating around. These encrypted ke
Cryptography-Digest Digest #552
Cryptography-Digest Digest #552, Volume #13 Fri, 26 Jan 01 02:13:00 EST
Contents:
Durstenfeld Transpositions & ARC4 ("r.e.s.")
Re: Knots, knots, and more knots (Matthew Montchalin)
Re: Durstenfeld Transpositions & ARC4 (Terry Ritter)
Re: Steak Stream Cipher ("Scott Fluhrer")
William's P+1 ("The Death")
Re: What do you do with broken crypto hardware? ("Douglas A. Gwyn")
Re: Durstenfeld Transpositions & ARC4 (David Wagner)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Durstenfeld Transpositions & ARC4 (Paul Rubin)
(EBAY AUCTION) Applied Cryptography (Eric S. Ma)
Re: Cryptographic Camouflage (Thomas Wu)
Re: Durstenfeld Transpositions & ARC4 (Benjamin Goldberg)
Re: What do you do with broken crypto hardware? (Nicol So)
Re: Durstenfeld Transpositions & ARC4 (Benjamin Goldberg)
Integer Primality tests using Chebyshev Polynomials ("ibnsug")
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: What do you do with broken crypto hardware? (Nicol So)
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Durstenfeld Transpositions & ARC4
Date: Thu, 25 Jan 2001 19:57:58 -0800
In 1964 Durstenfeld published his well-known Shuffle algorithm
that generates a random N-permutation by means of successive
pairwise transpositions, which seems to be the "dynamic" part
of Terry Ritter's "Dynamic Transposition" cipher. Has there
been substantive improvement in such algorithms since 1964, or
does Durstenfeld's remain about as good as any?
Also, is ARC4's byte-stream generator adequate as a CSPRNG? If
so, is there a straightforward way to adapt such a byte-stream
to generate PRNs uniformly distributed on 1..n?
If the answers to these last questions are in the affirmative,
then I wonder whether it might be reasonable to have a 2-stage
cipher that first uses ARC4 as usual (e.g. as in Ciphersaber),
followed by Durstenfeld Transpositions (Shuffles or equivalent)
whose rand(1..n) procedure also uses ARC4's stream. (?)
--r.e.s.
--
From: Matthew Montchalin <[EMAIL PROTECTED]>
Subject: Re: Knots, knots, and more knots
Date: Thu, 25 Jan 2001 20:18:29 -0800
|Except we have to describe how those bits got there, from the previous
|state. Thus, the punchcard, and what it dictates, is very important.
|
||Also, I'd argue that 10100111 is more complex than either of them.
But the length of the rope has not changed, and by feeding the same
length into this permutation machine, over and over again, you will
eventually reach a repeated state. The number of iterations, N,
defines the true efficiency of the encryption machine.
So, even if you start with a length of rope with knots in such places
represented by the "1" bits, the question is how long it will take
before the rope gets "unknotted" again, thus completing the cycle.
If the rope can be shown to never "unknot" again, then a second
inquiry must be made, and that is how long does it take for the
rope to repeat any given state?
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 26 Jan 2001 04:59:35 GMT
On Thu, 25 Jan 2001 19:57:58 -0800, in
<94qsjr$qfk$[EMAIL PROTECTED]>, in sci.crypt "r.e.s."
<[EMAIL PROTECTED]> wrote:
>In 1964 Durstenfeld published his well-known Shuffle algorithm
>that generates a random N-permutation by means of successive
>pairwise transpositions, which seems to be the "dynamic" part
>of Terry Ritter's "Dynamic Transposition" cipher. Has there
>been substantive improvement in such algorithms since 1964, or
>does Durstenfeld's remain about as good as any?
There exist other permutation techniques of similar age. Shuffle
seems about as good as any, and is widely understood. For the state
of the art up to 1991, see:
http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect6.7
>Also, is ARC4's byte-stream generator adequate as a CSPRNG?
The ARC4 state is awfully small for Dynamic Transposition, especially
if we shuffle twice. We want more active state in the RNG than is
used in a single encryption, and probably do want at least 128 bits in
the block. Since rejection in Shuffle (to achieve variable-range)
throws away values (and may throw away a lot), probably it is not
large enough.
>If
>so, is there a straightforward way to adapt such a byte-stream
>to generate PRNs uniformly distributed on 1..n?
The conventional technique is "rejection." I have described this many
times. See, for example:
http://www.io.com/~ritter/KEYSHUF.HTM
in "The Shuffling Subsystem" section.
>If the answers to these last questions are in the affirmative,
>then I wonder whether it might be reasonable to have a 2-stage
>cipher that first uses ARC4 as usual (e.g. as in Ciphersaber),
>followed by Durstenfeld Transpositions (Shuffles or equivalent)
>whose rand(1..n) procedure also uses ARC4's stream. (?)
Durstenfeld did not invent b
Cryptography-Digest Digest #551
Cryptography-Digest Digest #551, Volume #13 Thu, 25 Jan 01 23:13:01 EST
Contents:
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Re: How much of this group's discussion violates the DMCA (Mok-Kong Shen)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
MIKE - alternative to SPEKE and PAK ("Michael Scott")
Re: Knots, knots, and more knots (Matthew Montchalin)
Re: Random stream testing. (long) ([EMAIL PROTECTED])
Re: Leo Marks dies ([EMAIL PROTECTED])
Re: unknown encryption algorithm ("Douglas A. Gwyn")
What do you do with broken crypto hardware? (Paul Rubin)
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Fitting Dynamic Transposition into a Binary World (Benjamin Goldberg)
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fitting Dynamic Transposition into a Binary World
Date: Thu, 25 Jan 2001 22:50:38 GMT
On Thu, 25 Jan 2001 22:28:38 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>I doubt that substitution could be "just as good." Resolving that
>issue would seem to require a comparable alternative design which
>could be examined and compared.
But the specific point we disagree on, I think, is that "all possible
transpositions" are not, in my opinion, as good as "all possible
substitutions" of the whole block, so the fact that any substitution
design won't provide that is not a strike against substitution.
That's basically because "all possible transpositions" are not the
same thing as all possible substitutions over the set of balanced
blocks. This is a specific mathematical issue, and I'm puzzled why
it's not getting across.
What I have on my page at
http://home.ecn.ab.ca/~jsavard/crypto/co041205.htm
is just 'conceptual', and hence not completely specified, but then
neither is Dynamic Transposition (the stream cipher component isn't
fully defined). I can't remember the details now, but I wouldn't be
surprised if your original Dynamic Transposition design might have
even inspired it in part; I think I remember mentioning in an E-mail
to you, though, that I was thinking of using a block cipher as a
combiner simply as an alternative to Dynamic Substitution.
I can understand that interest in novel combiners is limited, but I
would have thought that even in the 'mainstream', combining a byte at
a time with byte-wide fixed S-boxes, sort of like a rotor machine,
would be popular to avoid the bit-flipping problem of the plain XOR
combiner.
My design at the URL given above, though, was more a tour-de-force
showing how a gigantic key could be used to some effect. (There is a
second design, which I consider more potentially practical, lower on
the page, but that isn't germane - even though _it_ uses
transposition...of key material.) Unlike Dynamic Transposition, which
is practical (if _unfashionable_), this is big, slow, and cumbersome.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How much of this group's discussion violates the DMCA
Date: Fri, 26 Jan 2001 00:46:40 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > It might be of interest to recall in this connection that
> > decades ago there was once a (unrealized) suggestion that
> > editors of scientific journals voluntarily submit articles
> > about crypto, the publication of which could be of relevance
> > to national security, for preview by some institutions.
>
> Of course that raised the issue of what criteria would be
> used to judge the impact on national security. The intent
> of most of the proponents seemed to be to slow down the
> open development of the science, on the assumption that
> the national interest would benefit from reduced
> understanding slower employment of improved technology.
> That evidently begged the question of whether improving
> understanding and technology might be better for the
> nation and indeed for everybody.
It appears that this inherently difficult political issue
has at that time been 'practically' resolved not through
convincing logical arguments from the one side or the
other (for a unification of the opposite views would be
by nature barely possible) but through naturally arising
hard facts. For in the modern era there is a flux of people
across the boundaries between all nations. A citizen of one
country today may become one of another tomorrow. So keeping
certain national 'wealth' of scientific knowledge in a
'safe' to be protected by a sentiment of patriotism against
intrusion by competing foreign countries becomes an
increasingly unrealistic and fugitive goal. At the same
time the scientists themselves, partly due to the more
frequent contacts and understanding with one another and
partly due to their enhanced awareness of the necessity
of having scientific developments serving the purpose
of peace rather than war in the world
Cryptography-Digest Digest #550
Cryptography-Digest Digest #550, Volume #13 Thu, 25 Jan 01 18:13:01 EST
Contents:
Re: unknown encryption algorithm ("Douglas A. Gwyn")
Re: Random stream testing. (long) ("Paul Pires")
Re: crypt(3C) algorithm under Solaris 2.6? (Jim Gillogly)
Re: Differential Analysis of "A + (B xor X)" ([EMAIL PROTECTED])
Re: Barrett modular reduction (Bryan Olson)
Re: DES check values (58)
Re: How much of this group's discussion violates the DMCA ("Douglas A. Gwyn")
Re: Differential Analysis of "A + (B xor X)" (Alexis Machado)
Re: NSA and Linux Security (Greggy)
Re: How much of this group's discussion violates the DMCA (lcs Mixmaster Remailer)
Re: How much of this group's discussion violates the DMCA (Darren New)
Re: How much of this group's discussion violates the DMCA (Ichinin)
Re: unknown encryption algorithm ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Fitting Dynamic Transposition into a Binary World (Terry Ritter)
Re: Random stream testing. (long) ("Douglas A. Gwyn")
Re: Echelon in Asia. (Jim)
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: unknown encryption algorithm
Date: Thu, 25 Jan 2001 19:30:57 GMT
[EMAIL PROTECTED] wrote:
> plaintext:
> dclient177-193
> some examples of encrypted (all of the same plaintext)
> kUqmnlaqr433-774
> jemuvastu663-255
> aEcofidqd366-512
> Djltfhmpi664-422
> 2dnsymiov322-450
> EEouuclio090-343
The first two characters are evidently a "salt",
or key used in the encryption. Since letters
encrypt to letters, digits to digits, and
punctuation to itself, it must be a simple
ad-hoc scheme.
I looked at the bit level for a simple Vigenere scheme,
assuming ASCII coding, but didn't find one.
--
From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random stream testing. (long)
Date: Thu, 25 Jan 2001 12:22:10 -0800
Matt Timmermans <[EMAIL PROTECTED]> wrote in message
news:OvNb6.5022$[EMAIL PROTECTED]...
> "Paul Pires" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> You're testing PRNGs, right? So you can make as much data as you like. I
> would suggest using 100 meg samples, and accepting as "OK" any result
> between 0.0001 and .. Anything outside of that would make me nervous,
Well, I have what I think is a bizzare scheme for a PRNG and I just can't
make it
fail. Not even a little bit looking at gigabytes in every way I can think
of.
I'm searching for what to do now since I am still curious about it and more
testing seems pointless. I guess I was searching for the
"PRNG evaluation process - Level 2 handbook" for clueless newbies and
the mathematically challenged. Pretty unrealistic.
> unless I had several hundred test results. If you get something outside
of
> that "good range", but you're running a whole lot of tests, then make a
new
> or larger sample and run it again -- if it is an artifact of your PRNG,
then
> it should be reasonably consistent.
>
> It seems that you simply stumbled upon a bad description of how to use
> randomness tests. I seem to remember that Marsaglia (sp?) included a very
> nice description of how to interpret the results of his DIEHARD suite.
Yes, he does say "but remember, P's happen" which
I took to mean that results cannot be interperated standalone but
only in the context of the actual sample.
Thanks.
Paul
> > Terry Ritter has made a convincing argument
> > that data sets should be examined for any deviation from
> > a random expectation including the case were the results
> > are "too good".
>
> That is exactly right -- if you run the same tests on multiple samples,
you
> should expect an even distribution of P-values. If you run 1000 tests and
> don't get any results outside of .25-.75, it is very likely that your data
> isn't random.
>
>
>
== Posted via Newsfeeds.Com, Uncensored Usenet News ==
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=== Over 80,000 Newsgroups = 16 Different Servers! ==
--
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: crypt(3C) algorithm under Solaris 2.6?
Date: Thu, 25 Jan 2001 12:29:51 -0800
[EMAIL PROTECTED] wrote:
> Does anybody now what encrypt algorithm is used by crypt(3C) under
> Solaris 2.6?
crypt(3C) under Solaris is a hashing algorithm, not an encryption
algorithm. It uses a "salt" of two characters and does 25 iterations
of a runtime-modified DES (26*16 rounds).
> I'm looking for DES encryption under 2.6. Solaris 7 and
> 8 seem to include libraries for these.
There's an encrypt(3C) that claims to provide encryption/decryption
based on crypt(3C) and mentions, but since it doesn't give details
in the man page I wouldn't use it. If you're determined to get DES
under stock Solaris 2.6 you might try this, checking some known DES
validation triples to make sure it's really d
Cryptography-Digest Digest #549
Cryptography-Digest Digest #549, Volume #13 Thu, 25 Jan 01 15:13:00 EST
Contents:
unknown encryption algorithm ([EMAIL PROTECTED])
Re: "How do we know an Algorithm is Secure?" (was RC4 Security) ("Douglas A. Gwyn")
Re: Secure game highscore server (Matthew Skala)
Re: Transposition code ("Douglas A. Gwyn")
Re: Knots, knots, and more knots ("Douglas A. Gwyn")
Re: Differential Analysis of "A + (B xor X)" (Tom St Denis)
Re: Knots, knots, and more knots (Richard Heathfield)
Re: How much of this group's discussion violates the DMCA (Mok-Kong Shen)
Re: Windows encryption: API and file system ("Ben Newman")
Re: "How do we know an Algorithm is Secure?" (was RC4 Security) (William Hugh Murray)
Re: Windows encryption: API and file system (Darren New)
Re: Transposition code ("Douglas A. Gwyn")
Re: finding inverses and factoring (Bob Silverman)
crypt(3C) algorithm under Solaris 2.6? ([EMAIL PROTECTED])
Re: Random stream testing. (long) ("Paul Pires")
From: [EMAIL PROTECTED]
Subject: unknown encryption algorithm
Date: Thu, 25 Jan 2001 17:22:23 GMT
Hi,
does somebody of you have an idea, what kind of algorithm was used to
encode the following plaintext?
plaintext:
dclient177-193
some examples of encrypted (all of the same plaintext)
kUqmnlaqr433-774
jemuvastu663-255
aEcofidqd366-512
Djltfhmpi664-422
2dnsymiov322-450
EEouuclio090-343
any help or hint is welcome :)
Sent via Deja.com
http://www.deja.com/
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "How do we know an Algorithm is Secure?" (was RC4 Security)
Date: Thu, 25 Jan 2001 16:40:56 GMT
William Hugh Murray wrote:
> We never really know that an encryption algorithm is strong.
In some cases it is possible to characterize the "strength"
of a cryptosystem. Consider a system where the key changes
before unicity distance is reached, as an oversimplified example.
--
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Secure game highscore server
Date: 25 Jan 2001 00:35:06 -0800
In article <[EMAIL PROTECTED]>,
graywane <[EMAIL PROTECTED]> wrote:
>The only way to prevent cheating is to play with people who don't cheat.
>Sad but true.
If the game is one where a computer player can trivially outperform a
human, then the game sucks anyway. Good games necessarily require human
intelligence. In the Kosmos Online project we're facing this kind of
issue over and over again, because we're building an open source
multiplayer networked roleplaying game. There's no question that anything
the client knows, the player knows - so the client cannot be told anything
the player isn't allowed to know. There's no question that anything the
client can do, the player can do - so the client cannot be allowed to do
anything the player isn't allowed to do. There's no way to distinguish a
computer behind the controls from a human, that's a harder problem than
creating a simulated human in the first place, so the game cannot be one
where a present-day-tech AI would have an advantage over a human. That
last requirement touches on every aspect of the game. There can't be any
critical reflex actions; there can't be any "strategy" tests that come
down to automatable things like arithmetic or simple logic. Instead, we
have to concentrate on social interactions and role-playing, the things
computers are no good at.
What a coincidence that they call them "role-playing games".
--
Matthew Skala
[EMAIL PROTECTED] :CVECAT DELENDA EST
http://www.islandnet.com/~mskala/
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Transposition code
Date: Thu, 25 Jan 2001 17:06:02 GMT
Benjamin Goldberg wrote:
> From your post, I wrote the following: ...
> However, it doesn't seem to work quite right.
I wasn't going to say anything, but at this point
perhaps you could use some friendly programming advice.
The simplest appraoch is often best -- don't try to
fold all the tranformations together in a few compact
lines of code, at least not until you have gotten the
code right. Use your diagram as a guide:
1 2 3 plaintext (input) column number
-
K E Y
2 1 3 ciphertext (output) column number
-
1 2 3 plaintext message sequence
4 5 6
7
-
l s s
The last line indicates whether the column is long or
short. First step is to obtain the geometric parameters:
message length, number_of_columns := key_length. Then
compute the lengths of short and long columns:
short_column_length := message_length // key_length,
long_column_length := short_column_length + 1. The
number_of_long_columns (may be 0) := message_length -
number_of_columns*short_column_length. If you lay the
plaintext out as a doubly-indexed array (perhaps using
dynamic allocation as I posted a week ago) it will be
easy
Cryptography-Digest Digest #548
Cryptography-Digest Digest #548, Volume #13 Thu, 25 Jan 01 12:13:00 EST
Contents:
Re: Knots, knots, and more knots (Richard Heathfield)
Re: DES check values ("madcow")
Steak Stream Cipher ([EMAIL PROTECTED])
Re: How much of this group's discussion violates the DMCA (Dido Sevilla)
Re: Random stream testing. (long) ("Gary Watson")
Re: "How do we know an Algorithm is Secure?" (was RC4 Security) (DJohn37050)
Re: How many bits of security can a password give? (rot26)
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Windows encryption: API and file system ("Ben Newman")
Re: Creating a self extracting encrypted exe? (Kent Briggs)
Re: How many bits of security can a password give? (Erik Runeson)
Re: How much of this group's discussion violates the DMCA (Jerry Coffin)
Re: Windows encryption: API and file system (Bryan Mongeau)
Re: Barrett modular reduction ([EMAIL PROTECTED])
Date: Thu, 25 Jan 2001 14:05:18 +
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Knots, knots, and more knots
Matthew Montchalin wrote:
>
> On Wed, 24 Jan 2001, Matthew Montchalin wrote:
>
> |Imagine you have this very long rope, and you've got this machine
> |with two holes, where you feed the rope completely through the
> |machine, and before it comes out, it will either be knotted, or
> |unknotted, depending on the state of a punch-card (ahem) that has
> |been inserted into the machine in advance. Let us further assume
> |that the machine does not stretch the rope longer than it was
> |to start with, and does not shorten it in any way.
> |
> |Starting with this simple setup, is it reasonable to describe
> |complexity by the knots per unit length of rope, multiplied by
> |the operations specified on the punch card?
(Clearly, we can describe the rope's knots as 0 = no knot, 1 = one knot,
so it's just a way to represent binary.)
I must have misunderstood what you meant because, the way I figure it,
this scheme would give maximum complexity (for a given, non-zero, series
of operations on the punch card) to and minimum complexity to
, whereas it seems to me that neither of these bitstreams is
more complex than the other - they are separated only by a single NOT
instruction.
Also, I'd argue that 10100111 is more complex than either of them.
Consider the descriptions in English:
Eight ones.
Eight zeros.
A couple of one-zero pairs, then a zero, then three ones.
Surely the last one is more complex?
Of course, you might find simpler descriptions for each of them... e.g.
FF, 00, A7. Now count the number of different symbols required to
describe each...
So the knots don't seem to tie it up completely, do they? In fact, it's
a bit of a tangle. Defining complexity is a knotty problem indeed.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
--
From: "madcow" <[EMAIL PROTECTED]>
Subject: Re: DES check values
Date: Thu, 25 Jan 2001 08:54:29 -0500
You can get source code for DES in Basic at :
http://home.wxs.nl/~napel/des.htm
58 <[EMAIL PROTECTED]> wrote in message
news:94n7hb$ij0$[EMAIL PROTECTED]...
> My company uses DES to encrypt fixed length (16-character) values.
> Much as I'd like to see them make the leap from DES, it's what our
> system, indeed all the businesses with which we work, uses.
>
> I am a custodian for one part of the clear text, and I am a hobbyist
> BASIC programmer (no laughing, please). One business to whom we must
> occasionally send this text requires that we apply some simple XOR math
> to mask the true text. This isn't hard, and I've written a program
> that does this for us and fills out a form.
>
> The business also asks that we provide a check value for the clear
> text, so that they can confirm it when they undo the XOR functions.
> And this is where I'm not proceeding well. For my tests, I used our
> Atalla SIU to generate some random clear text and the check values for
> each. When I try to generate my own check values, they're wrong.
>
> I understand that the algorithm to generate a check value simply
> encrypts with a key of all zeroes. I confirmed this on our SIU. I
> followed the ANSI standard to the best of my knowledge, making sure
> each step of the algorithm had its own routine, and the routines and
> tables all look right. The minor adjustments I've made don't change
> the check value, and I'm not sure where the real problem is (should be
> beyond the last sections, but I've adjusted those, too).
>
> So, I guess the easiest step, vice trying to re-invent this wheel, is
> to determine if such a program already exists. It doesn't have to be
> BASIC, but it does need to run on an NT. If the program accepted input
> on the command line, so much the bett
Cryptography-Digest Digest #547
Cryptography-Digest Digest #547, Volume #13 Thu, 25 Jan 01 06:13:00 EST
Contents:
Re: Snake Oil (Anthony Stephen Szopa)
Re: Some Enigma Questions -- 150*10^18 settings? (Frode Weierud)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Creating a self extracting encrypted exe? ("Vladimir Katalov")
Re: Secure game highscore server (Niklas Frykholm)
Re: Barrett Modular Reduction with large x (Bryan Olson)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Re: Cryptographic Camouflage (Mok-Kong Shen)
Re: Echelon in Asia. (Arturo)
Re: Snake Oil (Richard Heathfield)
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Snake Oil
Date: Wed, 24 Jan 2001 23:54:02 -0800
Paul Rubin wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> writes:
> > Take my encryption software. Give it a go. Prove to us you can
> > break it. Give us your most tenuous reasonable explanation on how you
> > would go about it.
> >
> > Or do you just talk about snake oil having never known what it really
> > is?
>
> That's another standard whine of the snake oil salesman, saying "how
> can you know it's bad unless you try it?". Of course, you have to
> expend your own resources / risk your own health in order to try it,
> with no compensation from the salesman if (as you suspected) the
> product is no good. In typical cases the salesman even wants you to
> pay for the product before you can test it, though that may not be
> going on here. In either case, the salesman is claiming you're remiss
> unless you're willing to work for him for free. It's not an
> impressive argument.
>
> Anthony: you are not offering to let people test your cipher under the
> same conditions that 3DES can be tested. Specifically, 3DES protects
> millions of dollars of live traffic every day, so it's worth that much
> for someone to be able to crack it.
>
> How many million dollars are you offering to anyone who cracks your
> cipher? That's the test that 3DES passes every day, that you have not
> offered to submit your cipher to.
>
> After all, some of us are professionals here. That means if we do
> cryptography for someone, we expect to get PAID for it.
Speaking of money( at least indirectly):
If you can believe that I did indeed invent the anti-piracy protocol
basis upon which MS is now touting as their latest "innovation"
while almost certainly having no legally defensible or legally
enforceable rights to it, what does this say about MS taking
advantage of probably most of the major software producers by
having them sign non disclosure agreements and possibly even
signing contracts to commit to exclusive usage of MSs anti-piracy
"innovation" all the while MS knew that their "partners" didn't have
a clue about me?
I bet they have been chuckling quite a bit about it.
I can already begin to hear the drone of masses of computer software
company stockholders gnashing their teeth.
"Tai Chi is just a path;
it is not the way."-- ASS 2001
--
From: [EMAIL PROTECTED] (Frode Weierud)
Subject: Re: Some Enigma Questions -- 150*10^18 settings?
Date: 25 Jan 2001 08:34:33 GMT
Reply-To: [EMAIL PROTECTED]
wint <[EMAIL PROTECTED]> writes:
>How is the "150 million trillion" (150 * 10^6 * 10^12 = 1.5*10^20)
>computed? My math gives a much lower number -- too low to be
>correct. Here goes.
>Three rotors, with 26 letters:
> 26*26*26 = 17,576 starting positions
>Three rotors selected from 5:
> 5*4*3 = 60 rotor choices
>Plugboard with 13 wire pairs (26/2, wild guess here):
> 13! = 6.2 billion ways to plug in the wires (wow!)
This is where the error is. First of all the "150 million trillion"
is calculated using 10 Steckers which gives a greater value for the
possible Stecker combinations than 13. Actually 11 Steckers give the
maximum number of combinations.
The way to compute this value is first to select the number of
Stecker plugs that 10 Stecker connections will use. One Stecker connection
will occupy 2 plugs, 10 Stecker will occupy 20 and s Stecker will occupy
2s. These 2s plugs can be selected from a total of 26 plugs which gives:
(26) 26!
( ) =
(2s) (2s)! * (26-2s)!
Within this selected group of plugs the first Stecker end can select
any of the 2s plugs the other end has a choice of (2s-1), the second
Stecker has a choice of (2s-3) plugs to complete the connection, third
Stecker (2s-5) etc.
The total expression will then be:
(26) 26!
( ) * (2s-1) * (2s-3) * (2s-5) * ... * 1 =
(2s)(2s)! * s! * 2^s
Using this formula the number of combinations for 10 Steckers will be
about 1.5 * 10^14 which, if you divide with your number of 6.2 * 10^9,
will give yo
