Cryptography-Digest Digest #605, Volume #9 Thu, 27 May 99 19:13:02 EDT
Contents:
Re: Review of Scottu19 (SCOTT19U.ZIP_GUY)
Re: The Sterling Approximation as it relates to OAP-L3 encryption software. (wtshaw)
Re: Best algorithm combination? (Bruce Schneier)
Re: AES tweaks (David Crick)
Re: Why would a hacker reveal that he has broken a code? (Terry Ritter)
Re: crack a hash function? (wtshaw)
Re: non-computerized cryptography (John Savard)
Threatening SW ^besides^ Strong-Crypto (Charles M)
Re: Review of Scottu19 ([EMAIL PROTECTED])
Re: Threatening SW ^besides^ Strong-Crypto (vincent michael crane)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Review of Scottu19
Date: Thu, 27 May 1999 21:49:37 GMT
In article <7ijt0c$nt8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thomas Pornin) wrote:
>According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
>> C is meant so that programers can code quickly from one machine
>> to another but it lacks many features that would be of use to a
>> encryption programer. For example ASCII C does not have a nice way of
>> speciifing number of bytes per variable.
>
>ANSI, not ASCII.
>
>Actually, C has some requirements for the length of integer variables,
>that are not expressed in terms of bytes (there used to be machines
>where bytes did not even exist).
>Typically, the integer types may represent values in the following
>ranges:
> min max
>char 0 127
>signed char -127 127
>unsigned char 0 255
>short -32767 32767
>unsigned short 0 65535
>int -32767 32767
>unsigned int 0 65535
>long -2147483647 2147483647
>unsigned long 0 4294967295
>
>When you cast an integer value to another integer type, and the value
>is in the two ranges, then the value is kept. Otherwise the result is
>(mostly) undefined ("the computer catches fire" is a legal behaviour
>in such a case -- more reastically, there are compilers where such an
>attempt is sanctionned by an end-of-task).
>
>There is no obligation for signed integer to be represented in
>two's complement. Actually there are computers which do use other
>representations (one's complement, or positive mantisse and a sign bit),
Yes I was an assembly language progmer on a 1180 univac 36 bit words
and 1'complement arithmatic. But the machine was a turkey in any other
language but assembly.
>which explains that (for instance) the lowest representable value in
>an int is -32767 and not -32768. There is also no obligation on what
>happens in case of overflow (if an int contains 32767 and you add 1,
>everything can happen, included an automatic installation of win98 --
>although this is not probable).
>
>However, unsigned integers are guaranteed to be rounded up modulo a
>power of two in case of overflow. If you add 1 to an unsigned int
>containing 65535, the result will be 0 + k * 65536, where k is 0 or 1,
>depending on the implementation (and the computer must not catch fire).
>
>
>So, given these characteristics, I have yet to see a single crypto
>algorithm that cannot be implemented in an elegant, readable and
>notwithstanding fast way in a true ANSI C fashion. See that memory
>representation is completely irrelevant here: if the computer decides
>to store a value in decimal, it is its problem, not yours.
>
Then you don't look very hard becasue scott19u can not be
implemented in a eleagant(what does elagnat mean any way)
readable ANSI C way and even start to run as fast as it does on
my PC. But if your good at assembly you can speed it up by a
factor if ten.
>
>The potential limitations of ANSI C are:
>
>-- No integer type for unsigned values bigger than 32 bits. This will be
Well DJGPP already beats that use "unsigned long long"
>corrected in the next ISO C specification (the so-called C9X, which will
>probably be C2K after all), which will standardize the "unsigned long
>long".
>
>-- No way to take some benefit of the ability of some processors to
>generate the upper bits of a multiplication: if you multiply two
>unsigned longs, you only get an unsigned long. But an Intel CPU produces
>a 64 bits quantity in this case, and you have to include some assembly
>to get the 32 higher bits (or otherwise use the unsigned long long).
>Same applies to Alpha processors (there is an opcode that outputs the 64
>high bits of a 64x64 multiplication).
>
>
>These two limitations strucked us when DFC (an AES candidate) had to be
>implemented (in DFC there are arithmetic operations on values modulo
>2^64+13, including a multiplication). The consequence is that, on a PC,
>the true ANSI C version is somehow 4 times slower than a completely
>hand-optimized assembly version. This is really not worth ranting about:
>if you want absolute speed, you would go for assembly, but properly
>coded C is portable and this is really valuable. The same, exactly the
>same C code will run unchanged on Sparc, UltraSparc, Intel, Alpha,
>680x0, PowerPC, Vax, PDP, 6809, Z80,... Think about smartcards for
>instance.
>
>And, more important, the DFC ANSI C code is understandable. This is not
>so relevant because DFC comes with a real description anyway, but at
>least one may read it and have some confidence.
>
>
>As for endianness, it is completely irrelevant. If your input data
>is an array of unsigned chars, use a macro to get these as 32 or 64
>or whatever bits, in the endianness you prefer, and let the compiler
>optimize the operation, depending on the architecture. It is much better
>than you and me anyway.
>
>
>
>To sum up all this: there is one advantage in producing C code that is
>not ANSI C compliant. Namely speed. But there are major drawbacks, worst
>of them is the lack of readability (which is bad for a symetric cipher,
>since the only real security you may get is derived from public review:
>many smart people read it, nobody breaks it, so it must be secure -- I
>have much more confidence in RC5 than in any of your algorithms, for
>this very one reason). Another drawback is that it makes you appear as
>perfectly incompetent in coding. This also is bad for confidence.
>
I would rather apear incompetent and have the code work than to follow some
ones ideas of a standard. If you have not figured that out then you haven't
followed much of what I have done. I hate ties and think only idiots where
them I am still pissed that C when it changed standards a while back you could
use octal contants that contained the digit '9' since it actually was 1001 but
the dam purist said fuck the working programers we think it is impure so will
change the rules so there old programs no longer work. I feel you like these
kinds of changes that make more restrictions on the programer are for
acedemic buffons who care about purity, I want a langage that any thing goes
and as new versions come out they add to the languge instead of driveing it
towards some purely crappy language like barf ADA. But that is just my view
point.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: The Sterling Approximation as it relates to OAP-L3 encryption software.
Date: Thu, 27 May 1999 15:09:57 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Anthony Stephen Szopa wrote:
> > Sterling's Approximation for factorials: ...
>
...
>
> > ... there are three randomly sequenced sets of these 3,628,800
> > permutations used to generate random numbers using this software,'
>
....
>
> So what? Similarly huge numbers of possibilities have been cited
> in the past for cryptosystems that were readily broken.
How you handle the resultant series to make your key makes lots of
difference; how the algorithm uses the key makes lots of difference as
well, either of which could kill the result.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Best algorithm combination?
Date: Thu, 27 May 1999 21:28:59 GMT
On Thu, 27 May 1999 20:44:20 +0300, Kiril Kesarev <[EMAIL PROTECTED]>
wrote:
>Several ciphers can be combined to increase security. One
>scheme would look as follows:
>
>1. Split the message into N shadows by XORing it with bits
>from a true RNG. Each shadow has the same length as the
>original message and all shadows are required to reconstruct
>the original message (OTP-style).
>
>2. Each shadow is encrypted separately with different
>secret-key ciphers using different keys for each of them.
>
>3. The resulting ciphertext will consist of all the
>encrypted shadows.
>
>In order to break the scheme, a cryptoanalyst must be
>able to break all the secret-key ciphers used in the scheme.
>
>If a paranoid person wishes to encrypt his email using
>several secret-key algorithms in parallel, what combination
>of ciphers should he use?
>
>Is it wise to bet on one type of ciphers, eg. encrypt
>using 3DES, IDEA, and BLOWFISH, or use a diverse combination
>like: BLOWFISH, some LFSR-cipher, RC4, and a strong PRNG such as the
>BBS-generator?
>
>Any ideas on the "best" combination of ciphers?
Fascinating question.
Leaving aside the mechanics of the scheme and how it could works... I
would choose algorithms that are very different. Triple-DES (because
of its pedegree), Blowfish or Twofish (because this is me talking), an
impressive LFSR-based stream cipher, a mathematical cipher like RSA,
maybe some sort of rotor-based cipher like RC4, and then some others.
This is, of course, silly. It's easy to keep something secure if you
have enough clock cycles to do all of these things, and can handle the
obscene data expansion that such a scheme causes. To me, cryptography
is only interesting when there are some performance constraints.
Otherwise, you end up with schemes such as this one.
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: David Crick <[EMAIL PROTECTED]>
Subject: Re: AES tweaks
Date: Thu, 27 May 1999 22:58:21 +0100
"SCOTT19U.ZIP_GUY" wrote:
>
> Dave I just think they are a bunch of stuffed shirts wearing
> clown suits why should I kiss there ass. I am sure they are aware
> of such weakness they just really don't give a damn. And did you
> try the above test or like most you just dismess this with out
> giving a dam too.
I did not dimiss it. I merely implied that if you had discovered
something significant then you should publish it properly and draw
people's attention to it.
However, as with your ciphers, you resort to bluster and name-
calling. As many people have tried to point out to you, if there
really is substance to your claims then you need to change your
attitude if you want them (and yourself) to be taken seriously.
David.
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Keys: 2048-bit RSA: 0x22D5C7A9 4096-DH/DSS: 0x87C46DE1 |
+-------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Thu, 27 May 1999 21:59:24 GMT
On 27 May 1999 16:12:58 -0400, in <7ik90a$13t$[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Patrick Juola) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>>[...]
>>Notice that what mathematicians work on and fail to find this year is
>>*not* treated as "evidence" of a limit on what math dabblers could do,
>>what other groups might already have done, or what will happen next
>>year.
>
>Obviously from someone who's never either written or reviewed budget
>plans for a mathematically-intense group.
I will not be held responsible for bean-counter logic!
>Hint : if a lot of people have pounded on a problem for a while with
>minimal impact, most bean-counters will regard that as "evidence of
>a limit" and will pull the plug on your funding.
And those bean-counters may be right -- with respect the capabilities
of the people they know and fund. Surely even bean-counters do not
attempt to predict what *others* can do without some knowledge of who
the others are and what their capabilities may be.
Predicting what the opponent can do on the basis of what we can do is
at the very essence of weak cryptography. That is Germany and Japan
in WWII and every other broken system as well. We can either learn
from history or repeat it.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: crack a hash function?
Date: Thu, 27 May 1999 16:21:10 -0600
In article <7ijk4b$daj$[EMAIL PROTECTED]>, "Jean Marc Dieu"
<[EMAIL PROTECTED]> wrote:
> It would be interesting that among the many inputs possible for one specific
> result, only one would have a language structure (such as: "This contract
> ..." in opposition to "H�#2@|&~^+U ...")
You might have an obscure sequence of symbols that never could be equated
to text, or you could use a hash that always results in letter output,
increasing the chance of having meaningful equivalents.
>
> I'm not a mathematician, so I'll probably be wrong (but I expect somebody to
> tell me why... :). I think there isn't any possible collusion-free hash
> function as you "lose" information by doing so. The only collusion-free
> "hash" function in my view, is a very well compressed message (I mean you
> try to have a compression that leads to the maximum average self information
> (entropy=1/2 right?) ) and followed by encryption - but then it wouldn't be
> a hash function, isn't that right? As long as you "remove" some information
> from a message (to obtain a hash of it), collusion will be possible?
> (I know that this is very intuitive and probably not mathematically
> rigourous at all, but I am only a humble management student very keen on
> crypto... :-)
Lots of the benefits of compression can be eliminated by using a more
appropriate character set to begin with.
>
> I have been thinking about multiple hashes too. Please correct me if I'm
> wrong:
> "Multiple hash reduces tremendously the probability of collusion, but
> doesn't eliminate this possibility"
It depends on how you do it.
> What do you mean by multiple hash?
> -Paralell (you have an input M and you hash it with k different hash
> functions in paralell; that leads to the following output: M1, M2, ... Mk)
> - Serial (You use the (k-1) output as the input for the next round (k),
> etc...)
> - A combination of both?
> Which one is the best way?
I'VE DONE BOTH,IN SEVERAL DIFFERENT WAYS.WITH THE PARALLEL METHOD CAN YOU
GET A COLLISION REDUCING INTERFERENCE PATTERN IN ENCRYPTION FROM THE KEYS
THAT WERE PRODUCED.CONSIDER THAT CHARACTERS OF THIS PARAGRAPH COULD BE
USED WITH MY OCTAL HASH TO PRODuce a series of 20 seeds.
OCTAL NUMBERS:
70271 14202 45331 03311 32033 42112 31444 55452 76254 66557
65264 56606 77663 16752 67132 00405 70703 34166 31420 57376
SEEDS:
28857 6274 19161 1737 13339 17482 13092 23338 1916 28015
27316 23942 2691 7658 28250 261 29123 14454 13072 24318
The UC shows the letters that were used, trimmed to 250 characters. A
counting routine was used to assign octal digits to all 250 characters,
and only the first 100 were harvested as octal numbers. These in turn
were converted to 15 bit decimal seeds, with an offset, and converted to a
cylinder key.
Taking the same text, and referencing a character set, an 8 character hash
can be generated: ET`/PUKG
In runtime, the two keys are both use in encryption.
Or, the process can be greatly simplified with a single action on the part
of the user in which the characteristic number of a cylinder is made,
3481315874, the key is shuffled according to the same text, and the 8
character has is also generated. Simple manipulation of the input text
would produce wildly different results in encryption and decryption
processes.
Now, a serial example. Consider that the algorithm example needs three
keys from a total of 81 characters. I will use the first to sentences of
this paragraph as source text to make them all. There are more than 81
characters available, and the three keys are made the same way:
Key1(CB): przawfukb mg/cotnhd sqxleivyj
Key2(CB): awxkebnjs umylpf/cq togrhidvz
Key3(CB): ltghni/wj uqpaxrybo skemcvdfz
If I have a dumb string, I can still make the has work by repeating the
characters.
Only 65 usable characters in the above line produces:
Key1(CB): khlja/gbf zrdvxumsi nectwyopq
Key2(CB): panewjfkb vzrtod/ug shcxmqiyl
Key3(CB): ifmasbgxj tvolpnc/k dhzrewyuq
To the algorithm, no function is changed, but the security, such that it
is, is lesser in the second case.
Now to an example where either parallel or serial hashing can be used:
Using these same words, here are the keys resulting from parrallel hashing
and from serial hashing:
Subs: su/, vate =brw of-l gyhi n?mj zxc. dpqk
Trans: lpqsf rjamh btikn gecod
Subs: su/, vate =brw of-l gyhi n?mj zxc. dpqk
Trans: kmrqn alctb joids hepfg
In parallel, 52 characters are needed; serial, 32, then, 20.
These are simply example and I make no claims for security in this posting.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: non-computerized cryptography
Date: Thu, 27 May 1999 22:34:30 GMT
[EMAIL PROTECTED] (Jim Dunnett) wrote, in part:
>When I was in the military
Be careful what you post on USENET. Given the reputation of your
government in such areas, I wouldn't want them coming after you like
they are after that fellow who - perhaps entirely mistakenly, from
mental problems caused by the strain and secrecy of his work -
concluded that, due to a similarity between the circumstances of a
well-known automobile accident and a plan to deal with someone causing
a great deal of pain in the Balkans at present, that his employer was
somehow responsible.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Charles M)
Crossposted-To: comp.security.misc
Subject: Threatening SW ^besides^ Strong-Crypto
Date: Thu, 27 May 1999 15:35:59 -0700
Slow week and too much thinking again.
The crypto bit is so much in the news, and so long-running that I for
one am apathetic on the topic. But I was thinking last night about
whether there mightn't be other kinds of software that would pose as
great a thread to "national security" as Strong-Crypto. And I was
thinking that while S-C is dangerous (supposedly) because it would allow
terrorists to plot under the nose of US spooks, there are obviously
tools that would have the opposite risk - in other words give our foes
the ability to tap into our secret data stores, etc. But then I think
the reality is that hackers don't benefit much from commercial software
- except for the holes in it.
^But^ - what about this: What about something like the Autonomy product?
- SW that is just so powerful and versatile in its applications that it
could certainly be used to boost foreign intelligence efforts. I don't
know how familiar you all are with Autonomy, but it's nominally a
"knowledge-management" tool. It can take "unstuctured" information
(text, content) and match like with like at a very sophisticated level.
The British gov't if not "ours" has been using to profile and link
police cases and to process gathered intelligence info. This was just
mentioned in a magazine article and I'm sorry I don't have more details
- very curious.
But just imagine if a foreign government - or a terrorist organization
for that matter - had a tool which let them automatically scan huge
volumes of intercepted email, stolen documents, or enormous sections of
the Web. The info just on US gov't web sites is unbelievable, and the
main obstacle to putting it to use is that the Web is so sprawling and
there is so much stuff out there that the important, "dangerous" stuff
is too hard to locate sort out.
Enough of that anyway. But you see what I mean? Does anybody have any
ideas for other software that could aid our foes this much, if they were
clever enough to put it to the right use??
...Charles
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Review of Scottu19
Date: Thu, 27 May 1999 22:02:26 GMT
In article <7ijt0c$nt8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Thomas Pornin) wrote:
> According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> > C is meant so that programers can code quickly from one machine
> > to another but it lacks many features that would be of use to a
> > encryption programer. For example ASCII C does not have a nice way
of
> > speciifing number of bytes per variable.
>
> ANSI, not ASCII.
>
> Actually, C has some requirements for the length of integer variables,
> that are not expressed in terms of bytes (there used to be machines
//snip
> (mostly) undefined ("the computer catches fire" is a legal behaviour
> in such a case -- more reastically, there are compilers where such an
> attempt is sanctionned by an end-of-task).
>
If your compiler does that, than I would reccomend that you get a
better compiler. Adding two variables of different integer types might
give you an implementation-defined result in some cases (ex. do we
extend the sign bit of a char treated as an int?), this result is never
undefined. Undefined has a very specific meaning in C, this basically
meaning that the compiler can turn your computer into a toaster.
> There is no obligation for signed integer to be represented in
> two's complement. Actually there are computers which do use other
> representations (one's complement, or positive mantisse and a sign
bit),
> which explains that (for instance) the lowest representable value in
> an int is -32767 and not -32768. There is also no obligation on what
> happens in case of overflow (if an int contains 32767 and you add 1,
> everything can happen, included an automatic installation of win98 --
> although this is not probable).
Same thing here, implementation-defined, but not undefined.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (vincent michael crane)
Crossposted-To: comp.security.misc
Subject: Re: Threatening SW ^besides^ Strong-Crypto
Date: Thu, 27 May 1999 15:53:24 -0700
interesting post.
you make a good case about autonomy. until 6 month ago i worked for
novell. their autonomy use is certainly covered by my extensive non-d,
but i'm sure i can copy the text from autonomy's customer page -
http://www.autonomy.com/customers/index.html#novell :"Novell- Autonomy
provides automatic competitive inelligence for internal and external
source." sound familiar to you?
i can tell you that system works beautifully. and it's easy enough for
even yale-educated balkan terrorists to use, i would think. it can
certainly do what you say.
i wonder, have no idea, whether there isn't along with all the
apolitical gun-runners out there, an information/intelligence cartel
selling data and strategy to all these factions out there. they could
offer -reports- along the lines of jupiter, except they could be on
topics such as US attaches morning commute routes. makes one shudder.
as far as other software... a lot of mathematics/chem/physics programs
would probably count. also software related to GPS/mapmaking?
--VC
Charles M wrote...
>
>Slow week and too much thinking again.
>
>The crypto bit is so much in the news, and so long-running that I for
>one am apathetic on the topic. But I was thinking last night about
>whether there mightn't be other kinds of software that would pose as
>great a thread to "national security" as Strong-Crypto. And I was
>thinking that while S-C is dangerous (supposedly) because it would allow
>terrorists to plot under the nose of US spooks, there are obviously
>tools that would have the opposite risk - in other words give our foes
>the ability to tap into our secret data stores, etc. But then I think
>the reality is that hackers don't benefit much from commercial software
>- except for the holes in it.
>
>^But^ - what about this: What about something like the Autonomy product?
>- SW that is just so powerful and versatile in its applications that it
>could certainly be used to boost foreign intelligence efforts. I don't
>know how familiar you all are with Autonomy, but it's nominally a
>"knowledge-management" tool. It can take "unstuctured" information
>(text, content) and match like with like at a very sophisticated level.
>The British gov't if not "ours" has been using to profile and link
>police cases and to process gathered intelligence info. This was just
>mentioned in a magazine article and I'm sorry I don't have more details
>- very curious.
>
>But just imagine if a foreign government - or a terrorist organization
>for that matter - had a tool which let them automatically scan huge
>volumes of intercepted email, stolen documents, or enormous sections of
>the Web. The info just on US gov't web sites is unbelievable, and the
>main obstacle to putting it to use is that the Web is so sprawling and
>there is so much stuff out there that the important, "dangerous" stuff
>is too hard to locate sort out.
>
>Enough of that anyway. But you see what I mean? Does anybody have any
>ideas for other software that could aid our foes this much, if they were
>clever enough to put it to the right use??
>
>...Charles
>
------------------------------
** 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
******************************
