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_col
Cryptography-Digest Digest #549
Cryptography-Digest Digest #549, Volume #12 Sun, 27 Aug 00 16:13:01 EDT
Contents:
Thanks for your comments! ("Slava K.")
Re: PGP 6.5.8 test: That's NOT enough !!! (SCOTT19U.ZIP_GUY)
My (New) New algorithm ("Slava K.")
Re: R: Test on pseudorandom number generator. (Terry Ritter)
Re: 4x4 s-boxes (Mack)
Re: PGP ADK Bug: What we expect from N.A.I. (Mok-Kong Shen)
Re: Destruction of CDs (Mack)
Re: DeCSS ruling -- More (Mack)
Re: The DeCSS ruling and the big shots (Mack)
Re: My (New) New algorithm ([EMAIL PROTECTED])
Re: 4x4 s-boxes ([EMAIL PROTECTED])
Re: 4x4 s-boxes (Mok-Kong Shen)
CD Steganography ("Paul Pires")
Re: My (New) New algorithm (Mok-Kong Shen)
Re: PRNG Test Theory (Tim Tyler)
Re: On pseudo-random permutation (Tim Tyler)
Encryption tool (No User)
CAST-Cipher / CAST-Algorithm ("Patrick Harenberg")
Re: R: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Re: On pseudo-random permutation (Terry Ritter)
Re: My (New) New algorithm ([EMAIL PROTECTED])
Re: CAST-Cipher / CAST-Algorithm ([EMAIL PROTECTED])
Re: RSA Security Conference for 2001 (Quisquater)
From: "Slava K." [EMAIL PROTECTED]
Subject: Thanks for your comments!
Date: Sun, 27 Aug 2000 18:38:03 +0200
Thanks to everyone who sent me their comments!
After taking a little more time to review the algorithm, I found the
pattern.
No further replies are necessary.
Thanks!
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: 27 Aug 2000 16:43:07 GMT
[EMAIL PROTECTED] (David Sternlight) wrote in
HY1q5.1460$[EMAIL PROTECTED]:
The dancing, fast footwork, and apologetics of PGP die-hards here is
truly sad. PGP has, after all the hubris of the past, acquired a fatal
error. If you can't detect a forged key, it's all over.
The only reliable solution is a "new" PGP which is deliberately
incompatible with all previous versions but classical PGP. This is the
ONLY way to restore trust on the part of the general (non-specialist)
user.
Could you in this NEW PGP please don't have checks built into the
code that immeditaly tell if the KEY is bad. Nothing like should be part
of the encrypted text. Also make sure it use a fully bijective compressor.
I have no heart burn if they add a CRC outside of the encrypted blocks
but even there one should have the option to turn it off.
Does NA have the guts to do this? Will they absorb the cost of a
complete product (recall and) replacement. Will "pay" PGP users be
willing to replace much of their PGP infrastructure? If not, I say game
over.
And if something like this had happened to Netscape/Microsoft S/MIME
X.509, honest PGP die-hards here will concede they would be among the
first to say what I am saying (about PGP) about S/MIME. When the
ordinary user loses control over his cryptosystem and cannot detect
forged keys, no amount of apologetics will sweep that under the rug.
David
P.S. For the ad hominem types here who think this is some anti-PGP
crusade on my part, I too have now had to suspend use of a good part of
my crypto infrastructure (PGP 6.x) and any number of PGP certificates
from Thawte.
David
"Michel Bouissou" [EMAIL PROTECTED] wrote in message
news:8o87bf$p7m$[EMAIL PROTECTED]...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've just tested the "ADK-bug-fixed" PGP 6.5.8 against Ralf's B1
forged key that holds a faked ADK.
Where previous versions would show this key as having an ADK, and use
the forged ADK, the "fixed" PGP 6.5.8 shows the forged key as being a
normal, valid key, without any ADK.
PGP 6.5.8 will not use the forged ADK for encryption, and will just
behave as for a normal key.
Well, okay, it "fixes" the bug.
BUT IT DOESN'T WARN YOU IN ANY WAY THAT THE KEY YOU'RE USING HAS BEEN
FORGED. You just see a valid key and the forged ADK is ignored.
So:
- - You don't know the recipient's key has been victim of an attack;
- - You don't know that this key remains a potential danger for users
that still have previous versions of PGP.
Actually with PGP 6.5.8, you have LESS CHANCES to ever detect that a
key was forged, than you had with previous vulnerable versions.
That's no good folks.
Waiting for 6.5.9 that will display a BIG WARNING that an ADK sits
where it shouldn't on a given key.
- --
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com
Comment: Corrigez le bug PG ADK. Installez PGP 6.5.8 ou plus recent.
iQA/AwUBOaeSnY7YarFcK+6PEQJUCACdFPt9KmCr+ImmCdpYt8i6XUlcmYUAnRRj
+OXfvsBkFugPmzNIlCaVO2N5
=iGL6
-END PGP SIGNATURE-
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD W
Cryptography-Digest Digest #549
Cryptography-Digest Digest #549, Volume #10 Fri, 12 Nov 99 00:13:03 EST
Contents:
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Mike McCarty)
Re: Encode It 1.03 CRACKED 1 month after released (JPeschel)
Re: real random number generator idea -- any criticisms? ("Gary")
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: E-CRYPT cracked too ! ("Ken Lee")
Re: Signals From Intelligent Space Aliens? Forget About It. (Mike McCarty)
Re: OT: dates and sigs[Re: PGP Cracked ?]
Re: Ultimate Crypto Protection? ("Trevor Jackson, III")
Re: real random number generator idea -- any criticisms? (John Myre)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: real random number generator idea -- any criticisms? (JD)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Postpages for Handbook of Applied Cryptography (Alfred John Menezes)
From: [EMAIL PROTECTED] (Mike McCarty)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 11 Nov 1999 22:34:30 GMT
In article [EMAIL PROTECTED], Coen Visser [EMAIL PROTECTED] wrote:
)Mike McCarty wrote:
)
) No individual string can be random. A string is or is not compressible,
)
)It is a definition: call a string random when it is incompressible.
I was disputing your definition.
[snip]
) You seem to be trying to decompose a single event, i.e. the generation
) of a string, into multiple events, i.e. the generation of each string
) element (or equivalently, generation of strings of length one element
) each), and then use the randomness or non-randomness of the latter
) events considered as a stochastic process as a means for determining
) the randomness of the single event of generation of the entire string.
)
)Ah, that was not what I meant. I was trying to make a point (badly)
)about the inevitable occurence of regular patterns in random strings.
If that's true, then we are talking about different subjects. I thought
you were discussing randomness, and a putative definition in terms of
compressibility.
To reiterate: the compressibility or non-compressibility of any given
string depends on the universe from which it is drawn. A given string
has a "pattern" in it which leads it to be compressible (in the sense
that the compressed string is actually shorter than the uncompressed
version) only if one knows something about the universe from which it
is drawn. It is not a property of an individual string.
In order to further the exchange of information rather than talking at
cross purposes, would you please supply putative definitions for:
random variable
random process
stochastic process
random number
random string
Mike
--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel - They make me say that.
--
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Encode It 1.03 CRACKED 1 month after released
Date: 11 Nov 1999 22:55:03 GMT
"Alexander PUKALL" [EMAIL PROTECTED] wrote so much that
I decided to snip it:
The soft can be found here :
http://www.skylarkutilities.com/encode-it.pcs...
The soft use a stream cipher with no salt key. With a same key, the output
of the stream cipher
will be the same :
A simple XOR with the same output stream for all files crypted with the same
password !!
But with the new SCC 524,288 Bit encryption method !! Yes my Lord !
Oh snake oil My Love !!
Encode-It is Province's replacement program for Turbo Encryptor, which
was cracked by Casimir, Randall Williams,and myself.
The SCC encryption method, I think you'll find, is, like Turbo Encrypto's,
home-grown. Instead of just discovering that no salt is used, I think
you may be able to really crack Encode-It using ciphertext only, or by changing
a few snippets of code.
Joe
__
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__
--
From: "Gary" [EMAIL PROTECTED]
Subject: Re: real random number generator idea -- any criticisms?
Date: Thu, 11 Nov 1999 22:57:38 -
It's easier to read the timestamp counter (rdtsc in assembler) every window
message event and append it the current random number then hash it giving
the new current random number.
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Crossposted-To: comp.compression
Subject: Re
Cryptography-Digest Digest #549
Cryptography-Digest Digest #549, Volume #9 Fri, 14 May 99 02:13:03 EDT
Contents:
Toy Function (post didn't work) ([EMAIL PROTECTED])
Re: TwoDeck solution (but it ain't pretty) (David A Molnar)
Re: On Contextual Strength (John Savard)
Re: Thought question: why do public ciphers use only simple ops like shift and
XOR? (John Savard)
Re: Thought question: why do public ciphers use only simple ops like (Bryan Olson)
Re: Lemming and Lemur ([EMAIL PROTECTED])
Re: Lemming and Lemur: New Block and Stream Cipher ("Craig Clapp")
From: [EMAIL PROTECTED]
Subject: Toy Function (post didn't work)
Date: Fri, 14 May 1999 04:12:23 GMT
Obviously my first post didn't work..
Hmm I have a round function where
a, b32 bits
+ addition (mod 2^32)
^ addition (mod 2)
S[1024] Array S-Box
R[32] Array of round keys
for r = 0 to rounds
A = A + (((B ^ R[2r]) * S[B 22]) ^ R[2r + 1])
(B,A) = (A,B)
next r
Where there are two permutations using round keys, and diffusion using
an sbox. The multiplication is to ensure a higher rate of diffusion
(while maintaining simplicity), and the shift is to use the more active
bits as indexes.
The diffusion is delayed by one round, but after about 16 rounds I
dunno if it matters. The average hamming distance is 31.93 bits after
16 rounds (comparing plaintext from decrypt cipher text with 'random'
keys). I used a blowfish style key schedule, which is heavily
dependant on the round function. I also used a R[32] and R[33] for
post white...
Anyways, this cipher may (and is most likely) weak, the point I am
trying to get to is
Where would I start to analyze this? What could I poke at to exploit?
I just want pointers on how to start. I have allready implemented
this. And some empiracle testing (hamming distance),.
Any pointers?
Thanks,
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: TwoDeck solution (but it ain't pretty)
Date: 14 May 1999 04:09:18 GMT
[EMAIL PROTECTED] wrote:
This is not a question which an aspiring cryptographer should ask
after posting his phone number...
Why not? They have to know where to send the money :)
combine digital cash with alt.anonymous.messages and a remailer network, and
we can get around that tiny little problem.
Just kidding
-David
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: On Contextual Strength
Date: Fri, 14 May 1999 04:35:26 GMT
Bryan Olson [EMAIL PROTECTED] wrote, in part:
I want to reject ciphers if there exists a tractable break,
without regard to whether an adversary may know or discover that
break.
No. I mean what I wrote.
I'd want to reject such ciphers too. However, I am helpless to reject
a cipher for which I do not know the break, or of the break - and my
adversaries are smarter than I am.
If a cipher is strong under the idea I proposed, then _no_
adversary can break it since a break does not exist.
So you do mean this.
And you are correct - that's a good definition of "strong".
But we don't know if tractable breaks exist that we don't know about.
We don't _even_ know if tractable breaks exist that we don't know
about, but our adversaries know about. We only know about the breaks
we know.
Terry Ritter asks us to consider the possibility our adversaries know
something we don't.
You are now saying that you believe in following an even higher
standard. I don't think he opposes this higher standard. What he
opposes is the *lower* standard of assuming a cipher is strong if we,
ourselves, don't know the break.
And that lower standard at least _appears_ to be the one followed in
practice by the conventional academic cryptographic community. Plus a
fudge factor - I tend to think this is unavoidable, even if it could
be made a little larger - but Mr. Ritter appears to be seeking to
reject that practice completely. Well, I think that even his
multi-cipher proposal is just a way of getting a bigger fudge factor -
but a _much_ bigger fudge factor without a correspondingly large
sacrifice of processing time.
John Savard ( teneerf- )
http://members.xoom.com/quadibloc/index.html
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Thought question: why do public ciphers use only simple ops like
shift and XOR?
Date: Fri, 14 May 1999 04:23:02 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
We *can't* build in "safety factors" if we don't know that anything is
strong. W
