Cryptography-Digest Digest #117, Volume #9 Sun, 21 Feb 99 17:13:03 EST
Contents:
Re: That 16-Year Old's "New" Cipher ("hapticz")
Re: 16 bit TwoFish (Bruce Schneier)
Re: Bruce's Feb. "CRYPTO-GRAM" (Bruce Schneier)
I need help with the decryption of a file (Mousie6062)
Re: Testing Algorithms (Withheld)
Re: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
Re: Bigger variables... ("D")
Re: Another extension to CipherSaber (Paul Crowley)
Re: Scramdisk File (Gregg Berkholtz)
Re: I need help with the decryption of a file (Michael Sierchio)
Re: 640-bit Modulus Factored. (Ted Kaliszewski)
Public key algorithms ("Alan Kelly")
Re: SkipJack vs RC2 ("jmp")
Re: I need help with the decryption of a file ([EMAIL PROTECTED])
Re: Randomness of coin flips (Herman Rubin)
Re: Snake Oil (from the Feb 99 Crypto-Gram) (Lutz Donnerhacke)
Re: Another extension to CipherSaber (Bauerda)
----------------------------------------------------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Re: That 16-Year Old's "New" Cipher
Date: Sun, 21 Feb 1999 10:38:38 -0500
maybe it/she got +ACI-swallowed up+ACI- by the secrecy police+ACE- ne'er to be
seen/hear from again+ACE-
kinda reminds me of scenarios unheard of in real life, eh?
--
best regards
hapticz+AEA-email.msn.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: 16 bit TwoFish
Date: Sun, 21 Feb 1999 16:09:04 GMT
On Sat, 20 Feb 1999 22:28:11 GMT, [EMAIL PROTECTED] wrote:
>Has anyone here compiled the TwoFish (optimised) code
>for 16 bit Windows ?
>If so, were there any problems ? What compiler did you use ?
I have not seen a version optimized for 16-bit computers. If someone
has one, I would like to put it up on the website.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Bruce's Feb. "CRYPTO-GRAM"
Date: Sun, 21 Feb 1999 16:11:29 GMT
On Sat, 20 Feb 1999 02:12:26 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>Last I read, some of the statements suggestive of snake oil that might be
>made by someone might also be honest claims, whether or not they were
>backed up at the time. Sometimes, truth is strong enough that it is not
>easily accepted; And, of course, plainly misleading statements gather no
>moss, or something like that.
Of course. Sometimes snake oil is actually good; it just takes time
before it is trusted. I recently consulted with a client who had a
proprietary cipher. They believed that it was strong, and possibly it
was. My advice was: "We can evaluate it for you, but the best we will
say is that we've spent several weeks analyzing the cipher, we cannot
break it and we cannot imagine how anyone else would, but you should
take it out of your system immediately and replace it with something
known and trusted."
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Mousie6062)
Subject: I need help with the decryption of a file
Date: 21 Feb 1999 16:34:38 GMT
Greetings Everyone.
I am a 17 year old college student in England, who desperately needs someone to
help me decrypt a file that was sent to me. The sender was a 31 year old
computer hacker who is very good. Unfortunately, I do not have any decryption
software left after it was taken off me by the police for some unknown reason.
If there is anyone out there who can help me, please email me on
[EMAIL PROTECTED]
Any help would be fabulous, cos I desperately want to know what this guy has to
say to me.
I do not know what type of encryption has been used, so somebody help!!!
CatchY'all later
TeknoTron
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
Date: Sun, 21 Feb 1999 16:37:52 +0000
Reply-To: Withheld <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> writes
>
>
>Vegeta-the original Super Saia-jin wrote:
>>
>> No, in that all forms of cryptography have finite life span and no matter
>> how strong they can be defeated in time.
>>
>> As far as speed goes, the faster the processor the faster the algorithm
>>
>> As far as security goes, key length helps, but it won't make it secure, I
>> think that DES proves that, it's a joke, and a bad one at that.
>>
>
>So you think a 256 bit key will eventually be brute forced?
>
Given enough processor power, yes. Current calculations are frequently
based along the lines of "Testing 1000000 keys per second would take x
billion years to brute-force it". If you can increase the number of keys
per second enough, you can brute force it in sensible time.
--
Return address removed for anti-spam purposes.
Email replies to news at maelstrom dot demon dot co dot uk
Email replies to this address may be copied to relevant newsgroups
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
Date: 21 Feb 99 16:39:51 GMT
[EMAIL PROTECTED] wrote:
: BTW, this further shows why unicity cannot
: defined by the condition of "zero key equivocation" alone -- here, we have
: zero key equivocation for one intercepted letter but not zero message
: equivocation and thus no unicity.
There is indeed zero message equivocation. We know, for a fact, that the
message is the letter "C".
Certainly, we can define a concept *similar* to unicity, which tells us
how much unenciphered English text we need, on average, to identify words
unambiguously, and get the sense of the text we see.
But that is a separate concept from unicity.
You *are* correct, though, that unicity depends on the language of the
message, and not just on key length and encipherment. It is because the
language used has redundancies that, given a large possible number of
keys, only one of the associated decipherments is a possible message.
When there is no encipherment, there is no task of picking the correct
message out from competing garbage - even if one isn't certain the letter
C really is part of English text. Saying that plugging numbers into the
unicity formula blindly will, in some cases, yield unmeaningful results is
one thing, and you would be correct if you said that. Saying that the
unicity formula does (or should) deal with the case you give as an
example, however, is incorrect. Such a formula would be unwieldy.
John Savard
------------------------------
From: "D" <[EMAIL PROTECTED]>
Subject: Re: Bigger variables...
Date: Sun, 21 Feb 1999 12:48:30 -0500
What I'm talking about would increment the running key after each block and
have more operations than just xors, like one op could be a backwordization
of some plaintext bits
bak p,2-13 (bits 2-13 would become bits 13-2)
or moving bits around
mov p,8-12 to 5
or multiplying with keybits
mul p,2-7 k,8-12
This would define a different cipher for each block and could additionally
be dependant on cfb
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Another extension to CipherSaber
Date: 21 Feb 1999 14:29:23 -0000
Anonymous <[EMAIL PROTECTED]> writes:
> Another improvement I implemented consists of a second number, which I
> call the "discard count." It is a 32-bit value that specifies how many
> cipher bytes to discard before beginning to encipher/decipher. I suppose
> this number is a "key" of sorts as well. It would seem to make the
> searchable keyspace larger by a factor of 2^32, assuming you were choosing
> "discard counts" that used the full span from 0 to 2^32-1.
>
> Intuitively I cannot see that this weakens CipherSaber in any way.
> Comments? Thoughts?
I made pretty much this very suggestion to the CipherSaber author.
We concluded that it's not a good idea to treat it as part of the key;
it's better to treat it as a kind of key stretching. Two plausible
options are:
(a) put this count in the message as plain text.
(b) make it always a power of two >= 256, encode it nowhere, but start
the message with a block of eight zeroes so you can tell when you've
found it. That way, discarding a wrong key is more expensive than
using a right one.
Suggestions?
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
From: Gregg Berkholtz <[EMAIL PROTECTED]>
Subject: Re: Scramdisk File
Date: Sun, 21 Feb 1999 08:40:56 -0800
I hope this is not the start of a flame because I made a typo the message.
What I meant to say was that the file was created with a specfied size of 1024
Mb (1Gb).
The disk that I store the file on is nearly full and there is no space to make
a backup (as I have done with my other scramdisk files).
Application development does eat alot of disk space. That is why I have the
tape drive.
Regards
Gregg Berkholtz
hapticz wrote:
> with all that gig space on yer hard drive, why the hay didn't you have a
> backup of the scramfile itself? and you actually have customers??
>
> it's time fo ryou to re-evaluate your basic operating procedures, not just
> slap on a backup tape unit!!
>
> --
> best regards
> [EMAIL PROTECTED]
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: I need help with the decryption of a file
Date: Sun, 21 Feb 1999 10:27:50 -0800
Reply-To: [EMAIL PROTECTED]
Mousie6062 wrote:
> ...Unfortunately, I do not have any decryption
> software left after it was taken off me by the police for some unknown reason.
I *hate* it when that happens...
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: 640-bit Modulus Factored.
Date: Sun, 21 Feb 99 13:36:43 -0500
The answer is, at present: nil! I made it quite clear that the method I am
now exploring is working only ( and then, not always) for moduli that are
pseudoprimes and, especially, strong pseudoprimes. I have used both the
Cipolla's and Jaeschke's algorithms to compute such moduli and, definitely,
not to dazzle anyone but simply to point the rather amazing nature of this
restricted solution. Perhaps, with luck I may still discover a simple
method of factoring a general class of moduli (your example) that will
not require mobilizing half of the academia and most of the working
computers for its solution. Wish me luck!
------------------------------
From: "Alan Kelly" <[EMAIL PROTECTED]>
Subject: Public key algorithms
Date: Sun, 21 Feb 1999 19:09:13 -0000
Does anyone know where I can get some source code for a public key
encryption algorithm, or at least some good information so that I can
implement my own?
Many thanks in advance
------------------------------
From: "jmp" <[EMAIL PROTECTED]>
Subject: Re: SkipJack vs RC2
Date: Sun, 21 Feb 1999 11:48:02 -0500
to j. savard:
j. savard writes:
After visiting AltaVista, I find that Dr. Rivest disclosed RC2 in an
Internet Draft recently. I hadn't realized that.
The specification is available at:
http://www.jya.com/rc2.htm
It's an interesting design. As I understand it, it makes use of the
following manipulations:
producing a value to XOR with one quarter of the block via an ICE-like
bit selection technique;
XORing in key material with the block in a fixed sequence;
Data-dependent rotations;
and
XORing in key material selected by bits from another quarter of the
block.
Except for the use of one bijective S-box consisting of 256 entries, I
do not see a resemblance to SKIPJACK. (BTW: it's SKIPJACK or Skipjack;
a skipjack is a kind of boat used to trawl for lobsters or something.)
John Savard
http://members.xoom.com/quadibloc/index.html
to j. savard:
the only use of a table in RC2 is to 'expand' the key entered by the user,
not for substitutions. Skipjack DOES use a S-box. that is NOT the similarity
i notice.
i point to the fact that one uses a real 'shift' structure and the other an
'implied' shift structure. both using 16-bit sub-blocks. this is not a big
deal, but i wonder about it since Skipjack was announced after the NSA saw
Rivest's RC2 for export consideration. if anybody did the borrowing it was
the NSA.
jmp
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I need help with the decryption of a file
Date: Sun, 21 Feb 1999 20:01:34 GMT
On 21 Feb 1999 16:34:38 GMT, [EMAIL PROTECTED] (Mousie6062) wrote:
>Greetings Everyone.
>
>I am a 17 year old college student in England, who desperately needs someone to
>help me decrypt a file that was sent to me. The sender was a 31 year old
>computer hacker who is very good. Unfortunately, I do not have any decryption
>software left after it was taken off me by the police for some unknown reason.
>If there is anyone out there who can help me, please email me on
>[EMAIL PROTECTED]
>Any help would be fabulous, cos I desperately want to know what this guy has to
>say to me.
>I do not know what type of encryption has been used, so somebody help!!!
Good God, AOL overseas. A whole new world of clueless to dump on the
Internet.
There is no hope.
--
ClassAct
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Randomness of coin flips
Date: 21 Feb 1999 16:47:29 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 20 Feb 1999 08:08:39 -0500, [EMAIL PROTECTED] (Herman
>Rubin) wrote:
>>>The concept of True Randomness we are using here on sci.crypt comes
>>>from crypto itself. A True Random Number is one that is produced by a
>>>True Random Number Generator (TRNG), which is a process that is
>>>capable of generating all possible finite sequences equiprobably.
>>If this is your definition,
>It is not MY definition - it is the definition of those on sci.crypt
>who participated in the discussions about crypto-grade randomness a
>year ago and recently. It is the result of a prevailing consensus
>gleaned from a set of threads that ran over a thousand posts and drew
>wide ranging participation.
It is possible to define anything in mathematics. This does not
mean it exists in the real world.
>BTW, since you are a statitician, maybe you can comment on this: How
>does that definition above differ, if any, from a Uniform Bernoulli
>Process (i.e., p = 1/2)? For some reason that I cannot recall, the UBP
>was rejected as a definition for a TRNG.
A Bernoulli process need not have p=1/2. But does that mean that
there is such an attainable animal? One can come close; this is
what I have been pointing out. And as there are things that can
go wrong, it is necessary to test for them.
>Remember that the term "TRNG" as used here applies only to
>crypto-grade randomness, not the notions of randomness in other
>fields. For example, algorithmic complexity randomness does not apply
>to crypto, since it distinguishes between "regular" and "irregular"
>strings, whereas there is no such distinction in crypto.
It is possible to get crypto-grade randomness without the existence
of a TRNG being possible. It is hard to get full channel capacity,
and a slight deviation from true randomness is acceptable.
That one has a low probability that the interceptor will be able
to figure out the message does not mean it should not be tested.
While all 0's, or even 90% 0's, is unlikely, a human has an
excellent chance of reading the message if such is used.
>> it is in the same class as the
>>frictionless bearing, the perfect engine, and other such
>>entities which are ideals only, and cannot exist in reality.
>According to that there could never be a wheel, since a Perfect Circle
>cannot exist in reality. In fact a Perfect Circle cannot even exist
>mathematically, since there are infinitely many points on the locus
>that are uncomputable.
A wheel does not have to be perfect to work. Neither does a TRNG,
or even a PRNG, have to be perfect to accomplish the job. Testing
TRNGs is likely to be easier than PRNGs, because physical processes
are not going to have long-range dependencies. However, physical
processes are not perfect.
>There are TRNG designs, complete with audits and diagnostics, which
>can produce crypto-grade random numbers. One such set are based on
>Quantum Mechanical measurements, and are as secure as you want to make
>them if you are willing to expend the effort to do so.
It still requires testing to make sure that the devices work.
>Crypto-grade security does not require 100.0 % security, since in the
>real world work effort and the amount of information leakage need to
>be taken into account. If you can demonstrate that a TRNG is secure to
>a level sufficient to meet the needs of the cryptosystem it will be
>used with, then that is secure in the sense of crypto-grade security.
>If you can demonstrate that, then you have a proveably secure system,
>even if the proof involves experimental tests.
But this requires testing. It also is not a TRNG as some, including
yourself, have specified. I believe that a RNG for cryptographic
purposes need not be as good as for statistical purposes, as the
message itself is not as regular as simulation conditions. If the
message does not have the same type of peculiarities as the RNG,
the combination will be hard to crack, and a slightly increased
proportion of 1's will not compromise the security.
>After all, the goal of crypto it to prevent a crypanalyst from
>decrypting your messages, and if that can be accomplished with even a
>small amount of information leakage, that is good enough. That's the
>same design philosophy for making wheels that work in the real world,
>despite the fact that a Perfect Circle does not exist.
>>The best one can do is to produce ways of generating information
>>by physical processes which is close, and to test for the
>>operation of Murphy's Law.
>Is that your notion of how experimental science works?
>What if there is no exhaustive set of tests for every possible
>instance of Murphy's laws? In fact it is a tenent of probability
>theory that you cannot apply all statistical tests on any given
>number, since there is no number that can pass all statistical tests
>for pseudo-randomness (cf. Li & Vitanyi, op. cit.).
Of course there is no such thing. But one can come up with a fair
number of them adequate for SOME testing. And XORing the results
of different generated threads at different times should be much
safer than the output of one physical device producing one series.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: Snake Oil (from the Feb 99 Crypto-Gram)
Date: 21 Feb 1999 19:34:55 GMT
* Mark Andreas wrote:
>Bruce Schneier wrote:
>> Some companies claim "military-grade" security. This is a meaningless
>> term. There's no such standard. And at least in the U.S., military
>> cryptography is not available for non-government purposes (although
>> government contractors can get it for classified contracts).
>
>The first time I remember seeing this phrase was when using the
>command-line version of PGP 2.6 using the -kg switch to generate a key.
>Choice #3 was:
That's why PGP 2.6.3(i)n changed this to:
1024 bit - User grade
1535 bit - SubCA and RA grade
2048 bit - CA grade
------------------------------
From: [EMAIL PROTECTED] (Bauerda)
Subject: Re: Another extension to CipherSaber
Date: 21 Feb 1999 19:47:44 GMT
>Another improvement I implemented consists of a second number, which I
>call the "discard count." It is a 32-bit value that specifies how many
>cipher bytes to discard before beginning to encipher/decipher. I suppose
>this number is a "key" of sorts as well. It would seem to make the
>searchable keyspace larger by a factor of 2^32, assuming you were choosing
>"discard counts" that used the full span from 0 to 2^32-1.
Actually, it would increase the key space by much more than that because of
the slowdown of discarding millions of bytes before getting to check and see if
the key is correct. It would, however, be decected by a timing attack:
differences of a few seconds is easy to notice.
A different option would be to just discard a set number of bytes, 65536,
1048576, or more to just slow down a key search on the current key-space.
David Bauer
------------------------------
** 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
******************************
