Cryptography-Digest Digest #930, Volume #8 Tue, 19 Jan 99 09:13:04 EST
Contents:
Re: Export laws (wtshaw)
simple symetric encrypt <-> decrypt ("Daniel Feurle")
Re: Export laws (Gurripato (x=nospam))
Re: SSL - How can it be safe? (Gurripato (x=nospam))
Re: sci.crypt intelligence test. (Terje Mathisen)
Re: Metaphysics Of Randomness (Coen L.S. Visser)
steganography algorithm? (Uri Fridman)
Re: Some Thoughts on the Design of a Proposed Stream Cipher (Mok-Kong Shen)
Re: Question on current status of some block ciphers in AC2 (David Hamilton)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: long numbers math - how to ? ("Pedro F�lix")
Re: Metaphysics Of Randomness (R. Knauer)
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Export laws
Date: Tue, 19 Jan 1999 01:22:50 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
> Bill Unruh wrote:
> >
> > The legislation is already there, under the export regulations. It is
> > illegal to export certain things without a license. ....
>
> Regulations are not laws. Until they have been tested in court, they
are not even reliable
> guides to behavior. Statutory law is much more reliable than regulatory
"law".
Too often regulations are done as a sort of wish-list. Getting Congress
to grant authority to allow this means taking advantage of them, and they
should revisit situations where authority has been exceeded, but they
might have to consider there own abuse of it also.
It is better that regulations be sunseted in short order if not soon
replaced with statutes that spell things out. If regulations are too
detailed to have this done, probably they should not exist in the first
place. If regulations cannot pass as laws, then they should be nullified.
--
Clinton should have been a Tobacco Company President, one of
thoses that got a pass for purjury. Who knows the millions of people who will die
because they were part of a conspiracy to hide the truth. They benefit from the
protection they paid, the bribes
commonly called political contributions. Put current events in
prospective, and consider the hypocracy of Congress in all this.
------------------------------
From: "Daniel Feurle" <[EMAIL PROTECTED]>
Subject: simple symetric encrypt <-> decrypt
Date: Tue, 19 Jan 1999 10:18:22 GMT
Have anyone of you an idea how i can encrypt and decrypt a simple
integernummer.
with a symmetric cryptosystem and without using -> x mod m
modulo???
example: 1234 -> encrypt -> (like) 3121239 -> decrypt -> 1234
I'm looking forward to hear from anyone!
TX
Dan
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: Export laws
Date: Tue, 19 Jan 1999 08:08:35 GMT
On Sun, 17 Jan 1999 22:15:33 GMT, [EMAIL PROTECTED] (Stephen
Darlington) wrote:
>On Sat, 16 Jan 1999 11:41:18 GMT, [EMAIL PROTECTED] (Bruce
>Schneier) wrote:
>
>>When someone (presumably outside the US) tries to download the file,
>>he is not doing anything illegal. (Unless, of course, he lives in a
>>country that believes US laws apply on non-US soil.) The owner of the
>>website is exporting the software (we think...this has never been
>>tested in court. I believe he is not exporting, but that's just me.)
>
Make it two. If export means "take out something out of the
country", the website owner cannot be thought of as the exporter. It is
the importer (the guy downloading the file) who is exporting the file
out of the US, and importing it into his country.
It�s like you park a car in north Wisconsin. If somebody gets
into it and drive it north to Canada it�s he who is "exporting" the car,
not you. The US website owner just puts some files on a US server,
he/she doesn�t "export" anything. Of course, the US law enforcement
bodies would prefer that the owner be held responsible for the export,
for then they could prosecute him/her.
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: SSL - How can it be safe?
Date: Tue, 19 Jan 1999 08:20:23 GMT
On Tue, 19 Jan 1999 01:30:10 GMT, [EMAIL PROTECTED] wrote:
>So any site that has SSL has to have the CA send out their public key? It
>sounds like the browser has the CA's public key embedded in it's binary at
>compile time also?
>
>> No, it is the data encryption key that is 40/128 bits. The public key
>> used for master key transport or agreement is much longer, 512/1024
>> bits. The international version is limited to a 512-bit key by the
>> U.S. export regulations.
>
>Ok, I think I need to do some reading on PKI then. If the first packet is
>encrypted with 512bit, how does that make it "easier" for the govt to break
>it? I always assumed that the 40bit (international) version was 40bit because
>it was easy for the feds to break, but if they have to get through a 512bit
>layer first, that seems to be sufficient enough security.
>
40 bit refers to symmetric algorithm (RC4) and 512 refers to
asymmetric (RSA) key.
But now that you mention, I have a doubt. Fortify patches
(www.fortify.net) allow the browser to use SSL with 128 (RC4) or 168
(3DES) symmetric bit encryption. But it doesn�t say anything about the
asymmetric key strength. Does anybody know the asymmetric key
properties of either US flavor or international+fortify version? After
all, the attack on a 512 bit key (asymmetric) is roughly equivalent to
that of a 64 (symmetric) bit key, well within the range of mayor law
enforcement bodies. Might "secure" SSL connections be not so secure
after all?
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: sci.crypt intelligence test.
Date: Tue, 19 Jan 1999 11:36:42 +0100
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>,
> Terje Mathisen <[EMAIL PROTECTED]> wrote:
> >This is (AFAIK) more or less the approach used by the Norwegian
> >military, i.e. XOR-ing the data stream with the output of a fairly long
> >LFSR, with the initial state of the shift register (possibly including
> >the tap points) being the session key.
>
> Um, I hope the Norwegian military doesn't really use plain LFSR's for
> cryptography. Methods of reconstructing the LFSR state have been
> known for decades...
Even I know that this is possible, but when I tried to ask about the
actual operation of the (hardware) encryption device, they refused to
answer.
(This was when the people who had developed the system tried to sell it
to the company I work for, to secure our international links.)
I do believe it is probably a secure system, but I really dislike being
asked to entrust my confidential data to a "secret algorithm".
"Trust us, it is really secure, but we cannot tell you how it works."
:-(
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (Coen L.S. Visser)
Subject: Re: Metaphysics Of Randomness
Date: 19 Jan 1999 10:53:03 GMT
[EMAIL PROTECTED] writes:
>[EMAIL PROTECTED] () wrote:
[...]
>>My opinion is all phenomenon obey to rules even if the rules
>>arent currently known. ok it is just my opinion and i dont have proofs.
>Whether a Turing Machine program halts or not is random.
Hmm, wouldn't that imply that the halting probability is 0.5?
Maybe there is a usefull distinction here between randomness and
not being able to calculate the probability.
>There is no way to prove that it will halt or will not halt by formal methods -
>rules as you call them.
Otherwise I agree with your arguments about "real" randomness occuring in/
emerging from formal systems.
Regards,
Coen Visser
------------------------------
From: Uri Fridman <[EMAIL PROTECTED]>
Subject: steganography algorithm?
Date: Tue, 19 Jan 1999 12:11:21 +0200
Reply-To: [EMAIL PROTECTED]
maybe this is not the right place to ask but i couldn't find the answer
anywhere else.
i'm coding for my company a steganography application, now, they don't
want to use one of the already existing apps so they want me to write
one. I know basically how steganography works but i can find any help in
any example in Delphi 32. does anyone know any source i can check? so
far i keep complication myself.
thanks for your time.
please send reply by e-mail
--
Uri Fridman
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"...the further we go, the older we grow,
the more we know, the less we show..."
=====BEGIN PGP PUBLIC KEY BLOCK=====
Version: 2.6
mQBtAzZXFiEAAAEDAJfbBmE5Yc9E3OoEF8Ku6vSlDdzen3e9uhdctdN6Hsz4MnhY
0zkxuYEnW5RBpj4nn/SxyLtqwtHBVUMdHlwkuTsRnN1U3Tjy+adjI23GbIY4iXKV
j0mgDGr5XV73w+WjjQAFEbQXVXJpIDx1cmlmcmlkQHlhaG9vLmNvbT4=
=VVEj
=====END PGP PUBLIC KEY BLOCK=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some Thoughts on the Design of a Proposed Stream Cipher
Date: Tue, 19 Jan 1999 12:28:55 +0100
JPeschel wrote:
> Why, though, do you cave-in so easily to an agreement that
> has yet to be ratified? What's to prevent the other countries
> from making strong crypto available on their ftp sites before
> the Wassenaar countries agree, if at all, on anything?
I don't think it is a good position to say to oneself that there
is yet much time before retification (though quite a lot of people
ignore the Y2K problem in the same manner). Note, though, there
has been report that someone in Danmark already got difficulty with
his Web publications immediately after the Wassenaar agreement.
Thank you for pointing out the second issue. But that point, I
suppose, is in a similar sense covered by PART of the following of
what I wrote in the article (I mean the maintenance and integrity
problems):
For eventually illegally imported strong crypto products
could have problems of general availability, cost, maintenance,
integrity (virus/bugs implanted by malicious agencies) and,
last but not least, legal issues.
In fact, a week or so after the Wassenaar agreement someone has
aptly arranged to set up a crypto archive in Hongkong. On the other
hand one of the problems which I personally have (and many of the
other common non-expert users very probably also have) with much of
the available strong cryptos is that they are not easy to understand
and consequently I find it difficult to have absolute trust in them,
especially in point of possible backdoors. For example, some
algorithms contain numerical constants that are not explained with
respect to their origin and exact functionality (I call these magic
constants). That's why I doubt, e.g. the probability that I would
ever use AES in an application that is extremely critical for me.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Question on current status of some block ciphers in AC2
Date: Tue, 19 Jan 1999 12:08:46 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] (Vincent Rijmen) wrote:
>The block cipher lounge !
>http://www.ii.uib.no/~larsr/bc.html
>Allthough we don't list answers to all your questions.
Thanks Vincent. I've added your site to my bookmarks.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNqR1Qso1RmX6QSF5AQFSAwf/VZscnWPC5nzmyKYG17yUTTFjjBpMeCNR
TlnNBbUSui0qWngLuuaRNaHhz7pR3Xc3rS7fIE8QgDTL2KqwjRHWJ9dEM88ef8H3
ta0IRGvKGn/vRpis241pfHtQeVZPLcsvr7S+17P2cJYVJbAYoQRuXKEXoPC8VDir
UBYW3P3D85k43Zq3oH80SWLoKiJX140BLi1m0GE2EI3Q52wwI+7WL7jXLUgihTL6
M6fPkoXRs7BZ1cYyZG7xw8UUsE1PGNXNb5SCjXV4/XfePymbL1Siaaz4YpK0C/2X
xnSp+8dH8JnnB4/xURbWIjj47maKB8P2Oa39a1xOG/gBepr//EJ8IA==
=N9ng
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 19 Jan 1999 08:35:53 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 18 Jan 1999 14:35:23 -0500, [EMAIL PROTECTED] (Patrick Juola)
>wrote:
>
>>The point at which the unicity point of the cryptographic system
>>becomes smaller than -- or becomes uncomfortably close to, depending
>>on your degree of paranoia -- the length of the message.
>
>>"Uncomfortably close to," can, of course, encompass a whole myriad
>>of numbers. If you're *really* paranoid, the point at which the
>>key is smaller than the message.
>
>Is it correct to say that the considerations of this subthread you
>posted are entirely based on the concept of Unicity Distance?
Not entirely, but close. The unicity point defines the length at
which a given cryptosystem becomes crackable -- as in, yields *one*
decryption. The key point in the "perfect secrecy" thesis applied
to the OTP is that trial decryption of the OTP will never eliminate
any possible messages. A cryptosystem being driven near the u.p. will
still leak information in that there will be some (but not all) false
messages that are eliminable.
But the concept is still there. What we need is a different term --
perhaps the multiplicity point 8-) -- defining the point at which
all potential plaintexts are possible decryptions of a given
cyphertext. *Any* message with length less than this will be
"perfectly secure" under appropriate conditions.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 19 Jan 1999 08:38:00 -0500
In article <781o6f$7kr$[EMAIL PROTECTED]>,
Coen L.S. Visser <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
>>[EMAIL PROTECTED] () wrote:
>
>[...]
>
>>>My opinion is all phenomenon obey to rules even if the rules
>>>arent currently known. ok it is just my opinion and i dont have proofs.
>
>>Whether a Turing Machine program halts or not is random.
>
>Hmm, wouldn't that imply that the halting probability is 0.5?
No. Whether a die rolls a six or not is also random -- but not 0.5.
-k.
------------------------------
From: "Pedro F�lix" <[EMAIL PROTECTED]>
Subject: Re: long numbers math - how to ?
Date: Tue, 19 Jan 1999 12:59:42 -0000
Rx Video wrote in message ...
>Hello,
>
>I'm looking for some information on how to implement the long numbers
>calculations. I have some ideas of my own, but I'm sure there are some
>better solutions. If anybody knows of some articles on the subject, or
>has tried to do it, please, let me know. I'm looking for conceptual
>(theoretical) solutions.
>Sincerely yours,
>
>Martin
>
The first place to look in is the second volume of Knuth's "The Art of
Computer Programming" - Seminumerical algorithms.
If your major area of application is cryptography there is one operation
that will be fundamental - modular exponentiation - which can be divided in
two: modular multiplication and exponentiation. For these specific
operations I suggest:
Modular multiplication and Squaring:
-P.Montgomery, Modular multiplication without trial division, Math. of
Computation, April 1985.
-A.Bossalaers, R. Govaerts, J. Vandewalle, Comparison of three modular
reduction functions, (I don't remember where it was published)
C. Koc, T. Acar, B. Kaliski, Analyzing and Comparing Montgomery
Multiplication Algorithms, IEEE Micro, June 1996.
Exponentiation:
-D. Gordon, A survey of fast exponentiation methods, (I don't remember where
it was published).
-C. Koc, High-Speed RSA Implementation, RSA Laboratories, November 1994.
I think that these references are enough to keep you busy for a while!
P.Felix
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Tue, 19 Jan 1999 13:54:35 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 18 Jan 1999 23:36:44 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> A Turing Machine program has memory associated with it - the tape. Yet
>> whether any particular program halts or does not halt is totally
>> random. See Chaitin, op. cit.
>Ridiculous.
Says you. You won't mind terribly if I take Chaitin's word for it
instead of yours. Unless, of course, you are prepared to argue
conclusively against Chaitin's theories.
Please let us know when you plan to take him on - and bring you lunch,
because it's gonna take a while.
BTW, I trust that you have actually read Chaitin's relevant papers,
since you seem to be so sure you can show that his work is incorrect.
>The noun phrase "any particular program" includes the program
>"1. Halt" and many others whose termination is not "totally random".
What so you mean by the phrase "whose termination is not totally
random"?
>Even the phrase "totally random" bothers me.
The concept of randomness bothers everyone at one time or another.
That's because there are different meanings for the term.
Your insistence that randomness has something to do with Shannon's
information theory is but one such use of the term. Another use is
Chaitin's algorithmic theory. They are not the same kind of randomness
either. Then there is another form of randomness called crypto-grade
randomness, which is produced only by a TRNG for use in the OTP
cryptosystem.
There is layman's book which describes the Physics Of Information,
entitled "Fire In The Mind", which helps put these different kinds of
randomness in perspective.
"Total Randomness" in cryptography means that the bit sequence is
generated by a TRNG. A TRNG is a physical device that is capable of
generating all possible sequences equiprobably. Only in that manner
can the sequence be used in the proveably secure OTP cytptosystem.
As Patrick Juola pointed out the other day, that statement applies to
arbitrary length messages. It is possible to communicate small
infrequent messages securely with less than OTP-strength pads, but
that exception is not of much practical interest. In order for the OTP
system to be proveably secure, the pads must be generated by a TRNG.
>Like uniqueness, randomness is a
>binary property.
Crypto-grade randomness is the consequence of the specification of a
TRNG, not some property of the sequence per se.
>Things are not very unique or a bit unique, they are
>either "totally" unique, or not at all unique. The same applies to
>randomness.
That consideration applies to certain kinds of randomness, but not to
crytpo-grade randomness used in the OTP cryptosystem.
For one thing, your definition would exclude certain sequences from
use in the OTP, something that is not permitted or the resulting
ciphers will be distributed nonuniformly, making them susceptible to a
probability attack like the Bayesian Attack. Purists would not even
permit filtering out the two most pathological sequences, 111...1 and
000...0, although I think that is a bit overdone for long sequences.
You cannot just preserve only those sequences that fit into your
information theory, sequences which individually pass some test
regarding entropy. That is an incorrect notion for purposes of crypto,
where randomness is the property of how the sequences are generated,
not a property of the sequences per se (for arbitrarily long
sequences).
Bob Knauer
"Whatever you can do, or dream you can, begin it. Boldness has
genius, power and magic in it."
--Goethe
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: Tue, 19 Jan 1999 13:00:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Ian Miller) wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel James <[EMAIL PROTECTED]> wrote:
> >
> >Interesting - I'd have expected Java to fare much worse against
> >optimized code like this.
>
> I am not surprised. In the long term, i.e. once compiler/processor
> technology has moved on a little, the quality of the programming is far
> more important than the language it was written in. The most extreme
> example of this is assembler code, which is fastest in the short term but
> freezes the code in the technology of the time. _Any_ high-level language
> on next generation of hardware with a decent compiler will out-perform it.
>
> e.g. The IDEA implementation used in the Mac version of PGP2.3 used 68020
> assembler. However on a 68030 (only a slightly more advanced processor),
> the pure C version ran 25% faster.
>
>
snip ...
Actual this is not true. Good assembly language is dam hard to bet.
I have seen old code written on old univacs fly circles around the
newer compiled stuff even though the newer univacs have a larger
instruction set. Also the newer compliers the designers have not
given much thought to good design. Lots of times an old fortran
v program will easily beat a newer ascii program in time and size.
I find it hard to belive a pure C version could run any faster
if you allowed the assembly version to run on the same processor.
Sure maybe it goes 25% faser on the 68030 hardware than the
assembly on the 68020 but that might be due to HARDWARE speed
increased and not SOFTWARE.
David A. Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
