Cryptography-Digest Digest #249, Volume #9 Thu, 18 Mar 99 18:13:03 EST
Contents:
Re: What is the MAC. ?? (Christoph Haenle)
Re: Another Q. What is CRT? (Paul Schlyter)
Re: One-Time-Pad program for Win85/98 or DOS (Jim Dunnett)
Re: One-Time-Pad program for Win85/98 or DOS (R. Knauer)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (John Savard)
RC6 (Piotr Mroczkowski)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Jim Gillogly)
Scramdisk on a floppy (Anonymous)
Re: DIE HARD and Crypto Grade RNGs. (Coen Visser)
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (John Savard)
Re: Paper on Guillo-Quisquater zero-knowledge algorithm wanted (Bruce Schneier)
----------------------------------------------------------------------------
From: Christoph Haenle <[EMAIL PROTECTED]>
Subject: Re: What is the MAC. ??
Date: Thu, 18 Mar 99 18:44:51
ZinHa ([EMAIL PROTECTED]) wrote:
: I read about "MAC"..
: Of course, It does not mean "Mac PC" made by APPLE Co.
: It called Multiplication..?????
: I can't get any other informations about it.
: Please let me know "MAC" include Web site possible.
: Any help will be thanks. please.
MAC means message authentication code and is a function which takes a
symmetric key and a message (encrypted or not) and computes a digest
used for integrity check. The MAC has properties similar to hash
functions, but also involves a shared secret (symmetric key), so that
as a result, a MAC can only be generated by the parties who know the
key. Unlike public key signatures, the MAC can not be used for
non-repudiation, since it involves a symmetric key which is shared by
two (or more) parties, and a judge has no way of knowing which party
produced the digest.
-Chris.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Another Q. What is CRT?
Date: 18 Mar 1999 20:16:00 +0100
In article <7cquht$pjt$[EMAIL PROTECTED]>, ZinHa <[EMAIL PROTECTED]> wrote:
> I also read about "CRT:Chinease Remainder Theorem".
> I know what is this algorithm.
> But, Is it important in cryptography? WHY?
> Many crypto-system contain information about CRT.
> I can't understand why is important???
CRT is used in RSA cryptography to encrypt faster with the
secret key. Instead of doing
d
M = C mod N
where N is the full-length modulus, you can use a more complex
algorithm which turns out to be 3-4 times faster. This can only be
used on the secret key since it requires knowledge of the factors of N:
N = p * q
where p < q. You must also know, or compute, u where u * p mod q = 1
Now you compute:
d d
e1 = C mod p och e2 = C mod q
e3 = u * (e2 - e1) mod q
M = e3 * p + e1
This replaces the modular exponentiation with the full-length modulus
N with two modular exponentiation with half-length moduli p and q
(the execution time of the extra additions and multiplications are
here insignificant). Since an exponentiation with half-length
modulus is some 8 times faster than an exponetiation with a
full-length modulus, this operation will be considerably faster
than a straight-forward exponentiation with the full-length modulus.
Another way to speed up RSA encryption is to use Montgomery
multiplication instead of normal modular multiplication when
computing the modular exponent. Montgomery multiplication can
be some 2-3 times faster than normal modular multiplication.
If you use both the CRT theorem and Montgomery multiplication,
you'll speed up the RSA computation with approx. a factor of 10.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Crossposted-To: alt.security,alt.privacy
Subject: Re: One-Time-Pad program for Win85/98 or DOS
Date: Thu, 18 Mar 1999 20:40:25 GMT
Reply-To: Jim Dunnett
On Wed, 17 Mar 1999 23:04:53 GMT, [EMAIL PROTECTED] (R.
Knauer) wrote:
>On Wed, 17 Mar 1999 21:18:13 GMT, [EMAIL PROTECTED] (Jim
>Dunnett) wrote:
>
>>>What you need for a totally secure OTP is a 100% unpredictable block of
>>>data.
>
>>Is that possible? Given a large block of data you're bound to be
>>able to predict the next number quite a few times.
>
>Please tell us how you are able to do that.
Law of averages I suppose. In a million or so bytes it would
be easy to predict, i.e. guess the next byte more than just
a few times.
--
Regards, Jim. | Der Staat wird nicht 'abgeschaft',
olympus%jimdee.prestel.co.uk | er stirbt ab.
dynastic%cwcom.net |
nordland%aol.com | - Friedrich Engels, 1820-1895.
marula%zdnetmail.com |
Pgp key: pgpkeys.mit.edu:11371
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Crossposted-To: alt.security,alt.privacy
Subject: Re: One-Time-Pad program for Win85/98 or DOS
Date: Thu, 18 Mar 1999 20:50:14 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 18 Mar 1999 20:40:25 GMT, [EMAIL PROTECTED] (Jim
Dunnett) wrote:
>>>Is that possible? Given a large block of data you're bound to be
>>>able to predict the next number quite a few times.
>>Please tell us how you are able to do that.
>Law of averages I suppose. In a million or so bytes it would
>be easy to predict, i.e. guess the next byte more than just
>a few times.
It is true that a given sequence that you guess will occur sometime in
a long enough string - but the problem is that you don't know where it
will happen, so your guess is ineffective.
Anyway guessing does not count for the OTP system. Do you know why?
Bob Knauer
"Every government always exercises the maximum amount of power its
rulers feel the people will stand for without revolting."
-- Alongside Night
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Thu, 18 Mar 1999 20:58:07 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>Yes, certainly the open crypto community doesn't currently have
>ultimate solutions to all our crypto needs. If I were king,
>nobody would be allowed to work on creating crypto systems until
>after he has cracked several really tough ones.
But that might leave us bereft of possible solutions - unless the home of
such expertise deigned to bless us with something like Clipper. Yes, some
people in the academic community do have such experience - but that is
partly due to the existence, in the first place, of systems invented in
violation of that dictum.
Since the negative approach isn't possible anyhow, I favor distilling the
knowledge gained from cryptanalysis in a form which could be utilized by
the intelligent layperson to design secure ciphers within a general set of
guidelines and constructs.
Ultimately, the idea is that interested parties will have the option open
to them of packing their own parachutes: protect your own data with your
own algorithm. I know, I may be an impractical dreamer...and the notion
applies only to conventional, secret-key algorithms in any case.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Piotr Mroczkowski <[EMAIL PROTECTED]>
Subject: RC6
Date: Thu, 18 Mar 1999 22:16:26 +0100
I'm interesting in hardware implementation of RC6 using ALTERA
If everybody can help me, please send me e-mail:
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Thu, 18 Mar 1999 20:49:00 +0100
Patrick Juola wrote:
>
> You're displaying an appalling ignorance of what can and cannot
> be done w.r.t. the measuring of Kolmogorov compleixty. There's
> a very good paper by Chris Hillman available on the Web, with the
> title "All Entropies Agree For A Set" (to which I refer you).
> I take the liberty of quoting :
>
> "It is obviously very difficult to compute [the Kolmogorov
> complexity of a string x] directly from the definition. Indeed,
> the algorithmic complexity of a string is uncomputable in the
> technical sense that there exists no algorithm which, when run with
> any finite string s as input, is guaranteed to terminate in a
> finite time with output Ku(s). However, this does not imply that
> one can *never* [emphasis original] find exact values or even sharp
> estimates of complexity."
>
> He then goes on to discuss how, for instance, the K-complexity of
> a typical string generated by a Bernoulli process agrees "pretty
> nearly" (his words) with the Shannon-entropy of the source -- and
> indeed with several other formalism of the "entropy" of a dynamic
> system.
Please give the URL. Perhaps I may ask a question concerning
to the last paragraph. Does this mean that in the case of strings
generated by a Bernuoulli process one DOES have an algorithm to
compute the Kolmogorov complexity? Is that algorithm explicitly
given in that paper so that one can actually do the computation?
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Thu, 18 Mar 1999 13:49:36 -0800
Reply-To: [EMAIL PROTECTED]
John Savard wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>
> >Yes, certainly the open crypto community doesn't currently have
> >ultimate solutions to all our crypto needs. If I were king,
> >nobody would be allowed to work on creating crypto systems until
> >after he has cracked several really tough ones.
>
> But that might leave us bereft of possible solutions - unless the home of
> such expertise deigned to bless us with something like Clipper. Yes, some
> people in the academic community do have such experience - but that is
> partly due to the existence, in the first place, of systems invented in
> violation of that dictum.
Not necessarily. A lot of people have worked on the Zendian Problem,
which includes a number of what I would consider pretty tough ones.
So far as I can tell nobody has put up a web site that spoils these
problems, so <lots> of people can crack them and gain the requisite
experience. If those aren't deemed tough enough, similar training
sets could be created based on more modern crackable systems or their
analogues... perhaps as a final exam for Schneier's cryptanalysis
course at Counterpane.
I agree with Doug that you can't have an appreciation for possible
holes in your own cipher if you haven't spent a lot of time trying
to dig them in others'.
--
Jim Gillogly
26 Rethe S.R. 1999, 21:44
12.19.6.0.11, 6 Chuen 4 Cumku, Second Lord of Night
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Scramdisk on a floppy
Date: Thu, 18 Mar 1999 21:30:39 +0100 (CET)
It is possible to load the Scramdisk driver when Windows is
already running by calling the Windows API CreateFile function.
This can be useful when you want to use SD on a machine on
which you do not have sufficient priviledges to install it or if you
have other reasons for not wanting SD installed.
The best way to call the CreateFile function is from a simple loader
program - see a C++ example bellow. (If you are tempted to call it
using the rundll32.exe be warned that accessing the kernel via
rundll32 can have disasterous consequences, even renderring
Windows un-bootable and unrepairable - speaking from
experience!).
The only difference that I have observed when loading the driver this
way is that when you mount a drive, you will get a warning that SD
is not able to determine the nature of the drive (it does not know
whether it is a floppy, a hard drive, or whatever). This does not
seem to have any adverse effects on the performance of the
program.
The SD exe file compresses very well with the ASPack exe
compressor (do not have the URL, but you should find it on
www.nonags.com), so that it is possible to have a fully functional
SD setup on a single floppy (the driver, the exe, the loader + 1MB
volume file), to cary around your Swiss bank account no. :).
Nemo
@Nautilus.sub somewhere of the coast of ...
=================================================
C++ code example
=================================================
#include <windows.h>
int WINAPI WinMain(
HINSTANCE /*hInstance*/, // not used
HINSTANCE /*hPrevInstance*/, // not used
LPSTR /*lpszCmdLine*/, // not used
int /*nCmdShow*/ // not used
)
{
//the CreateFile bellow will load the VXD if not already loaded,
//if already loaded it will return a valid handle
//(SD.VXD should be located in the same dir as this program)
if(CreateFile("\\\\.\\SD.VXD", 0, 0, 0, 0, 0, 0) !=
INVALID_HANDLE_VALUE)
{
//if you want a specific file to be mounted when SD is loaded
//modify the command line below to something like
// "Scramdisk.exe myfile.svl"
WinExec("Scramdisk.exe", SW_SHOWNORMAL);
}
else MessageBox(0, "Sorry, could not load SD.VXD", "Error",
MB_OK);
return(0);
};
------------------------------
From: [EMAIL PROTECTED] (Coen Visser)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 18 Mar 1999 21:51:58 GMT
[EMAIL PROTECTED] writes:
>[EMAIL PROTECTED] (Coen Visser) wrote:
>>Not for every 1-string. Consider 1^n (n repetitions of 1's) with
>>n incompressible.
>
>For a sequence (run) of 1's of length N, one can write the algorithm:
>for (int i=0; i<N;i++) putchar("1");
> which will reproduce the original sequence in entirety.
>All the code for that fragment, except for the actual representation
>of N, is of O(1).
>The number N can be represented as a binary sequence of length
>log2(N). Therefore the entire code fragment is of size = log2(N) +
>O(1), which is considerably smaller in size than the original sequence
>of length N. For example, a sequence of 1 million (decimal) 1s, the
>size of the binary representation of N is only about 20 bits.
That is the 'trivial' compression. My point was that for large N, say
a thousand bits, N itself might be (in)compressible. So you can not say
in general that you can approximate the K-complexity of a 1-string.
Because you have to take into account the (in)compressibility of N too.
>IOW, the algorithm has "compressed" the original run of N 1's by a
>logarithmic amount plus a small constant amount of order 1.
[...]
>The term of order unity, O(1), is small compared to the length of the
>original sequence, N, for large N. In Chaitin's modified lisp, it is
>of order a few hundred to a few thousand bytes depending on the
>overhead of his interpreter. In any event, it is pretty much a
>constant once the unversal computing machine is decided.
Ah, I was not aware of the magnitude of the constant. It is not
extremely big, but for the discussion a few hundred to a thousand
bytes is too much for a good approximation. Just look at the 1-string
example. If length(N) is 1000 bits it might be possible to compress it. But
the O(1) factor defeats approximation of its K-complexity.
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Thu, 18 Mar 1999 22:28:50 GMT
Reply-To: [EMAIL PROTECTED]
On 18 Mar 1999 21:51:58 GMT, [EMAIL PROTECTED] (Coen Visser)
wrote:
>That is the 'trivial' compression. My point was that for large N, say
>a thousand bits, N itself might be (in)compressible. So you can not say
>in general that you can approximate the K-complexity of a 1-string.
>Because you have to take into account the (in)compressibility of N too.
Hmm... log log compressibility, eh. I gotta admit that is some
compression.
You would have to decompress the compression of N to implement the
algorithm that reproduces the original sequence, and that entails
additional code. But I get your point that for some sequences, not
only the sequence but also its length can be compressed significantly.
>Ah, I was not aware of the magnitude of the constant. It is not
>extremely big, but for the discussion a few hundred to a thousand
>bytes is too much for a good approximation. Just look at the 1-string
>example. If length(N) is 1000 bits it might be possible to compress it. But
>the O(1) factor defeats approximation of its K-complexity.
The term of order unity, O(1), can be made arbitrarily small based on
the universal machine chosen. That is the main point, not its
comparison to the length of some particular sequence.
Bob Knauer
"Every government always exercises the maximum amount of power its
rulers feel the people will stand for without revolting."
-- Alongside Night
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Thu, 18 Mar 1999 20:47:51 GMT
[EMAIL PROTECTED] (Mark Currie) wrote, in part:
>In order to prevent reliance on
>public key schemes entirely, you would have to maintain a traditional secret
>key management scheme.
Yes, you understand me correctly.
The use of KEA with FORTEZZA at least appears to indicate that the NSA now
trusts public key methods - with *unclassified*, but sensitive,
information. The costs of traditional key distribution probably are not
prohibitive for the protection of all (or some) classified material.
I suspect that they have at least considered the idea of hybrid key
management of the general form I advocated, although doubtless they viewed
it in terms of alternatives beyond anything I could imagine.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Paper on Guillo-Quisquater zero-knowledge algorithm wanted
Date: Thu, 18 Mar 1999 22:22:10 GMT
On 16 Mar 1999 04:10:04 GMT, [EMAIL PROTECTED] (S.T. Wong)
wrote:
>Hello,
>
>I'd like to know if the following paper is available online :
>
>Louis C. Guillou and Jean-Jacques Quisquater.
>A practical zero-knowledge protocol fitted to security microprocessor
>minimizing both transmission and memory.
>In Christoph G. Günther, editor, Advances in Cryptology -- EUROCRYPT 88,
>volume 330 of Lecture Notes in Computer Science, pages 123-128.
>Springer-Verlag, 25-27 May 1988.
>
>Would anyone please help ?
If it's available online, then it is indexed on my 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
------------------------------
** 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
******************************
