Cryptography-Digest Digest #79, Volume #9 Sun, 14 Feb 99 14:13:02 EST
Contents:
Re: Tell-Tale DES Byte-Length Encoding (wtshaw)
Re: Help! Cryptosystem needed. (UBCHI2)
Re: IDEA Rounds (Cuykens Anthony)
Re: Tell-Tale DES Byte-Length Encoding (fungus)
Re: Microsft crypto headdump.cpp ("arclight")
Re: GPL'ed RNG (Jon Haugsand)
Re: Help! Cryptosystem needed. (Lincoln Yeoh)
Re: RNG Product Feature Poll (R. Knauer)
Re: Microsft crypto headdump.cpp ("John")
Foodfight! (Ken Blangert)
Re: Help! Cryptosystem needed. ("Steve Sampson")
Re: WW-2 German Enigma Machine For Sale ("Cestyll O. Dywod")
640-bit Modulus Factored. (Ted Kaliszewski)
Re: Tell-Tale DES Byte-Length Encoding ([EMAIL PROTECTED])
Have you ever had your Astrological Charts done? (Money Concepts Unlimited)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Tell-Tale DES Byte-Length Encoding
Date: Sat, 13 Feb 1999 21:09:38 -0600
In article <7a58o7$arp$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> That is one reason my scott19u contest is the way it is. The contest can
> not be done using any of the FISHY NSA approved methods with weak chainning
> such as CBC that are being pushed as AES candidates. AND THAT IS FACT even
> Mr B.S. can not dispute this simple truth.
>
The problem with AES is the same as it has always been, various parties in
government with various interests are trying to row the boat in several
directions at once, some in the name of technological need, some in the
name of keeping crypto on the dumb side, some in the name of directing or
misdirecting manufacturing to vested interests, some in just keeping the
pot boiling so they can do as they please, and many who haven't a clue
about more than one aspect of the problem.
The past myths have died about encryption, its possible tremendous
strengths, and the govenment's ability to transparently control it. Now
we have overt turf warfare amongst those who want to control it, not
knowing much really about the underlying subject themselves. They cannot
accept the statements of limitation that they get, and still fund those
who promise to deliver something that cannot be neatly done.
I could not say that chaining does not have its place, but it is a poor
excuse for a better alternative. I still consider dscott's methods
excessive and in some ways self-defeatin, but be they so, they are not
necessarily in an option to be forgotten; I merely think there are better
options, AES not necessarily being out of the picture as just another of
those.
>
> > If chaining is used appropriately, the worst result under the best
> > circumstances is the all or nothing type of encryption that dscott
> > advocates, but that may be desirable to your circumstance.
> And what SIR chainning do you propose for this all or nothing effect?
It is simply not necessary for some applications, but for others, fine.
If your programs work for someone, fulfilling their needs, by all means
they should use them.
I simply maintain that all-or-nothing can be a problem in some
circumstances, and the predictability of those circumstances does not go
away. In those likely cases, use something else, or wish you had if you
underestimated the dependability of the data.
> > --
> > A much too common philosophy:
> > It's no fun to have power....unless you can abuse it.
>
> I was wondering is this last line a Clinton quote or what?
>
Just an observation.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: Help! Cryptosystem needed.
Date: 14 Feb 1999 07:25:41 GMT
Why isn't blowfish suitable for your needs?
------------------------------
From: Cuykens Anthony <[EMAIL PROTECTED]>
Subject: Re: IDEA Rounds
Date: Mon, 08 Feb 1999 13:33:04 +0100
I am not an expert but I could say this to you: adding some more round
will probably not increase your security because:
- This will not enhance the length of you key;
- 8 round must be quite enough (otherwise the constructor would have
put 16 or more).
On the other hand, here are the problems that I see:
- your new version will no more be compatible;
- you will have to develop the new program that will be tested only
by you so you will not have many people finding the bugs as for the popular
implementation of IDEA;
- this will make your encryption algo slower.
After having said that you may expect that I am not for an augmentation
of the number of rounds.
Dirk Mahoney wrote:
> Hi everyone,
>
> Are there any known problems (security-wise) of arbitrarily increasing
> the number of rounds used when encrypting plaintext with the IDEA
> algorithm? The default is 8 rounds, but if I were to be a little on the
> paranoid side, would there be any harm in increasing this to 12 for
> example?
>
> Thanks in advance,
> - Dirk
--
Anthony Cuykens
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Tell-Tale DES Byte-Length Encoding
Date: Sun, 14 Feb 1999 19:13:58 +0100
wtshaw wrote:
> I still consider dscott's methods
> excessive and in some ways self-defeatin, but be they so, they are not
> necessarily in an option to be forgotten; I merely think there are better
> options...
DScott's philosophies of providing free crypto algorithms to the
masses should be applauded[1], but his implementations leave something
to be desired.
What I look for in a crypto algorithm is simplicity and transparency,
I want to be able to see what's happening, and analyse it in my head.
Every release of ScottXX gets more and more complex, with no real
justifications for the changes. Every layer of "security" just makes
it harder to analyse, and therefore harder to trust.
For these reasons I like ARCFOUR. With ARCFOUR I can see what's
happening, and I can understand why it's hard to crack. I find it
extremely hard to believe that those few lines of code can contain
any major weakness. Even ARCFOUR's weaknesses are easy to understand
and appreciate. Understanding the weaknesses is important to
understanding the threat they pose (nothing worth mentioning).
To me, complexity is what kills a cipher... (just my $0.02)
--
<\___/>
/ O O \
\_____/ FTB.
[1] Though he's not the only person doing so...
------------------------------
Reply-To: "arclight" <[EMAIL PROTECTED]>
From: "arclight" <[EMAIL PROTECTED]>
Subject: Re: Microsft crypto headdump.cpp
Date: Sun, 14 Feb 1999 02:25:27 -0800
looks like it wants an authenticode signature, like it's an activex
component...
check it out...
John wrote in message <7a4evd$nc7$[EMAIL PROTECTED]>...
>Hi guys,
>
>I was playing with a file I downloaded from Microsoft site, called
>"headdump.cpp".
>This executable allow to send ssl request in the form of a C API. The funny
>thins
>is that, when this API runs inside a normal executable from a DOC console,
>it works fine.
>But when this API is called form a CGI, I receive this error :
>
>HttpSend error code : 12045
>Message : The certificate authority is invalid or incorrect.
>
>Any ideas ?????
>
>Thanks
>
>J.
>
>
------------------------------
From: Jon Haugsand <[EMAIL PROTECTED]>
Subject: Re: GPL'ed RNG
Date: 08 Feb 1999 13:51:22 +0100
* Wm. Toldt
> Do the letters GNU stand for some words?
"Gnu's Not Unix"
--
Jon Haugsand
Norwegian Computing Center, <http://www.nr.no/engelsk/>
<mailto:[EMAIL PROTECTED]> Pho: +47 22852608 / +47 22852500,
Fax: +47 22697660, Pb 114 Blindern, N-0314 OSLO, Norway
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Help! Cryptosystem needed.
Date: Sun, 14 Feb 1999 11:10:16 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 14 Feb 1999 00:05:08 +0200, Divon Lan <[EMAIL PROTECTED]> wrote:
>I'm developing a product that's going to process and transfer over the
>Internet large volumes of commercial-sensitive data.
>
>I need to encrpyt all data in some kind of asymmetric + symmetric
>fashion (something similiar to what PGP does). Also, I need an
>asymmetric encryption algorithm for authentication.
>1) Is there an accepted, well-researched and non-patented alternative to
>RSA for asymmetric encrpytion? Is there anyway using RSA without
>violating the patent? How about El-Gammal?
DH or RSA should be fine. RSA is not patented in many countries outside the
US.
>2) What symetric system should I choose (it must be non-patented,
>royalty-free and preferably (but not necessaraly) exportable):
> (o) How insecure is DES (what does it take to break it)?
> (o) How about IDEA or arcfour?
> note that I am dealing with large volumes of data, so it must be
>fast. e.g. I think 3DES will
> be too slow for my needs.
Unless you are transferring at T3 (45Mbit/s) speeds I do not think you will
have any problems with 3DES or other symmetric encryption with run of the
mill Pentium II machines. It is probably more an architecture thing.
>3) What do suggest I use for a hash function - faster than MD5 (I don't
>care too much about collisions - and I think 64 bits is enough for me)?
Erm why don't you just use a modified PGP 2.6.x with a frontend? Or get the
PGP5 developer toolkit and use it.
If your data doesn't have to be transferred near real time then PGP would
be fine. If not then you should perhaps look into SSL with certificates at
both client and server side.
However SSL is not so good at authenticating the actual messages, it just
provides a secure authenticated _channel_ but that may be good enough for
you.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Sun, 14 Feb 1999 13:09:59 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 13 Feb 1999 18:25:30 GMT, Dave Knapp <[EMAIL PROTECTED]> wrote:
>> That's because it is a complicated subject. The closest one comes to
>> crypto-grade randomness is Quantum Mechanics, a very complicated
>> subject indeed.
>And one with which I am _far_ more familiar than you, FWIW.
>I don't know whether to laugh or cry about the above. It's just so...
>so... wrong? Stupid? Ignorant? All of these?
>Enjoy your Deep Metaphysical Discussion.
Another Flame Twit, eh.
<plonk>
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
------------------------------
From: "John" <[EMAIL PROTECTED]>
Subject: Re: Microsft crypto headdump.cpp
Date: Sun, 14 Feb 1999 14:28:19 +0100
In this case, why the SAME executable works when called from a
DOS window, and fails when it is called as a CGI ? The
file use windows standard calls ! (InternetOpen,InternetConnect, ...)
What is bothering me is that I build the whole project based on the
idea that if the executable works fine, the CGI will. And two days before
the delivery, here what happens ...
I LOVE MS ...
arclight wrote in message ...
>looks like it wants an authenticode signature, like it's an activex
>component...
>check it out...
>
>John wrote in message <7a4evd$nc7$[EMAIL PROTECTED]>...
>>Hi guys,
>>
>>I was playing with a file I downloaded from Microsoft site, called
>>"headdump.cpp".
>>This executable allow to send ssl request in the form of a C API. The
funny
>>thins
>>is that, when this API runs inside a normal executable from a DOC console,
>>it works fine.
>>But when this API is called form a CGI, I receive this error :
>>
>>HttpSend error code : 12045
>>Message : The certificate authority is invalid or incorrect.
>>
>>Any ideas ?????
>>
>>Thanks
>>
>>J.
>>
>>
>
>
------------------------------
From: Ken Blangert <[EMAIL PROTECTED]>
Subject: Foodfight!
Date: Sun, 14 Feb 1999 07:35:15 -1000
R. Knauer wrote:
>
> On Sat, 13 Feb 1999 18:25:30 GMT, Dave Knapp <[EMAIL PROTECTED]> wrote:
>
> >> That's because it is a complicated subject. The closest one comes to
> >> crypto-grade randomness is Quantum Mechanics, a very complicated
> >> subject indeed.
>
> >And one with which I am _far_ more familiar than you, FWIW.
>
> >I don't know whether to laugh or cry about the above. It's just so...
> >so... wrong? Stupid? Ignorant? All of these?
>
> >Enjoy your Deep Metaphysical Discussion.
>
> Another Flame Twit, eh.
>
> <plonk>
>
> Bob Knauer
Windbag: a loquations, usually pompous person who has little to say.
Come on David Hamilton and Paul Allen, join the fun! This self appointed
random number expert always needs the last word: a perpect taget for a
slug-fest. These random threads could go on forever, so join in the fun.
It is a very difficult concept, randomness, so it must be pounded into
our heads over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and ....
RTFB
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: Help! Cryptosystem needed.
Date: Sun, 14 Feb 1999 09:23:35 -0600
Because he wants an end-to-end system, not a file that
was encrypted, and then sent via FTP...
UBCHI2 wrote
>Why isn't blowfish suitable for your needs?
------------------------------
From: "Cestyll O. Dywod" <[EMAIL PROTECTED]>
Subject: Re: WW-2 German Enigma Machine For Sale
Date: Sun, 14 Feb 1999 11:58:43 -0500
Reply-To: [EMAIL PROTECTED]
webb wrote:
>
> There is a WW-2 German Enigma Machine For Sale on the eBay
> auction site. Also a post-WW-2 Swiss enigma linked to from the
> following:
>
> http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=64840419
>
> The auction ends Sunday night 2/14/99.
>
> Webb WA2MOT
Nice to see the starting price was lower than the $20,000 asked for the
last Enigma!
Dave K7HMP
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: 640-bit Modulus Factored.
Date: Sun, 14 Feb 99 13:05:57 -0500
13 February 1999
640-bit Modulus Factored.
Now, friends, do not panic! The modulus in question is, indeed,
a legitimate two-primes composite BUT, it is also a pseudoprime to
bases of 3, 5, 11 and 13. It is one of my favorite traps. This modulus
factors easily via the construct of ufm with a prime multiplier of
65537.
Here it is:
n=
258235611221564887324336132528616569709171143133191762270611528270579\
528902851865120478046304699997730811969691803799491527919245659499681244\
7182731923492396146370564696347865725215472047041631
p=
227260032219290546911431576628944021599721419449237531076055686338663\
7965958418193416061231579621
q=
113630016109645273455715788314472010799860709724618765538027843169331\
8982979209096708030615789811
As you can see, I am inching toward my goal of 1024-bit modulus.
Incidently, can anyone touch the above modulus with, say, the NFS
factoring algorithm? If so, let me hear about it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Tell-Tale DES Byte-Length Encoding
Date: Sun, 14 Feb 1999 15:55:30 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>
>
> wtshaw wrote:
> > I still consider dscott's methods
> > excessive and in some ways self-defeatin, but be they so, they are not
> > necessarily in an option to be forgotten; I merely think there are better
> > options...
>
> DScott's philosophies of providing free crypto algorithms to the
> masses should be applauded[1], but his implementations leave something
> to be desired.
Thanks I got very little phrase but I suspect part of the reason
is my poor political skills. I find it hard to lie and word things
in a politically incorrect way. I have the uique ability to walk
in to two groups arguing to what they think are opposite sides but
then I end up hated by both groups. Well folks its a gift.
>
> What I look for in a crypto algorithm is simplicity and transparency,
> I want to be able to see what's happening, and analyse it in my head.
This is actually what I wanted to do. Any block cipher that does not
use previous internal memory states can be reduced down to a S-table
the size of the block. What this means is that if you write some wizbang
block cipher program for 8 bits. The NSA could give a shit how you do it
they need only treat it as a general case of the random 8 bit S-Table.
So ideally one wants to use the largest possible random S-Table. But the
problem is the key gets REAL BIG REAL FAST so it not feasable to go to
large at present. Second I noticed that many random S-tables can be
reduced to smaller S-tables. So I choose to limit mine to nonreduceable
single cycle random S-tables. When one is doing certain forms of attack
on certain structures any porperty known is a weakness so even if one limits
oneself to single cycle S-tables the key space is reduced and the attacks
can be more focused. However it is also considered a weakness to allow
such things as the identity transform the single cycle aspect ilminates
this. If such ciphers as Two Fish are any good I would be very surprised
if they are not just a special case of a very limited subset of a single
cycle S-Table. I would say that when one is analysisng such ciphers it would
be of great benifit to know this kind of information.
But in looking at various ciphers the goal long has been to try to
increase the block size. This cannot be done with out some sort of
internal chaining. Even IDEA which is considered a 64 bit cipher
only works on 16 bit words. So that is what I used as a baseline.
>
> Every release of ScottXX gets more and more complex, with no real
> justifications for the changes. Every layer of "security" just makes
> it harder to analyse, and therefore harder to trust.
I really did not intend to make it more complex. The main complexities
between scott16u and 19u are only do to the fact 16 bits is two bytes
while 19 bits is a bitch since one is stuck with 8 bit machine bytes.
I went to 19 since I fell one should be simple but on the edge at same
time. The 19 bit if a random key is used just fits on a floppy.
The chainning method is the main difference between my stuff and the
other weaker systems that flood the market. I felt the need to treat
the whole file as a block made from the working subblocks while IDEA
or DES types choose a much smaller block size. However they had there
reasons and one was the problem that if block size to big then the
ending problems can occur in last block which this thread is addressing.
But the chainnng methods are a very very weak link in modern block
encryption systems. I can see that when DES was invented why the
ones choosen are used. Mainly to recover from errors when data
block of encrypted text get corrupted. But in todays modern file
systems one wants a totally correct output or get a new copy.
"Wrapped PCBC" solves both problems you can end a long file on
any byte boundary without changing the size of the file. And it
adds the "all or nothing encryption" feature. It is not often one
can kill two birds with the same stone. But I can see why the crypto
gods and groups like the NSA are pushing weak chainning they want
the ability to break codes easily. The AES circus will not change
that feature until people wake up from there sleep.
As to making things more complex I really don't want to. I was
thinking heavily about adding compression. But that greatly will
add confusion. And at this point to be honest the best way to use
compression with my stuff is to just use pkzip and then encrypt the
file. The header plain text "PK" and such do little damage in my
system since it is all or nothing and if an attacker keeps trying
a key to match the first few bytes of the zipped file he will soon
find that more keys will create false soultions that match the
first few bytes than the whole key space of the weak AES methods
combined. Yes I said this on purpose to rasie the nasty snake oil
flag. But I will still add compression at this point sorry if it
makes it more complex. I may add options to allow one that analyzises
my code to vary the passes and dump the intermedate passes to files
if this would partial aleaveate you fears and concerns.
>
> For these reasons I like ARCFOUR. With ARCFOUR I can see what's
> happening, and I can understand why it's hard to crack. I find it
> extremely hard to believe that those few lines of code can contain
> any major weakness. Even ARCFOUR's weaknesses are easy to understand
> and appreciate. Understanding the weaknesses is important to
> understanding the threat they pose (nothing worth mentioning).
>
> To me, complexity is what kills a cipher... (just my $0.02)
I to think complexity kills a cipher. I still think my appraoch
is very simple in my mind. It is just translating those thouths
to C for the PC that is the complex part. (that and spelling these
dam words close enuff to something that people can decipher)
>
> --
> <\___/>
> / O O \
> \_____/ FTB.
>
> [1] Though he's not the only person doing so...
>
>
David 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
------------------------------
From: Money Concepts Unlimited <[EMAIL PROTECTED]>
Subject: Have you ever had your Astrological Charts done?
Date: Sun, 14 Feb 1999 18:37:38 GMT
==============B66F6AF96BB782EF18259805
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Interested in having your Astrological Charts Done for you, we have
available Birth (Natal) Charts, Transit Charts for your upcoming
birthday, and Compatibility Charts for you and your significant other...
For more information E-Mail: [EMAIL PROTECTED]
==============B66F6AF96BB782EF18259805
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Interested in having your Astrological Charts Done for you, we have available
Birth (Natal) Charts, Transit Charts for your upcoming birthday, and Compatibility
Charts for you and your significant other...
<p>For more information E-Mail: <a
href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a></html>
==============B66F6AF96BB782EF18259805==
------------------------------
** 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
******************************
