Cryptography-Digest Digest #541, Volume #10 Wed, 10 Nov 99 22:13:03 EST
Contents:
Re: One-time-pad simulator. (William Rowden)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Encode It 1.03 CRACKED 1 month after released ("Alexander PUKALL")
Re: Signals From Intelligent Space Aliens? Forget About It. (Anthony Stephen Szopa)
Re: Signals From Intelligent Space Aliens? Forget About It. (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Tom)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Research suggestion? (David A Molnar)
Re: Re: How protect HDisk against Customs when entering Great Britain (JD)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
----------------------------------------------------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: One-time-pad simulator.
Date: Wed, 10 Nov 1999 21:25:22 GMT
In article <[EMAIL PROTECTED]>,
trifthen <[EMAIL PROTECTED]> wrote:
> Here's the crypted text:
>
> Ly"f;It1R15U33RzNIpC"Z5RDi"YFj"X/c5O5Np;
> Z.Rs/a5Ll,Rr!Ut Xw"Rp"HoyBYv Vs!:
I won't claim to be an expert, but I have a comment below. First,
however, I want to quote "Cryptography FAQ 02/10: Net Etiquette":
2.3. How do I present a new encryption scheme in sci.crypt?
``I just came up with this neat method of encryption. Here's some
ciphertext:
FHDSIJOYW^&%$*#@OGBUJHKFSYUIRE. Is it strong?'' Without a
doubt questions like this are the most annoying traffic on
sci.crypt.
...
So what do you do if you have a new encryption scheme? First of
all, find out if it's really new. Look through this FAQ for
references and related methods. Familiarize yourself with the
literature and the introductory textbooks.
> Here's a short overview of how my random number generator works, as
> it's crucial to the system:
[snip]
> Find current value of length.
> Take this value and add 21 to separate it enough from the
> data stream. (length = len + 21)
> Take first character of the key. (string)
> Mod string by length.
> While there is still key left
> Get the next character in the key. (next)
> Take the result of the previous mod, and append next. (new)
> Mod new by length. (result)
> increment length.
> Return final mod.
>
> It does this for every character in the original text, hence it makes
> a one-time-pad based on the original text.
Code would help; I don't understand the relationship between the
plaintext and your "pad." Which of the values above are influenced by
the plaintext?
In any event, I'll venture the opinion that your last sentence sounds
more like a complicated autokey rather than a one-time-pad. I've read
that Vigenere invented a simple autokey system in 1585. Similar to
your hex key, his system also had a "priming" key to begin enciphering.
An attack (developed by Bassieres) relies on finding in the ciphertext
the correlations between the plaintext and the key (the actual key, not
the priming key). Some think Vigenere "almost" invented the
one-time-pad; he recognized that a key as long as the message was a Good
Thing. To be a true one-time-pad, however, the key would have to be (at
least) uncorrelated to the plaintext.
Additionally, while it is easy to design your own pseudo-random number
generator, it is difficult to create one that is cryptographically
strong. Is your PRNG linear?
> If you want to see my actual code, just tell me and I'll
> show it to you.
Again I'll quote the FAQ:
If you really think your system is secure, and you want to get some
reassurance from experts, you might try posting full details of
your system, including working code and a solid theoretical
explanation, to sci.crypt.
Have fun with your system. I wish you luck.
--
-William
Damages claimed for unsolicited commercial email (RCW19.86 & 47USC227)
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Wed, 10 Nov 1999 22:22:52 +0100
Tim Tyler wrote:
>
> In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> : As I said previously, for such numerical coding the compression is
> : already so good that one need not (at least in the first
> : experimental phase) consider the aspect of word freqeucies.
>
> I doubt this. I expect non-dictionary words will typically bulk up the messages
> by a larger factor than they are compressed by, for (say) email messages.
>
> It may be possible to develop a scheme that (roughly) breaks even on the
> compression stakes - but I doubt good compression ratios will ever be obtained -
> except on obscure or contrived types of text.
Just try to roughly compute the compression ratio of your paragraph
above (noting that each word is translated to 16 bits) and
you'll see that you get something that is probably better than
what you expect from a normal compression of ASCII text.
>
> Also, any 16-bit granularity in the output file will immediately render "8-bit"
> one-on-one property invalid: if you have a file which is an odd number of bytes
> long, you can rule it out immediately as a candidate compressed file ;-/
>
> In fact, this will /probably/ have few implications for security, given various
> assumptions - e.g. that the length of the compressed file is already clear.
Since each word is translated to 2 bytes, every compressed file
has a even number of bytes. Now, suppose one gets a 'wrong' file
which comes into being because the analyst uses an incorrect key
to decrypt. This file certainly also has an even number of bytes
(assumung normal block algorithms). Since the dictionary has
2^16 entries, any 2 bytes, whatever the content, has a corresponding
word (the dictionary is assumed to be full, i.e. exhausting the
coding space of 2^16). Thus the 1-1 property (definition of Scott)
is trivially present, since one can translate the words back again
to the same numbers.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Wed, 10 Nov 1999 22:21:55 +0100
Phil Norman wrote:
>
> To clear up an implicitly asked question above, is it being
> assumed that the dictionary is a shared secret?
A secret dictionary would have been the classical code book.
Since our main purpose here is compression, it is my understanding
(and anyway what I strongly favour) that the dictionary is to
be a public one and preferably a standard or a defacto standard,
so that there could be commonly available software packages to
perform the translation.
Once again I like to stress that the numerical encoding with
constant size numbers is a known (and practice-proven) technique.
Long long time before the appearence of Unicode there has been
the Chinese telegraphic code which translates 10000 Chinese words
into 4 digit numbers each. So there is nothing mythtical about
such coding schemes.
M. K. Shen
------------------------------
From: "Alexander PUKALL" <[EMAIL PROTECTED]>
Subject: Encode It 1.03 CRACKED 1 month after released
Date: Wed, 10 Nov 1999 22:56:03 +0100
The soft can be found here :
http://www.skylarkutilities.com/encode-it.pcs
Title: Version: File Size: Published: Platform: Includes: Status:
Encode It 1.03 380 KB October 7, 1999, ------ Cracked November 10,
1999 ------
===== By Raymond J. Province Lord of snake oil ======
Windows 95,98,NT Install/Uninstall
Shareware
Overview:
Encode It is a easy to use file security system using the new SCC 524,288
Bit encryption method -
very secure and a single system wide password. In addition, it employs 21
layers of protection to
ensure your data is secure. Includes Decode It - a very small decoding
utility that you can take
anywhere. Decode It allows you to encode or decode any number of files
encoded by your copy of
Encode It, because each application will generate an unique keycode upon
installation.
Includes full support for decoding one or more files directly from within
Windows Explorer,
plus all the goodies including Copy, Move, Delete, Rename, Printing,
Viewing, Exporting,
Drag & Drop, and many more functions that make Encode It the number one
choice among
professionals.
***************************************************
* CRACKED CRACKED CRACKED CRACKED CRACKED CRACKED *
***************************************************
The soft use a stream cipher with no salt key. With a same key, the output
of the stream cipher
will be the same :
I used two files with the same password :'snake-oil-for-ever', each was
encrypted independently.
When you run the soft for the first time, it ask you a password, type
:'Password' ( not 'password' )
After, when the registration page is closed, type 'Pass' ( caution 'Pass'
and not 'pass'),
it allow you to give a new password.
a.txt with 10 bytes : AAAAAAAAAA
b.txt with 10 bytes : AAAAAAAAAA
a.txt give a.txt.scc :
2425:0100 6F 55 52 7F 45 5F 50 59 13 68
b.txt give b.txt.scc :
2425:0100 6F 55 52 7F 45 5F 50 59 13 68
When i change 52->53 at offset 0x102 ( offset 0x102 in the MSDOS/Win
debug.exe utility is same
as offset 0x2 directly in the file )
The decrypted text is :
AA@AAAAAAA
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 !!
Alexander PUKALL
November 10, 1999
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Wed, 10 Nov 1999 13:54:20 -0800
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > While don't just tease us what distance did you come up with?
>
> I don't have my notes with me right now and don't want to
> spend time recomputing it. I'll try to look it up at home
> and post a follow-up with the info.
Actually, I believe the professor said a slightly higher percentage of
the speed of light but I cannot remember exactly what it was but I do
remember it was in excess of 90%.
But my comment about surviving the voyage was referring to the
expansion of mass as one increasingly achieves speeds closer and
closer to that of light.
This mass expansion seemed to me to be dangerous and I believe I
communicated this concern to the professor. I believe he understood
what I was concerned about and I believe his reply was meant to
answer my question with regard to my concern.
He firmly believed that we could reach speeds above 90% ( he actually
gave what seemed to be a precise percentage: as if he had looked
into this matter seriously at one time) that of light, and mass
expansion would not harm us because the effect is not very
appreciable until you get very very close to the speed of light.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Thu, 11 Nov 1999 01:16:22 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>"Douglas A. Gwyn" wrote:
>
>> "SCOTT19U.ZIP_GUY" wrote:
>> > While don't just tease us what distance did you come up with?
>>
>> I don't have my notes with me right now and don't want to
>> spend time recomputing it. I'll try to look it up at home
>> and post a follow-up with the info.
>
>Actually, I believe the professor said a slightly higher percentage of
>the speed of light but I cannot remember exactly what it was but I do
>remember it was in excess of 90%.
>
>But my comment about surviving the voyage was referring to the
>expansion of mass as one increasingly achieves speeds closer and
>closer to that of light.
>
>This mass expansion seemed to me to be dangerous and I believe I
>communicated this concern to the professor. I believe he understood
>what I was concerned about and I believe his reply was meant to
>answer my question with regard to my concern.
>
The mass that you think would be dangerous is not.
If you where in a rocket without windows feeling an accleration of 1.1 G's you
would never even be able to tell if your going 1% the speed of light or 99.99%
the speed of light. Your concerns of the problem are false.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Tom)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Wed, 10 Nov 1999 05:05:52 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 9 Nov 1999 22:06:29 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: Tim Tyler wrote:
>:> In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>:> : The second rule apprears to be sufficient.
It is.
>:>
>:> To quote from: http://www.alife.co.uk/securecompress/
>:>
>:> ``This condition is necessary to prevent pathological cases: If "and" and
>:> "wander" are both words - and if "and" <=> "#" and "wander" <=> "&", then
>:> there is no chance that the string "w#er" will compress to "wander" - and
>:> then decompress to "&".''
>
>: But all these steps are reversible, so from & you can get back
>: your w#er, don't you?
Yes. Beware, the use of logic seems to be taken as hostile with this
group.
>
>The file is parsed from top to bottom. "wander" will be identified and transformed to
>"&" before the "and" in "wander" can be spotted. This causes problems.
The argument is one of why a particular type of compression, to be
reversible (satisfy rule #2), has to be symmetric ("o-o-o") to be
implemented. It's not an argument as to why o-o-o is required for
reversibility, unless you assume that this type of compression is
used.
You also have to swallow the argument that the claimed resistance to
brute force attacks is worth trading off against allowing chosen
plaintext attacks.
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 00:59:14 +0000
"Trevor Jackson, III" wrote:
> Randomness _implies_ incompressibility. They are not identical.
Hmm, you can convince me by giving an example of an incompressible
string that is not random.
> Properly, no string is a random string.
It is impossible to prove that a string is random, what do you mean with
"no string is a random string"?
> Randomness applies to the source or
> the selection process that generated the string rather than the output of of
> the generator. If you neglect this difference you get into the position of
> denying the randomness of "0000000000" because it can be compressed, in spite
> of the fact that you flipped the coins yourself.
So what is wrong with denying the randomness of "0000000000"?
It is quite possible to produce a *finite* non-random (sub)string with
a fair coin. On the other hand I don't believe it is possible to
produce an *infinite* non-random string by throwing a fair coin.
Your reasoning has some troublesome consequences. Say I have two
random sources. One "true" random source (TRNG), and one unreliable not
quite random bit string generator (URNG-generator). If both
sources produce "0000000000" then I would have to
acknowledge the randomness of the produced bit-string because
it is produced by TRNG and *at the same time* denying it because it
was also produced by URNG.
> You also have to defend the
> notion that the strings "1", and "0" are always random because they cannot
> ever be compressed.
Hmm, the compression argument itself seems to have been compressed
using a "lossy" compression method and therefore some information has
been lost ;-) Optimal compression of strings is computed + O(1),
you still need some Turing Machine (of size O(1))
to decompress your compressed string. It seems to me you can not
compress
both "0" and "1" but one of them can be compressed using the null string
as the input of your TM.
Regards,
Coen Visser
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Research suggestion?
Date: 11 Nov 1999 00:31:18 GMT
Rick Decker <[EMAIL PROTECTED]> wrote:
> Anyone have a suggestion for a research project that would be suitable
> for a semester-length project? My student is pretty quick, but the
> project need not lead to original results-- a new interpretation or
> tweak of an existing result would be satisfactory. The thesis is
> nominally in cs, but need not include a programming component.
The suggestions given here are all very good. Just in case you
would like other places to look for project ideas :
Kris Gaj has a list of projects in conjuction with his crypto course
at http://mason.gmu.edu/~kgaj/ECE590/project/project.html . These all
range more to the "applied" end of the spectrum, e.g. "Design a public
key infrastructure for your school."
You might also look at the topics of seminar series in crypto as a guide
to what kinds of things are out there. For example :
The MIT Crypto and Info Security group (tends to theoretical results) :
http://theory.lcs.mit.edu/~cis/cis-talks.html
Worcester Polytechnic Institute (Christof Paar, more hardware/applied) :
http://ece.wpi.edu/Research/crypt/seminar/index.html
Stanford (more "network security" talks) :
http://theory.stanford.edu/seclab/sem.html
------------------------------
From: JD <[EMAIL PROTECTED]>
Subject: Re: Re: How protect HDisk against Customs when entering Great Britain
Date: Thu, 11 Nov 1999 01:24:17 GMT
In article <[EMAIL PROTECTED]>,
this news group unless otherwise instructed! wrote:
> On 9 Nov 1999 01:45:29 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>
> >No. US law prevents you from taking any encryption, no matter where
you
> >got it, out of the US without a license.
>
> Does this mean that you can't take MSIE, Netscape, Opera, or a host of
> other SSL capable browsers out of the counrty? What about Outlook?
> Doesn't that have S/Mime?
>
> That's a pretty bold statment that you made, can you back it up?
Read the licenses that you agreed to when you purchased or downloaded
any of these software products. For example, in the "about:license"
URL of Netscape Navigator, section 10 reads, in part:
"If the Product is identified as being not-for-export (for example,
on the box, media or in the installation process), then, unless
Licensee has an exemption from the United States government, the
following applies: EXCEPT FOR EXPORT TO CANADA FOR USE IN CANADA BY
CANADIAN CITIZENS, THE PRODUCT AND ANY UNDERLYING ENCRYPTION
TECHNOLOGY MAY NOT BE EXPORTED OUTSIDE THE UNITED STATES ...."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 10 Nov 1999 20:23:31 -0500
Reply-To: [EMAIL PROTECTED]
Coen Visser wrote:
>
> "Trevor Jackson, III" wrote:
>
> > Randomness _implies_ incompressibility. They are not identical.
>
> Hmm, you can convince me by giving an example of an incompressible
> string that is not random.
>
> > Properly, no string is a random string.
>
> It is impossible to prove that a string is random, what do you mean with
> "no string is a random string"?
>
> > Randomness applies to the source or
> > the selection process that generated the string rather than the output of of
> > the generator. If you neglect this difference you get into the position of
> > denying the randomness of "0000000000" because it can be compressed, in spite
> > of the fact that you flipped the coins yourself.
>
> So what is wrong with denying the randomness of "0000000000"?
> It is quite possible to produce a *finite* non-random (sub)string with
> a fair coin. On the other hand I don't believe it is possible to
> produce an *infinite* non-random string by throwing a fair coin.
> Your reasoning has some troublesome consequences. Say I have two
> random sources. One "true" random source (TRNG), and one unreliable not
> quite random bit string generator (URNG-generator). If both
> sources produce "0000000000" then I would have to
> acknowledge the randomness of the produced bit-string because
> it is produced by TRNG and *at the same time* denying it because it
> was also produced by URNG.
You're still missing the point.
Both TRNGs and URNGs are given the modifier "random" because
"random" applies to the -generators- and not the -strings-.
> > You also have to defend the
> > notion that the strings "1", and "0" are always random because they cannot
> > ever be compressed.
>
> Hmm, the compression argument itself seems to have been compressed
> using a "lossy" compression method and therefore some information has
> been lost ;-) Optimal compression of strings is computed + O(1),
> you still need some Turing Machine (of size O(1))
> to decompress your compressed string. It seems to me you can not
> compress
> both "0" and "1" but one of them can be compressed using the null string
> as the input of your TM.
You need strings to define the TM, so the TM can be reduced to {},
and you're left with "1" as incompressible.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
