Cryptography-Digest Digest #687, Volume #13 Wed, 14 Feb 01 08:13:01 EST
Contents:
Re: National Security Nightmare? ("Douglas A. Gwyn")
Re: Super strong crypto (wtshaw)
Re: Building PGP 658 under Linux. (Ian Goldberg)
JSTV ("Niederhammer")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: What is an Inorder Algorithm? (Mok-Kong Shen)
Re: Factoring (and not the Philippino :) ("Michael Brown")
Re: OverWrite freeware completely removes unwanted files from harddrive ("Michael
Brown")
Re: OverWrite freeware completely removes unwanted files from hard drive ("Michael
Brown")
Re: Minimal-space authentication algorithm (Paul Crowley)
Re: Key Exchange (Paul Crowley)
Re: asking for stream cipher resource (Paul Crowley)
Re: Fractal encryption? (Mok-Kong Shen)
Re: National Security Nightmare? (JPeschel)
Big Numbers in C/C++ (Edward Rustin)
Re: The Kingdom of God (Volker Hetzer)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Wed, 14 Feb 2001 07:27:39 GMT
JPeschel wrote:
> Hmmm... my bother-in-law at Ft Meade sent me this one.
..............^ Freudian slip?
Thanks for the link to the "news" story. (The quotes
are because it's not new news.)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Super strong crypto
Date: Wed, 14 Feb 2001 01:45:29 -0600
In article <eY6Sa0hlAHA.340@cpmsnbbsa09>, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
> "wtshaw" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> Actually we do have absolute upper bounds on the strength of cryptographic
> algorithms. It is known quite flatly that Rijndael has an absolute upper
> bound of 128, 192, and 256-bits depending on how it is used. It is known
> that DES has an absolute upper limit of 56-bits. These are absolutes and are
> very well known. The attacks that are found against the algorithms decrease
> that bound, but it makes it no less an absolute bound. It has been said many
> tim by many different people, let me be the latest "Attacks never get worse"
>
You make my point, these algorithms as defined have low practical ceilings
of strength, but that is not true of all algorithms.
> > ....
> > > Any of the 5 [AES}
> > > of them should be strong enough for most things.
> >
> > Wrong, you need fix-um-up modes, whiuch mean that they lack sufficient
> > independent strength as ciphers.
>
> No it means that they deal only with the block cipher component, they do not
> deal with the key mutation, the integrity, the signing, etc. They are a very
> specific solution to a very specific problem. The debate regarding whether
> or not that is the problem is quite seperate from the debate of the strength
> of the ciphers themselves.
Again, they do not deal with variable output and when that is prescribed,
it is not within their structure to do it alone. From the beginning, I
was there, I called for that to be an integral part of the algorithms
submitted.
But, unfortunately, most did not understand the crux of getting real
security. When DES was announced many years ago, I doubled over laughing
at it. I knew the score then. It is still much of a joke that real
security was and is sidestepped.
Today's security problems are a result of lack of vision in the
promulgators of shallow interests. Now, folks, get excited looking for
better ways to do things, but some of them have always been known.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: Building PGP 658 under Linux.
Date: 14 Feb 2001 09:28:57 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Scherrey <[EMAIL PROTECTED]> wrote:
>I'm trying to build the source for PGP 658 and am having difficulties
>getting a complete build. I run the build script but it complains
>(eventually) about not being able to find -lPGPui which I take to be some
>file called libPHPui.[a|so] and probably the GUI part of the program
>which is only available in Windows. So... why is the cmdline version
>requiring a link to a GUI lib? Am I missing some option somewhere? I'd
>appreciate any pointers from anyone successfully building this under
>Linux. FWIW - I'm running x86 RedHat 6.2 using gcc-2.95.2.
So I've spent quite a while tracking down why the source code for PGP 6.58
under Linux (Redhat 6.2):
a) doesn't compile, and
b) when I get it to compile, produces encrypted messages that the
standard binary can't read
Len Sassaman and I finally got it working. Here's a patch to make PGP
6.58 both compile *and work* under Redhat 6.2:
diff -urN pgpsrc/libs/pgpcdk/priv/crypto/cipher/pgpCAST5.c
pgpsrc-fixed/libs/pgpcdk/priv/crypto/cipher/pgpCAST5.c
--- pgpsrc/libs/pgpcdk/priv/crypto/cipher/pgpCAST5.c Mon Oct 13 21:48:14 1997
+++ pgpsrc-fixed/libs/pgpcdk/priv/crypto/cipher/pgpCAST5.c Thu Jan 11 20:36:06
+2001
@@ -275,6 +275,7 @@
/* Some macros used in the encryption/decryption code */
#define ROL(x,r) ((x)<<(r) | (x)>>(32-(r)))
+#ifdef USE_BROKEN_GCC_ASM
#ifdef __GNUC__
#if __i386__
/* Redefine using GCC inline assembler */
@@ -284,6 +285,7 @@
__asm__("rol %%cl,%0" : "=g" (_y) : "0" (x), "c" (r)); _y;})
#endif /* __i386__ */
#endif /* __GNUC__ */
+#endif
#define F1(x,xkey,i) (ROL((xkey)[2*(i)] + (x), (xkey)[2*(i)+1]))
#define F2(x,xkey,i) (ROL((xkey)[2*(i)] ^ (x), (xkey)[2*(i)+1]))
diff -urN pgpsrc/libs/pgpcdk/priv/crypto/random/pgpRandomPool.c
pgpsrc-fixed/libs/pgpcdk/priv/crypto/random/pgpRandomPool.c
--- pgpsrc/libs/pgpcdk/priv/crypto/random/pgpRandomPool.c Fri Aug 6 16:56:49
1999
+++ pgpsrc-fixed/libs/pgpcdk/priv/crypto/random/pgpRandomPool.c Thu Jan 11 20:36:47
+2001
@@ -424,7 +424,7 @@
* #define UMULH_32(r,a,b) (r) = 0
*/
#ifndef UMULH_32
-#if defined(__GNUC__) && defined(__i386__)
+#if defined(__GNUC__) && defined(__i386__) && defined(USE_BROKEN_GCC_ASM)
/* Inline asm goodies */
#define UMULH_32(r,a,b) __asm__("mull %2" : "=d"(r) : "%a"(a), "mr"(b) : "ax")
#elif HAVE64
diff -urN pgpsrc/libs/pgpcdk/unix/ui/PGPKeyServerDialogs.cpp
pgpsrc-fixed/libs/pgpcdk/unix/ui/PGPKeyServerDialogs.cpp
--- pgpsrc/libs/pgpcdk/unix/ui/PGPKeyServerDialogs.cpp Tue Mar 9 21:52:17 1999
+++ pgpsrc-fixed/libs/pgpcdk/unix/ui/PGPKeyServerDialogs.cpp Thu Jan 11 20:43:33
+2001
@@ -5,6 +5,7 @@
$Id: PGPKeyServerDialogs.cpp,v 1.2 1999/03/10 02:52:17 heller Exp $
____________________________________________________________________________*/
#include <string.h>
+#include <stdlib.h>
#include "pgpDialogs.h"
#include "pgpKeyServerDialogCommon.h"
And, as a bonus feature, here's a patch to fix a bug which prevented my
PGP scripts from working under 6.x. The bug is this: even when +compat
and -force are given, PGP will ask you "are you sure you want to use this
key?" where 2.6 didn't. This breaks scripts, of course. Here's the
simple fix:
diff -urN pgpsrc-fixed/clients/pgp/cmdline/doencode.c
pgpsrc-ian1/clients/pgp/cmdline/doencode.c
--- pgpsrc-fixed/clients/pgp/cmdline/doencode.c Thu Sep 30 20:10:21 1999
+++ pgpsrc-ian1/clients/pgp/cmdline/doencode.c Thu Jan 11 20:50:20 2001
@@ -283,6 +283,7 @@
PGPBoolean batchmode = pgpenvGetInt( env, PGPENV_BATCHMODE, &pri, &err );
PGPBoolean verbose = pgpenvGetInt( env, PGPENV_VERBOSE, &pri, &err );
PGPBoolean quietmode = pgpenvGetInt( env, PGPENV_NOOUT, &pri, &err);
+ PGPBoolean force = pgpenvGetInt( env, PGPENV_FORCE, &pri, &err);
PGPKeySetRef tmpset;
err = PGPNewEmptyKeySet( toSet, &tmpset );
@@ -317,7 +318,7 @@
if(verbose)
pgpShowKeyValidity( filebPtr, key );
- if( validity < kPGPValidity_Marginal ) {
+ if( validity < kPGPValidity_Marginal && !force) {
char useridstr[ kPGPMaxUserIDSize ];
PGPBoolean answer;
err = pgpGetUserIDStringFromKey( key, useridstr );
Now all my scripts work again! Yay!
- Ian
------------------------------
From: "Niederhammer" <[EMAIL PROTECTED]>
Crossposted-To:
alt.binaries.cracks.encrypted,alt.binaries.dominion.warez.decrypted,alt.satellite.tv.crypt,alt.sources.crypto
Subject: JSTV
Date: Wed, 14 Feb 2001 09:18:22 +0100
Who knows how to crack the videocrypt of JSTV ?
Giumartello
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Wed, 14 Feb 2001 09:40:42 GMT
wtshaw wrote:
> But, unfortunately, most did not understand the crux of getting real
> security. When DES was announced many years ago, I doubled over laughing
> at it. I knew the score then. It is still much of a joke that real
> security was and is sidestepped.
If you really have insights into "real security", please write them
up in a form that others can understand and publish them. DES met
its design goals admirably, and in fact exceeded them. Even today
nobody admits to knowing any attack on the DEA that is appreciably
better than a brute force search of the key space. That is quite
an accomplishment for a cryptosystem that has been the subject of
intense scrutiny by so many for so long.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.c,alt.comp.lang.learn.c-c++,sci.math,comp.lang.c++,comp.lang.java.programmer,comp.programming
Subject: Re: What is an Inorder Algorithm?
Date: Tue, 13 Feb 2001 20:25:37 +0100
Riordan wrote:
>
[snip]
> Imagine the following tree-like structure
> A
> / \
> B C
>
> Then postorder would process in the order:
> B, C, A
> Pre-order would go:
> A, B, C
> & In-order would go:
> B, A, C
I am not quite sure of that. According to Knuth, vol. 1,
one will have:
Postorder: B, A, C.
Preorder: A, B, C.
Endorder: B, C, A.
M. K. Shen
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Factoring (and not the Philippino :)
Date: Wed, 14 Feb 2001 23:45:26 +1300
"Tomas Rosa" <[EMAIL PROTECTED]> wrote in message
news:3a87ff98$[EMAIL PROTECTED]...
> It seems that your article is about "just another" representation of
> nonlinear boolean equations, which can be derived from the binary
> representation of the multiplication in the form n=p*q.
>
I've never run into these before. Is there somewhere that has a bit of
information on these sort of things (calculus is more my kind of poison :)?
I tried google, but the stuff it came up with was WAY over my head.
> Unfortunately the nonlinearity of these equations grows very rapidly (due
to
> the carry output), so it is "very, very, very, very, ..., very" unlikely
> that you will find any effective way to solve them (with respect to the
> appropriate length of n, of course).
>
The only problem that I have at the moment is for solving for when the 2
LSBs of the product are not both 1 (however, this should immediately kill
~50% of current RSA keys I presume? That's an interesting question - do 50%
of prime numbers have a second least significant bit of 1?). The algebraic
approach works, and is fairly easy to see how to implement (constant*a
combination of a's and b's), but hard to actually implement.
As I showed on the site (or thought I did. I probably didn't make it too
clear), the actual complexity depends more on the number of bits that are
the same on the left hand part of the two factors. This is mainly an
observation of when I was trying to factor using the algebraic approach. I
cannot attach a number to it, but I can say that the complexity (and hence
the security) APPEARS to depend more heavily on the number of identical left
hand bits than on the length of the key. For example 0111*1101 is less
complex than 1101*0101 (probably not all primes because I can't be bothered
checking them at 11:30 PM, but you get the idea).
> However if you are still interested enough to continue in your work, then
> the only think I could recommend you is to focus yourself on the area of
> nonlinear boolean equations. This will mainly help you to formalize your
> ideas about the behavior and power of the basic constraints observed and
> mentioned in your document (referred to as "clever tricks" as I know).
>
Do you mean focus on implementing and experimenting with the cases where the
2nd LSB of the product is 1? What I was actually fiddling around with at the
moment was trying to see if there was an alternative to the algebraic
approach.
One thing which I have tried fiddling with (without much sucess) is to do
the whole thing using the algebraic approach (ie: generate and solve to the
maximum extent the first column, then do the same for the second column, an
so on). This method works, but I'm sure for larger products it would be far
too slow (also probably been done several times before, so I won't spend
much more time with it).
> have a nice day
As always :)
Thanks for the input,
Michael
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files from harddrive
Date: Wed, 14 Feb 2001 23:56:31 +1300
<SNIP>
> >
> > I checked the web pages, but I can't find any description for how the
> > program ensures that the multiple overwrites actually take place. There
> > are several ways it could fail for a naive implementation:
> >
> > - The OS may allocate new disk blocks when writing the patterns, leaving
> > the old data unaltered
> > - The OS may cache the writes, only actually writing the last pattern to
> > disk (or not even that if the file is removed afterwards)
> > - The SCSI controller may cache the writes
> >
> > I'm interested in how you've solved this.
> >
> > Andreas
> >
> > --
> > Andreas Gunnarsson <[EMAIL PROTECTED]>
> > +46 31 7014268
>
>
> I don't see what you suggest could happen happening.
>
I can. My HDD has 2mb cache. Having tested various things I can shove far
more data that I should be able to through the HDD. In other words, it ain't
writing it all.
> Give us a specific example where you have written source code that
> says to open a file and write to the file where the computer did not
> carry out this instruction.
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.conspiracy
Subject: Re: OverWrite freeware completely removes unwanted files from hard drive
Date: Wed, 14 Feb 2001 23:58:20 +1300
I think the point he was trying to make is that you shouldn't have
unencrypted info on your HDD (force OS to keep in RAM and only store when
encrypted).
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hit1Hard wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> >
> > > So where are these technological sophisticates: these brain drained
> > > mental armchair hackers, now?
> > >
> >
> > They make sure the "crucial" information on the HD is encrypted with
> > their own encryption software.
> > wich is not placed on the system HD's.
> > Oh. And the swapfile is empty.
> >
> > >
> > > Thanks for the grilling.
> >
> > anytime.
> >
> > --
> > Hit1Hard
>
>
> You seem to have changed the topic of this thread.
>
> The thread is about overwriting confidential data on a hard drive.
>
> It is a given that there is confidential data on the hard drive
> that one desires to make unrecoverable.
>
> Of course, if there is no confidential data on the hard drive then
> there would be no need to overwrite confidential data that does not
> exist.
>
> Hit one hard for me while you're at it.
------------------------------
Subject: Re: Minimal-space authentication algorithm
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2001 10:53:13 GMT
H. Peter Anvin <[EMAIL PROTECTED]> writes:
> I'm looking for an encryption and/or authentication algorithm (the
> latter is actually more important) that can be implemented in minimal
> code space -- literally every byte counts. I have looked at TEA,
> including the extensions by Needham and Wheeler (Oct 1997), but some
> of the back archives of this group seem to imply that it may not be
> that good of a cipher algorithm. I wonder if anyone could comment on
> this, or perhaps suggest alternatives.
Do the client and server have a shared secret? If so, then it sounds
like what you want is a cipher+MAC, and all your security requrements
are achievable.
Is Rijndael's 256-byte substitution table prohibitively large? It's
the same whatever the key is and can be burned into ROM. The Rijndael
team, with Michael Peters and Gilles van Assche, have designed a new
block cipher, Noekon, designed specifically for when resources are
very limited (http://www.cryptonessie.org/); of course this is a new
cipher so it won't have received much cryptanalysis.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: Key Exchange
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2001 10:53:13 GMT
George <[EMAIL PROTECTED]> writes:
> I'm working on a project where I need to have a client and a server
> agree on a session key. What algorithm would be the MOST secure to use?
> (Keeping in mind there is ONLY Alice and Bob and NO Trent). If
> DiffieHelman were to be used, how often should Alice and Bob generate
> new session keys? Any help is greatly appreciated. Thanks.
No algorithm is most secure; the security of any strong PK algorithm
can be increased by adding an extra bit to the keylength.
Diffie-Hellman with 1024-bit p is generally considered hard. When to
generate session keys depends on other considerations of your
application, since there should be no need to worry that any of your
crypto primitives will be cryptanalysed. Remember to authenticate to
avoid MITM attack.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: asking for stream cipher resource
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2001 10:53:14 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> writes:
> Eric wrote:
> >
> > Could any one give me some web sites about stream cipher background,
> > publications etc. ?
>
>
> http://www.ciphile.com
Beware that crypto-knowledgable people consider this site garbage.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption?
Date: Wed, 14 Feb 2001 12:40:18 +0100
A more recent paper in chaos literatures that seems to have
some connection to crypto is:
T. L. Carroll, L. M. Pecora, Using multiple attractor
chaotic systems for communication. Chaos 9(1999) p.445ff.
Something termed chaos synchronization appears to play a role.
My knowledge is much too poor to understand the topic, which
apparently goes back quite a time in the chaos literatures.
Hopefully the pointer could be of use for some experts of
the group to initiate related researches.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 14 Feb 2001 12:13:02 GMT
Subject: Re: National Security Nightmare?
Douglas A. Gwyn [EMAIL PROTECTED] writes:
>JPeschel wrote:
>> Hmmm... my bother-in-law at Ft Meade sent me this one.
>..............^ Freudian slip?
>
Oops, well, for chrissake, don't tell him! :-)
>Thanks for the link to the "news" story. (The quotes
>are because it's not new news.)
'Twas new news to me!
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Edward Rustin <[EMAIL PROTECTED]>
Subject: Big Numbers in C/C++
Date: Wed, 14 Feb 2001 12:13:12 GMT
Hi,
Does anyone know where I can find information about working with big (1024
bit+) numbers under C or C++?
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: The Kingdom of God
Date: Wed, 14 Feb 2001 13:39:01 +0100
JPeschel wrote:
>
> [EMAIL PROTECTED] (Niklas Frykholm) writes:
>
> >>> Smile! There is no god.
> >>
> >>And if there was would it matter anyways?
> >
> >Yes! If there is a god it can probably break all the cryptography in use
> >today, since recent theological findings have indicated that god is
> >not polynomially bounded.
> >
> >I am working on a 666-bit cipher which will be safe from the prying eyes
> >of god.
>
> But God already knows the plaintext.
Ok, now all we need is a way to make him tell us. Any ideas?
How many candles does it take to get at verisigns private key?
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
