Cryptography-Digest Digest #989
Cryptography-Digest Digest #989, Volume #13 Sat, 24 Mar 01 14:13:01 EST Contents: Re: Hello (Frank Gerlach) Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (SCOTT19U.ZIP_GUY) Re: decryprtion help please? (SCOTT19U.ZIP_GUY) Re: Idea - (LONG) (amateur) Re: Open Source Implementations of PGP (SCOTT19U.ZIP_GUY) Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be (Frank Gerlach) Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be (Frank Gerlach) Re: Idea - (LONG) (SCOTT19U.ZIP_GUY) Re: decryprtion help please? (Jim Gillogly) Re: Crack it! (Mok-Kong Shen) From: Frank Gerlach [EMAIL PROTECTED] Subject: Re: Hello Date: Sat, 24 Mar 2001 20:11:38 +0100 Tom St Denis wrote: Um anyone home? I posted a question 6hrs ago and no reply. BTW the NSA broke PGP and B.S works for the commies (that should get a reply, then while you are flaming me reply to my other question please...) -- Tom St Denis --- http://tomstdenis.home.dhs.org No, the NSA is sabotaging the usenet :-) -- From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) Crossposted-To: alt.privacy.anon-server,alt.security.pgp Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged Date: 24 Mar 2001 18:21:30 GMT [EMAIL PROTECTED] (Bill Unruh) wrote in 99imvl$ab$[EMAIL PROTECTED]: In 99av4l$q67$[EMAIL PROTECTED] Pawel Krawczyk [EMAIL PROTECTED] writes: In sci.crypt Bob C. [EMAIL PROTECTED] wrote: The exploit works by attacking the Digital Signature Algorithm's so-called discrete logarithm problem. DSA keys are typically stored in a file called secring.skr, and Klima and Rosa found that they could successfuly insert a replacement key in it. Every day new details leak painfully slow from the ICZ and it's still getting closer to another instance of what Bruce Schneier called `publicity attack'. First comments from ICZ suggested that the PGP has been broken, then that the secret key can be retrieved without knowing the passphrase, now we learn that you can substitute private key with your own, if you have access to the keyring. What an invention! ;-\ If this is right then the OpenPGP standard is broken. To break a cryptosystem does not necessarily imply breaking just the algorithm. A crypto system is the whole system, including the key storage. displaying a weakness anywhere is a break of the cryptosystem. This is an inherent I don't think you really belive what your saying "a weakness anywhere is a break of the cryptosystem" if you belived that the combination of non 1-1 compression with the encryption algorithm is also a break. But few seem to care and they claim its minor. David A. Scott -- SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE http://www.jim.com/jamesd/Kong/scott19u.zip Scott famous encryption website **now all allowed** http://members.xoom.com/ecil/index.htm Scott LATEST UPDATED source for scott*u.zip http://radiusnet.net/crypto/ then look for sub directory scott after pressing CRYPTO Scott famous Compression Page http://members.xoom.com/ecil/compress.htm **NOTE EMAIL address is for SPAMERS*** I leave you with this final thought from President Bill Clinton: -- From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) Subject: Re: decryprtion help please? Date: 24 Mar 2001 18:13:34 GMT [EMAIL PROTECTED] (rh) wrote in EI3v6.172$[EMAIL PROTECTED]: A buddy had asked me yesterday, if it would be possible to migrate all of our pins from the current main system to the new test pin vault. We have no decryption utility that could do this. Below I have included some clear text pins and then the encrypted version that is located in the SQL database.I do know that the clear text pins "are encrypted with themselves." Pin Encrypted Pin in SQL DB 1234 9EE7964577447ADA 1F1D2C2ED301B2A6 test 8A49D1CCB9AA5DBB hello 7F85C0A9F3F86EC0 4567 60956233056154AC 1234565155482C2078BF2C voyager 73C63521A96FF1C9 ATLAS BFC44BCCC9ED5EE5 -- Robert Hawks http://www.elitedaytraders.com Since each thing is "encrypted to same size" 64 bits it could be DES encryption. What is the size limit on password. Also its possible it could be a HASH of some type. Since you have the utillity that does the encryption it should not be that hard to trace through it and see what its using. Anotherpoint if the DATA base is anygood you can migrate the encrypted pins over. Since the code should always should encrypt any pins and then compare the test encrypted pin with the data base stored value assuming your using same encryption method for new system. Another common why would to be give users of old pins a time period where they old system would be in use to optionally check using old method. If key passes then store it
Cryptography-Digest Digest #989
Cryptography-Digest Digest #989, Volume #12 Mon, 23 Oct 00 18:13:00 EDT
Contents:
Re: Huffman stream cipher. (Tom St Denis)
Re: toy cipher question (Tom St Denis)
Re: toy cipher question (Tom St Denis)
Re: Hypercube/FFT encryption (James Felling)
Re: Problem with the CS-Cipher (Tom St Denis)
Re: My comments on AES (Tony L. Svanstrom)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: Steganography books (wtshaw)
Re: How about the ERIKO-CHAN cipher? ("Mark Dowdey")
Re: As I study Rinjdael... (SCOTT19U.ZIP_GUY)
Re: As I study Rinjdael... (Mok-Kong Shen)
Re: Rijndael implementations (Tim Tyler)
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Huffman stream cipher.
Date: Mon, 23 Oct 2000 19:55:43 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
Maybe the 19x19 bit S tables are bigger than what most people are
use to.
Yes I would say a 19x19 table is not only crazily large but terribly
inefficient. Sure I could make a secure block cipher (Bruce Schneier
like rant comming up...) out of 128 rounds of a simply stupid round
function however good crypto is about doing good things with
less and faster. Using a 19x19 table is hardly a sign of "doing things
with less or faster"
I guess you don't realize that warning is not the same as error.
I use to get warning from compliers all the time. It just means becare
or use at you on risk which really goes with all software. But a
warning is not an ERROR. Portability to other systems is not a high
priority with me. Getting code to work on the machine I use is. Hell
when I worked for the US gorvernment people who thought they were
using
portable fortran also got a shock when there code did not work the
same
on next verison of fortran on the same machine. I don't like to change
compiler versiions even in C. I would not be surprised in the next
release of GNU C for DJGPP it may not work. But it does for the
current
version. One could chase portability issues for ever but you never
really know the code is portable until you test it on the machine.
My fun is getting it to work on the machine I have access to with the
tools I have. I figure if some one wants to use it in another machine
or compiler of there choice they have to get it to work. However
since I am retired I would be willing to work for CASH to get it to
work on another machine and or version of a compiler.
Not only is your thread (with Richard) off-topic (move to comp.lang.c
please) but your statement is plainly wrong. Good C code should
compile without fuss on any platform with sufficient resources. For
example the source code to my block ciphers (well some of them)
compiles without fuss for an Intel 8051 as it would for a pentium
(while the pentium is much much faster... that's another story).
Also I use "void main(void)" quite a bit, I know it's wrong, and not at
all portable. I really should be carefull.. You're right that in all
honesty it doesn't matter, but if you're trying to impress others or
write code that is semi-portable you're better off cleaning up the code.
C was not designed for portability. It was designed to make
programing
easyer on NEW machines without having to rely soley on machine
language
it is a tool to help nothing more.
I would say you're full of it now. C was purely designed to be
portable. That is why a "standard library" was developped shortly
after the syntax was born. In fact the library was standardized much
before the syntax "such as quarky things like "auto"". I think you
should read "KR C" the official C bible (it's only 40 bucks) or
perhaps the second edition for some references.
Just because you're code is not portable doesn't mean C wasn't designed
to be portable...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: toy cipher question
Date: Mon, 23 Oct 2000 20:01:07 GMT
In article [EMAIL PROTECTED],
Benjamin Goldberg [EMAIL PROTECTED] wrote:
I have a few functions that I want to use as components of a cipher,
and
I want to know how secure they are on their own (ie, if used as
complete
ciphers)... Or at least, how strong are they relative to each other,
using various values for the "rounds" variable. Assume that k
contains
(2*rounds) truly random bytes, and sbox8 and sbox16 have "good"
properties.
void toya( unsigned char *ct, unsigned char *pt, unsigned char *k )
{
char a = pt[0], b = pt[1], i;
for( i = 0; i rounds; ++i ) {
a = sbox8[a + *k++], b = sbox8[b + *k++];
a += (b += a); }
ct[0] = a; ct[1] = b;
}
v
Cryptography-Digest Digest #989
Cryptography-Digest Digest #989, Volume #8 Thu, 28 Jan 99 15:13:02 EST
Contents:
256-bit block cipher ([EMAIL PROTECTED])
Re: Random numbers from a sound card? ([EMAIL PROTECTED])
Any known probs with 2PKDP (KryptoKnight)? (Christian Muszynski)
Re: hardRandNumbGen (Patrick Juola)
Re: hardRandNumbGen (Patrick Juola)
(no subject) (barak)
Re: Random numbers from a sound card? (Medical Electronics Lab)
Re: Encoding for telephone over Internet (fungus)
Blowfish: Affecting strength of algorithm? ("Uta Loeckx")
Re: Who will win in AES contest ?? (David Hamilton)
Re: Foiling 56-bit export limitations: example with 70-bit DES ([EMAIL PROTECTED])
Merchants needed for software beta testing (Kent Briggs)
Re: My comments on Intel's Processor ID Number (Barry Margolius, NYC)
Re: RNG Product Feature Poll (Dan S. Camper)
From: [EMAIL PROTECTED]
Subject: 256-bit block cipher
Date: Thu, 28 Jan 1999 17:23:32 GMT
256-bit block cipher
The size of the block is 256 bits or 32 bytes.
Inserted key is transformed to 256 bytes( effective key)
using 8-bit Alex chained encryption.
There are two interpretations of the key. One of them
is mentioned above in 8-bit chained encryption a sequence
of automorphisms of a group. The second is the sequence
of transpositions of bits in block. Each byte of the key
represents a simple transposition of bits as follows:
index of byte is the index of the first bit in block and the
context of the byte is the index of the second bit in block.
During encryption of the block the key is scanned from the
beginning to the end and during decryption reverse.
Encryption follows in two steps:
1. A block is encrypted using 8-bit Alex chained algorithm.
This approach gives suitable dispersion of 1 and 0 bits in
the block.
2. A transposition of all 256 bits in block is made using
256 byte key.
This algorithm is implemented and has performance apr.127 Kb/sec.
The full Delphi 4 source code, freeware executable, updated
algorithm description are available for download at
www.online.de/home/aernst
Please follow the link 'Alex8x256.zip'
Regards
Alex
= Posted via Deja News, The Discussion Network
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
From: [EMAIL PROTECTED]
Subject: Re: Random numbers from a sound card?
Date: Thu, 28 Jan 1999 18:10:41 GMT
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Note that even using a highly structured signal (e.g., digitized
video program including your local receiver noise) you could generate
good bits, but you'd have to distill bushels of them.
I find your experience interesting. (In another thread I suggested
obtaining good bit sequences from such materials as natural
language texts.)
M. K. Shen
There is a big difference. Eve does not know the local, instantaneious
electromagnetic conditions around my receiver, nor does she know what
my local electronics are doing.
The point is that measuring something physical is nothing like
playing with text streams, unless you you get them via UDP and
have a real bad link :-)
"Properly done science is a sort of masochistic game where one beats
one's head against a wall until it falls down, and then goes in search
of another wall." --Steven Vogel
= Posted via Deja News, The Discussion Network
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
From: Christian Muszynski [EMAIL PROTECTED]
Subject: Any known probs with 2PKDP (KryptoKnight)?
Date: Thu, 28 Jan 1999 19:30:21 +0100
Hi everybody,
I have to implement an authentication and encryption system for a
wireless
data communication environment. This is an environment which has some
special characteristics as:
- small bandwith
- higher reaction times
- high transmission costs
- high error rate
- clients with reduced ressources concerning processing power and memory
What I need is a system for mutual authentication between client and one
communication server, data encryption and MAC of data packets.
I can't integrate a standard solution as IPsec because I don't have an
IP connection between communication server and the mobile client,
but a specific point to point protocol.
Two achieve these goals for this special environment I need a slim
protocol and an effective algorithm. At the moment I am thinking of
the Two Party Key Distribution Protocol (2PKDP) (also integrated in
KryptoKnight family). As algorithm I plan to take Blowfish for the
encryption part, MAC-calculating and perhaps part of the
number generator(with some realtime events as millisecondtimer, consumer
reacktions, Process data as intialisation and key).
I think Blowfish is ok for this MAC use, because the MAC is just
