Cryptography-Digest Digest #154, Volume #13 Tue, 14 Nov 00 08:13:00 EST
Contents:
Re: XOR Software Utility (freeware) available from Ciphile Software ("Midnight's Own
Fire")
Re: XOR Software Utility (freeware) available from Ciphile Software ("Midnight's Own
Fire")
Re: Hash used in prepaid phone cards. (those who know me have no need of my name)
Re: Hash used in prepaid phone cards. (Ariel Burbaickij)
Re: DES advice ("kihdip")
Re: DES advice (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
Re: Algorithm with minimum RAM usage? (Paul Rubin)
Re: Algorithm with minimum RAM usage? (Paul Rubin)
Re: Algorithm with minimum RAM usage? (Guy Macon)
Re: hardness of monoid word problem? (stanislav shalunov)
Re: "Secrets and Lies" at 50% off (Paul Crowley)
Re: Anyone done/doing Schneier's self-study cryptanalysis course? (Paul Crowley)
XORred zipfile chunks = random? ([EMAIL PROTECTED])
Re: Why remote electronic voting is a bad idea (was voting through pgp) (Tommy the
Terrorist)
Re: On an idea of John Savard (Tom St Denis)
Re: XORred zipfile chunks = random? (Tom St Denis)
Re: I would like your opinion on this (Tom St Denis)
Re: PGP still the no1? (Tom St Denis)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (d)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (d)
----------------------------------------------------------------------------
From: "Midnight's Own Fire" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 14 Nov 2000 05:17:55 GMT
root1657 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Anthony Stephen Szopa wrote:
>
> > If you know what you are talking about then you must have resources
> > to check the behavior of the software while it is running: such as
> > a firewall or virus protection?
> >
> > Some are free, you know.
> >
> > Give us some proof if you can.
> >
> > Or are you too pathetically feeble minded?
First off... if I were doing what you seem to be doing... I'd burry the
damned thing so deep... that it would not manifest itself in anyway... for a
while.
> Without even having seen the program, or it's code, i would caution anyone
> against using a program written or endorced by a person with an attitude
like
> that..... It just gives off a "malicious code" vibe....
> xxx
No kidding... but the file size itself does that.
------------------------------
From: "Midnight's Own Fire" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 14 Nov 2000 05:17:55 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8ua38p$bk4$[EMAIL PROTECTED]...
>
> That's insane... learn how to trim executable sizes...
>
> At http://www.geocities.com/tomstdenis/files/xor.c is a copy of the
> same program that does most common error handling (read/write errors,
> invalid file opens, etc...)... except for forgetting a "return 0;" at
> the end of main()I think it's a complete application.
>
> It's only 9kb when compiled with Turbo C 2.01...
>
> Tom
bet I could write it in vb in just under 7k. maybe not tho... heh.
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Hash used in prepaid phone cards.
Date: Tue, 14 Nov 2000 05:42:25 -0000
<[EMAIL PROTECTED]> divulged:
>Question: What is the standard(or most ofen) hash function
> used to discriminate between valid and invalid
> PIN-number very quickly?
there is probably no hashing being done, just a database lookup. (the
database system will probably use a hash to locate the key bucket.)
--
okay, have a sig then
------------------------------
From: Ariel Burbaickij <[EMAIL PROTECTED]>
Subject: Re: Hash used in prepaid phone cards.
Date: Tue, 14 Nov 2000 08:22:18 +0100
those who know me have no need of my name wrote:
>
> <[EMAIL PROTECTED]> divulged:
>
> >Question: What is the standard(or most ofen) hash function
> > used to discriminate between valid and invalid
> > PIN-number very quickly?
>
> there is probably no hashing being done, just a database lookup. (the
> database system will probably use a hash to locate the key bucket.)
>
> --
> okay, have a sig then
Well but you somehow have to fill your database (just random number
generator
? )or something more deeper ?
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: DES advice
Date: Tue, 14 Nov 2000 08:27:14 +0100
You'll find test-vectors in this document:
http://csrc.nist.gov/nistpubs/800-17.pdf
At page 134 you'll find round results.
Kim
------------------------------
From: Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: DES advice
Date: Tue, 14 Nov 2000 09:50:29 +0200
Bob Luking wrote:
> Unfortunately, the ciphertext is incorrect (according to FIPS 81). Somehow,
> my interpretation
> of the DES specification is lacking...
You may have confused the way the bits are numbered. At least, that's what I
did. Bit 1 is on the left and bit 32 is on the right. (Or was it so? ;))
-- Panu H�m�l�inen
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Algorithm with minimum RAM usage?
Date: 14 Nov 2000 00:18:22 -0800
[EMAIL PROTECTED] (Guy Macon) writes:
> The list of AES candidates I saw didn't include Skipjack. Is there
> a reason why not? The lowest RAM user on the list is Rijndael.
>
> (Rijndael uses 36 bytes of RAM plus the key. (It's important to count
> them separately not only because the key may be in ROM, but it might
> be in EEPROM with limited number of write cycles - good for keys, bad
> for frequently written to RAM).)
Skipjack predates AES and is a 64-bit block cipher with an 80 bit key.
That does not meet the AES requirements, but it's good for most
things. If the 80 bit key isn't enough, you could use 128 bits of
whitening (like DESX) or triple Skipjack (like 3DES).
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Algorithm with minimum RAM usage?
Date: 14 Nov 2000 00:22:50 -0800
[EMAIL PROTECTED] (Guy Macon) writes:
> >Skipjack has 64 bit blocks and a (very low) 80 bit key size.
> >
> >Too, Skipjack is from the NSA. In fact, it is the first algorithm ever
> >published by the NSA. In fact, it was never intended to get published.
>
> Ah. I see. Looks like Rijndael is the best choice if I want strong
> encryption in minimum RAM.
I wouldn't call 80 bits a very low key size. It's probably barely
breakable (by brute force) by very rich organizations (e.g. the NSA).
It's completely outside the practical range of anything like
distributed.net or Deep Crack. Distributed.net is still working on an
RC5-64 problem (64 bit key) and the estimated completion time is
measured in YEARS. 80 bit Skipjack has 65536 times more keyspace.
What kind of application do you have, that makes 80 bits not enough?
Note that Skipjack's 80 bit key corresponds to the security parameter
for free collisions in SHA-1 and brute force signature forging in DSA.
So if SHA-1 and DSA are good enough for you, Skipjack might also be
good enough.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Algorithm with minimum RAM usage?
Date: 14 Nov 2000 08:37:28 GMT
Tom St Denis wrote:
>
> [EMAIL PROTECTED] (Guy Macon) wrote:
>>
>> Ah. I see. Looks like Rijndael is the best choice if I want strong
>> encryption in minimum RAM.
>
>Strong is in the eye of the attacker who knows the implementor who just
>met the user and is buying them a cup of coffee trying to get their
>secret key... hehehe
>
>Just throwing Rijndael at a program will NOT (NOT NOT NOT!!!) make it a
>secure application. Be careful!
I knew that, but the comment is always welcome.
Most security systems are like chains that are only as strong as the
weakest link. Strong encryption just means that the link that resists
pure cryptography attacks is strong.
Alas, I often make systems with no human involved. Encryption in such
cases is better than just sending the message in the clear, but there
is no way to provide security for a shared secret that is inside a
silicon chip that is anywehere near as strong as the strength of the
encryption. :(
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: hardness of monoid word problem?
Date: 14 Nov 2000 03:40:40 -0500
[EMAIL PROTECTED] (MikeAt1140) writes:
> 1994
> V.M.Sidel'nikov,M.A.Cherepenev and V,V Yashichenko,
^^^^^^^^^^ ^^^^^^^^^^^
The former underlined name should be "Cherepanov". The bearer of the
former usually spells his last name in Roman alphabet as "Yaschenko".
The "i" is a typo in any case.
> "Systems of open distribution of keys on the basis of noncommutative
> semigroups",
> Russian. Acad. Sci. Dokl. Math. Vol.48 No.2 (1994) 384-386
--
Stanislav Shalunov <[EMAIL PROTECTED]> Internet Engineer, Internet2
"Nuclear war would really set back cable [television]." -- Ted Turner
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Tue, 14 Nov 2000 09:57:04 GMT
James Felling wrote:
> As to the snake oily ness of his product, while it does seem a little oily,
> esp the tangle code as documentation, it also seems to do what it says it
> would reasonably well. So if it is snake oil it is high grade snake oil. My
> personal opinion is that it is not snake oil, just somewhat iffy and if it
> were cleaned up and vetted I might just use it.
Why would you use this rather than a system based on a peer-reviewed,
well regarded encryption algorithm such as Rijndael?
Either you have some extraordinary reason to believe good things about
his program that I'm not privy to, or it's snake oil that you're almost
prepared to drink. How did you conduct your security analysis of this
program? I'm under the impression that no serious cryptanalysis of this
algorithm has been attempted - am I mistaken?
This is a very odd assertion. I would certainly like to hear more about
the reasoning behind it.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Anyone done/doing Schneier's self-study cryptanalysis course?
Date: Tue, 14 Nov 2000 09:58:52 GMT
Fritz Schneider wrote:
> Hello all. I'm curious to see if there's anyone out there that
> wouldn't mind corresponding with me about Bruce Schneier's self-study
> block cipher cryptanalysis course.
> Perhaps if there's enough interest we could start a site where
> people can post their progress at each stage in order to help each other
> along?
I think this is a good idea. I'd suggest either starting a mailing list
with topica or egroups, or starting a diary on kuro5hin.org.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED]
Subject: XORred zipfile chunks = random?
Date: Tue, 14 Nov 2000 10:24:16 GMT
(sorry to post this again, but deja doesn't seem to carry
sci.crypt.random-numbers)
This easy to implement, quick and dirty method may be naive,
simplistic, trivial etc. but it seems to work...
Take a 3 minute audio cd .wav file (or record your own), zip it to
improve uniformity of bits, giving around 30MB. Compile and run program
below (or use my one time pad program at <http://www.vidwest.com/otp/>,
creating an 11MB file and test with DIEHARD. If it doesn't pass, repeat
above using a longer .wav - it will eventually.
So,
1. Is DIEHARD broken? Probably not. Is there a better RNG tester? 2.
Even if it is possible to distinguish between pseudo-random and 'true'
random (say, from a radioactive source), so long as the former is
unrecreatable...
3. What is random anyway??? (this posting perhaps :-)
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
FILE *ifp, *ofp, *tfp; long n, i; int ic, oc, ieof;
if (argc != 4 || !(n = atol(argv[1])) || !(ifp = fopen(argv[2], "rb")))
{
fprintf(stderr, "To XOR n-size file chunks: %s n infile outfile\n",
argv[0]);
return 1;
}
for (ieof = 0, ofp = NULL; !ieof; ) { /* kludge */
if (!(tfp = fopen("XOR.TMP", "wb"))) {
fprintf(stderr, "\nError#2 Disk write-protected?\n"); return 2; }
for (i = 0L; i < n; i++) {
if (ieof || (ic = getc(ifp)) == EOF) { ic = '\0'; ieof = 1; } if (!
ofp || (oc = getc(ofp)) == EOF) { oc = '\0'; }
if (putc(ic ^ oc, tfp) == EOF) {
fprintf(stderr, "\nError#3 Disk full?\n"); return 3; }
}
fclose(tfp); if (ofp) { fclose(ofp); } remove(argv[3]);
rename("XOR.TMP", argv[3]); ofp = fopen(argv[3], "rb"); }
return 0;
}
--
Thanks for giving this your attention,
David West. <[EMAIL PROTECTED]>
PS. Does anyone have the pkzip format spec?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tommy the Terrorist <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Why remote electronic voting is a bad idea (was voting through pgp)
Date: 14 Nov 2000 09:49:03 GMT
In article <[EMAIL PROTECTED]> Roger Schlafly,
[EMAIL PROTECTED] writes:
>With a PGP-type approach, there are various authentication methods
>possible, such as certs. But ISTM it would be a much greater burden
>on the voter, requiring special ID and registration requirements.
>And all it would take would be some flawed CA procedure, and someone
>will anonymously vote 1000s of times. I just don't see how you'd
>manage the fraud problem. (But go ahead and make suggestions.)
Managing the fraud FROM THE VOTER will be trivial.
You've already heard of the so-called "electronic signatures", right?
The point is, they plan to bet MONEY on those. That for most ordinary
people they will be essentially unbreakable. The saps are supposed to go
down to some special Biometrics Temple, get suitably verified as to their
good standing with the Beast Who Is For Ever, and come back with their
very own "smart card" (keyed to their own iris print, eventually). This
will absolutely, positively, GUARANTEE that every packet they send is
encrypted to a secret key that they don't even KNOW because it's locked
inside a card and tamper-proof electronics. This code will guarantee to
the government, which holds an "escrowed" copy, that they can decipher
every byte that they send AND instantly identify precisely WHO sent it.
It will guarantee to the businessman that he has a transaction that
stands up in court. And it will guarantee to the voting board that the
vote is legitimate.
Of course, anyone with the secret escrowed key could sign up the sap for
a $50,000 bet on the Cubs to win the world series, or even a vote for
Gore or Bush. They already have the wires tapped, and it is a simple
substitution in transit. The reverse communication, also "unbreakably"
encrypted, is likewise subject to substitution, confirming that they
(didn't) vote for the person they (didn't) vote for.
One almost wonders why they'd bother to rig a U.S. election when both
candidates are so abjectly under their control, but the point is, these
people live by contingencies. When you already know you have everything
calculated out to the third decimal place you go for the fourth! And so
the Naders of the world need to be taken into their plans, even if their
own supporters don't have that much hope in them.
Even now, you can hear how they're playing with the "close" election.
Punched cards are so unreliable and questionable after all... and then
there's the issue of those obnoxious third party candidates who make it
difficult for "real" candidates who might have a hole next to them. And
oh, how that Nader with his couple of percent 'took' the race from the
one who really 'deserved' it. You don't exactly have to listen hard.
--
"Williams said the officer went to the car and found a mouse, which had
been injured and was bleeding.
The officer took the mouse to an animal hospital for treatment."
"6 Arrested in Rodent-Tossing Case", _The San Diego Union-Tribune_,
October 5, 2000
"Animal-rights groups have been watching the case and have told police
they want stiff punishment meted out, police said."
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Tue, 14 Nov 2000 12:12:39 GMT
In article <[EMAIL PROTECTED]>,
Darren New <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > Mixing up ciphers is a terribly bad idea. Now taking parts from
> > ciphers to build a new one can be done (I mixed IDEA+Twofish before)
> > but you have to be carefull of how you mix up the primitives. Just
> > mixing rounds is not a good idea.
>
> What would be the benefit to interleaving the rounds, versus just
running
> the two encryptions in sequence?
Hmm there is no benefit to EITHER mode. You have to actually stop and
say "this new combo is not either cipher" and analyze it all over again.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: XORred zipfile chunks = random?
Date: Tue, 14 Nov 2000 12:15:05 GMT
In article <8ur3se$lj0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> (sorry to post this again, but deja doesn't seem to carry
> sci.crypt.random-numbers)
>
> This easy to implement, quick and dirty method may be naive,
> simplistic, trivial etc. but it seems to work...
>
> Take a 3 minute audio cd .wav file (or record your own), zip it to
> improve uniformity of bits, giving around 30MB. Compile and run
program
> below (or use my one time pad program at
<http://www.vidwest.com/otp/>,
> creating an 11MB file and test with DIEHARD. If it doesn't pass,
repeat
> above using a longer .wav - it will eventually.
The problem is that wav files are not particularly random and if you
took something off a CD there is a chance that I own it too.
Sound cards were not meant to be RNG's so you have to be very carefull
if you're trying to justexpos it's job.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: I would like your opinion on this
Date: Tue, 14 Nov 2000 12:17:43 GMT
In article <qW1Q5.195565$[EMAIL PROTECTED]>,
Mike Vaughn <"vaughnmt"@@@home.com> wrote:
> Hi, and thank you for taking the time to share your opinion with me. I
> attend the University of Colorado, Colorado Springs, and this is an
> assignment for extra credits.
>
> I had a bitch of a time trying to come up with a PRNG so I ditched the
> idea completely and elected instead to take a different approach.
>
> What you see below is exactly what you would see if I emailed this to
> you. It is self decoding at the other end without the use of a public
> key exchange. The key is contained within the letter itself.
"The key is contained within the letter itself" this means that I could
steal your email had I reverse engineered the message format. Not
particularly an inteligent move my friend.
Perhaps if you really want that extra credit you should go read some
books on cryptography. Such as the hand book of applied crypto or
Bruce Schneier's book...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: PGP still the no1?
Date: Tue, 14 Nov 2000 12:20:22 GMT
In article <8uq596$lo9$03$[EMAIL PROTECTED]>,
"Sascha Klein" <[EMAIL PROTECTED]> wrote:
> im afraid about the new versions of PGP. someone told me, the crypted
data
> could be decrypted by police and so on. which is the best encryption
method?
> still pgp? or does any other program exist?
>
> and no :) im not on the run, i dont write any mean mails, iam just
> interested about beeing controled.
PGP is not an encryption "method". It's a cryptography toolkit. Big
difference. And for the most part PGP is still considered a secure
tool. The problem with ADK keys (that affected virtually no one) has
been fixed as well as the PRNG in the commandline versions (i.e doesn't
just return 0xFF anymore... :))
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: d <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Tue, 14 Nov 2000 12:29:00 GMT
In article <[EMAIL PROTECTED]>,
> It won't work for graphics,
> but there are some stories better told in words.
>
But it works with any binary data as well, including graphics, or you
could encrypt ~2GB of (zipped) text with a CDROM sized OTP.
--
Thanks for giving this your attention,
David West. <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: d <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Tue, 14 Nov 2000 12:42:05 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> d <[EMAIL PROTECTED]> wrote:
>
> : Command line One Time Pad utility. Options: pad generation,
randomness
> : testing, en/decryption, base64 en/decoding and disk wiping. ANSI-C
> : source and DOS executable included.
>
> : Free download at <http://www.vidwest.com/otp/>
>
> : Your bug reports/other feedback will be gratefully received.
>
> If you want a feature suggestion, add a (possibly OTP-based?)
signature
> routine. Without authenticity, OTPs are vulnerable to active
attackers.
>
Nice Idea. PGP does seem to have a few built-in advantages...
> Also, I'm not sure about the market for: "For a reliable and timely
> source of randomness, /unique/ CDROMs containing over 5 billion
> statistically random bits, delivered in tamper-proof seals."
>
> You may have to present yourself as a trusted agency to sell very
many of
> these. You will know where you shipped each CD to.
And I could never provably not keep a copy for myself. Hmmm...
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Florist:
Petal pusher.
>
--
Thanks for giving this your attention,
David West. <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
