Cryptography-Digest Digest #994, Volume #13 Sun, 25 Mar 01 13:13:00 EST
Contents:
Newbie: Eight out of Eight ("Helge Haensel")
Re: Best encryption program for laptop? ("Thomas J. Boschloo")
Re: Attn: Chris Drake and Thomas Boschloo ("Thomas J. Boschloo")
Re: on-card key generation for smart card (Daniel James)
Re: Compression-encryption with a key (SCOTT19U.ZIP_GUY)
Re: Compression-encryption with a key ("Tom St Denis")
Re: I was so so right about PGP ... so right when I started writing (William
Hugh Murray)
Re: Operations for the DES (William Hugh Murray)
Re: Operations for the DES (William Hugh Murray)
Re: Verisign and Microsoft - oops (Anne & Lynn Wheeler)
Re: Compression-encryption with a key (Mok-Kong Shen)
Re: DES C Source Code (Graywane)
Perl public key encryption ("Chris Eason")
Re: Compression-encryption with a key (amateur)
Re: Best encryption program for laptop? ("Roman E. Serov")
----------------------------------------------------------------------------
From: "Helge Haensel" <[EMAIL PROTECTED]>
Subject: Newbie: Eight out of Eight
Date: Sun, 25 Mar 2001 15:20:36 +0200
Hi, anybody out there who knows how to code/decode a characterstream (0x00
... 0xFF) in 'eight out of eight'?
Thanks, H. H.
--
Dipl. Ing. Helge Haensel, DJ1WM
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Best encryption program for laptop?
Date: Sun, 25 Mar 2001 15:56:53 +0200
[EMAIL PROTECTED] wrote:
>
> My job is changing, and is going to require me to do some travelling.
> I would like to purchase a laptop, and continue to keep my home
> finances, and other private data, on it.
> what would be the best way to keep data safe, in case the laptop was
> stolen? Which encryption program? And, should it be encryption alone,
> or encryption coupled with a secure os like NT?
NT is a secure OS? ;-P How about FreeBSD?
But I would recommend a program like Scramdisk
<www.scramdisk.clara.net>. They have a paid version for NT and a free
version of W9x.
Regards,
Thomas
--
Kittenbirds - You, me and Jesus: "I love your hair it's just so long"
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.privacy.anon-server
Subject: Re: Attn: Chris Drake and Thomas Boschloo
Date: Sun, 25 Mar 2001 16:09:40 +0200
Chris wrote:
>
> So Thomas, you have written a program which records the current time.
> Well done. Now, all you've got to do is get some keystrokes in there,
> and you'll be on your way to showing that one of your SIX ridiculous
> claims has some weight.
>
> You've got 3 and a half days left - you'd better get busy!
>
> Required:-
>
>http://groups.google.com/groups?q=&hl=en&lr=&group=alt.security.pgp&safe=off&rnum=9&seld=914264994&ic=1&filter=0
Well, since I so far got one report that my keylogger, netsafer crack
works and verified it's working myself under Windows 95 ORS2 [nl]
Version 4.00.1111 on two different computers, I guess that is two votes
that my crack works against one of you that it does not.
This means I have made the deathline of tomorrow you set and I can go on
finishing Startrek Generations today instead of wasting more time on
your product, just to have you lie about it not working again (as you
have done before about the crack I did for Netsafe 4.2).
Have phun proclaiming yourself the winner tomorrow. You will be the only
one cellebrating in your little victory party as the rest can visit my
site and check the crack for themselves.
<http://home.soneraplaza.nl/mw/prive/boschloo>
Regards,
Thomas
--
Frieza to Goku: "It was fun while it lasted"
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: on-card key generation for smart card
Date: Sun, 25 Mar 2001 15:49:28 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Paul Rubin wrote:
> > ... generating the key in software and loading it into the
> > card was the best way to operate because one could then be
> > sure that sufficient care had been taken to generate a strong
> > key ...
>
> That's silly--the card firmware should do the same checking.
True, and the Cryptoflex card claims it does. I don't know whether the
PKCS#11 vendor, in the case that I related, had reason to believe that
the card did not perform the checking well or thoroughly enough...
Another reason given was that the on-card keygen process was too slow to
be acceptable to users, and that users were liekly to get impatioent and
remove the card part-way through the operation (leaving the card in an
unknown state).
> Faking should be easy to detect unless they went out of their way to
> conceal it. Just generate keys on the same card, using a slow
> workstation and then a fast one, and see if the speeds are different.
Good point. The results I've seen using various NT boxes between about
133MHz Pentium and 450MHz Pentium III give a fairly consistent keygen
time of about 7 seconds, give or take (keygen times vary anyway, of
course, depending on the number of non-prime 'primes' that are generated
and have to be rejected).
Cheers,
Daniel.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression-encryption with a key
Date: 25 Mar 2001 14:59:47 GMT
[EMAIL PROTECTED] (Ross Younger) wrote in
<Jab*[EMAIL PROTECTED]>:
>amateur <[EMAIL PROTECTED]> rearranged some electrons into article
><[EMAIL PROTECTED]> thus:
>>Compression-encryption with a key is exist or no?
>>The same algo compress and encrypt simultaneously the plain-text with a
>>secret key, that is what I mean.
>
>Simultaneously? Not that I'm aware of.
>
>It is generally a Good Idea to compress your plaintext before encrypting
>-- this normally reduces the amount of ciphertext for an attacker to play
>with and reduces redundancy within (one could call this obfuscating the
>plaintext, I suppose).
>
Yes in theory its a good idea to compress before one encrypts
unfortunately most don't use a compressor that is a good match
not only to the data but to the encryption engines that follows.
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: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Compression-encryption with a key
Date: Sun, 25 Mar 2001 15:30:16 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Ross Younger) wrote in
> <Jab*[EMAIL PROTECTED]>:
>
> >amateur <[EMAIL PROTECTED]> rearranged some electrons into article
> ><[EMAIL PROTECTED]> thus:
> >>Compression-encryption with a key is exist or no?
> >>The same algo compress and encrypt simultaneously the plain-text with a
> >>secret key, that is what I mean.
> >
> >Simultaneously? Not that I'm aware of.
> >
> >It is generally a Good Idea to compress your plaintext before encrypting
> >-- this normally reduces the amount of ciphertext for an attacker to play
> >with and reduces redundancy within (one could call this obfuscating the
> >plaintext, I suppose).
> >
>
> Yes in theory its a good idea to compress before one encrypts
> unfortunately most don't use a compressor that is a good match
> not only to the data but to the encryption engines that follows.
You have yet to prove 1-1 is any better then the higher ratio codecs that
you slander.
If your 1-1 algorithm works on a computer, I can write a program to brute
force it. Nuff said. It's not an argument it's a friggin fact.
Let me review your argument. You say that a 1-1 codec will decompress
anything into a valid output (which will compress back to itself). Neato
but not a criterion for security AFAIK. Reason: Not all of the
decompressed outputs will resemble what I want. Let's say I am trying to
find a key for a message starting with "DEAR ABBY: RE: MY EGO". Will all
inputs to the decompressor output that? I don't think so. Therefore I can
easily eliminate keys for which the decompression doesn't match.
Am I missing something here?
Tom
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: I was so so right about PGP ... so right when I started writing
Date: Sun, 25 Mar 2001 15:39:59 GMT
Mxsmanic wrote:
> "Frank Gerlach" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Cryptographic devices and critical infrastructures
> > (routers, name servers, telephone switches, emergency
> > communications systems) should *not* be implemented
> > in a language, which defies runtime bounds checking.
>
> The choice of programming language used to develop cryptographic systems
> is irrelevant from a security standpoint. All that really matters is
> the skill of the people designing and coding the system. Good engineers
> can code airtight systems in Word macros; bad engineers will make a
> Swiss cheese out of any cryptosystem written in any of your favorite
> languages.
>
> > And yes, using a good programming language is not
> > sufficient, but a NECESSARY PRECONDITION.
>
> You're half right: it's not sufficient. But it's hardly necessary,
> either.
Can we agree on useful?
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Operations for the DES
Date: Sun, 25 Mar 2001 15:46:29 GMT
Paul Rubin wrote:
> William Hugh Murray <[EMAIL PROTECTED]> writes:
>
> > How many computer operations does a DES operation require?
> >
> > The context of my question is a program on the History Channel about
> > NSA. At one point they assert that that they once had a machine that
> > could do 73 quadrillion computer operation in five seconds. I thought
> > that this was an interesting set of numbers in which to express the
> > speed of a computer.
>
> Heh, 73 quadrillion is very close to 2**56, if that's what you're thinking.
Yes, that is what I was thinking. It is a number that someone interested in
cryptography might identify but that would be gibberish to anyone else. That
raises the question of why it was in the script.
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Operations for the DES
Date: Sun, 25 Mar 2001 15:50:40 GMT
Merrick wrote:
> >I distinctly remember reading that the IBM says that Blue Gene will run
> >at 1 petaflops (1 quadrillion) per second.
> >Seems like the History Channel is referring to some machine beyond Blue
> >Gene :-)
>
> A while back the NSA was taken to court (!) by John St Clair Akwei
> (Civil Action 92-0449).
>
> During the course of the trial, the NSA was required to reveal certain
> technological information, which showed them to be about 8 years ahead
> of the current technology, and already using nanotechnology for
> computing purposes.
>
> Don't be too surprised if that quote from the history channel refers
> to one of their decommissioned "old" computers...
It is clear that the number referred to an "old" computer. Of course, the
number of operations per unit time is meaningful only if one knows the size
of the operation. I would expect that the word size here is at least 64
bits.
------------------------------
Subject: Re: Verisign and Microsoft - oops
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 25 Mar 2001 16:09:39 GMT
[EMAIL PROTECTED] (Vernon Schryver) writes:
> It takes more than $200 to ensure that I speak for rhyolite.com and that
> I am me. Consider the cases where someone would pay that cost plus the
> costs to operate the servers plus a profit to justify a $33/share price
> for a stock that lost $19/share and has a mysterious book value (at least
> to http://www.quicken.com/investments/stats/?symbol=VRSN ). Don't all of
> those cases have cheaper and more secure alternatives, such as exchanging
> keys in person?
one of the problems with TTP certificate manufactoring (term i coined
several years ago to highlight the fact that a lot of the references
to PKIs were really talking about just certificate manufactoring
... not about real infrastructure) is that the TTP has to cover the
costs of a independent, stand-alone, complex, robust data processing
complex and services purely out of fees charged for trust. Many
business operations dealing in trust do it in conjunction with other
types of operation (lot of cost-sharing across the infrastructure).
random refs:
http://www.garlic.com/~lynn/aepay2.htm#fed
http://www.garlic.com/~lynn/aadsm3.htm#kiss10
http://www.garlic.com/~lynn/aepay3.htm#openclose
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Compression-encryption with a key
Date: Sun, 25 Mar 2001 19:24:46 +0200
Tom St Denis wrote:
>
> "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Ross Younger) wrote:
> > >amateur <[EMAIL PROTECTED]> wrote:
> > >>Compression-encryption with a key is exist or no?
> > >>The same algo compress and encrypt simultaneously the plain-text with a
> > >>secret key, that is what I mean.
> > >
> > >Simultaneously? Not that I'm aware of.
> > >
> > >It is generally a Good Idea to compress your plaintext before encrypting
> > >-- this normally reduces the amount of ciphertext for an attacker to play
> > >with and reduces redundancy within (one could call this obfuscating the
> > >plaintext, I suppose).
> > >
> >
> > Yes in theory its a good idea to compress before one encrypts
> > unfortunately most don't use a compressor that is a good match
> > not only to the data but to the encryption engines that follows.
>
> You have yet to prove 1-1 is any better then the higher ratio codecs that
> you slander.
>
> If your 1-1 algorithm works on a computer, I can write a program to brute
> force it. Nuff said. It's not an argument it's a friggin fact.
>
> Let me review your argument. You say that a 1-1 codec will decompress
> anything into a valid output (which will compress back to itself). Neato
> but not a criterion for security AFAIK. Reason: Not all of the
> decompressed outputs will resemble what I want. Let's say I am trying to
> find a key for a message starting with "DEAR ABBY: RE: MY EGO". Will all
> inputs to the decompressor output that? I don't think so. Therefore I can
> easily eliminate keys for which the decompression doesn't match.
>
> Am I missing something here?
Scott's point, if I don't err, is that you can base on
the fact whether the decrypted stuff, on decompression
and further compression, remains the same, to automatically
(i.e. with a simple machine decision without further ado)
discard most (I suppose not all) tried decryption keys
that are incorrect. Someone has raised the question whether
this advantage is big enough for justification of its use
in view of the fact that one has thereby to process the
whole file and not only some blocks. I don't know the
answer. A point I mentioned earlier elsewhere is that,
if a compression scheme is not fixed but variable, i.e.
dependent on or parametrized by a 'key' (e.g. an adaptive
Huffman primed by some chosen sequence), then the opponent
will not be able to exploit the above said criterion
to discard wrong keys, since he doesn't know whether
his version of the compressor is identical to that of
the communication partners. This amounts, though,
effectively to an extension of the encryption key (due
to the 'key' of the compressor).
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Graywane)
Subject: Re: DES C Source Code
Date: Sun, 25 Mar 2001 17:32:24 GMT
In article <[EMAIL PROTECTED]>, Adrian Planinc wrote:
> I am looking for an implementation (source code) of DES in C/C++ that
> compiles on Linux and is as simple as possible - ie...closely follows
> the original standard.
DES is far from "simple".
> I have been assigned the task of analysing and modifying the code, and
> thus need the original DES, and not Triple DES or any sort of algorithm
> that's based on DES but is not proper DES. I've been told this is the
> best place to ask...:)
You are going to "analyze and modify" DES? Do you feel qualified to do so?
You can check out the following links (which you could have found as easily
as I by taking 2 seconds to use a search engine):
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
http://www.itl.nist.gov/fipspubs/fip81.htm
http://www.openssl.org/source/cvs/crypto/des/?hideattic=1&sortbydate=0
http://www.stillhq.com/gpg/source-1.0.3/cipher/des.html
http://www.austinlinks.com/Crypto/source-books.html
http://www.radiusnet.net/crypto/archive/source/des/
> Thanks in advance and please come back in email as I don't check these
> forums too often.....
If you can't even be bothered to read the group then you don't really
deserve an answer now do you?
--
Note: There is no example in my hostname.
------------------------------
From: "Chris Eason" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: Perl public key encryption
Date: Sun, 25 Mar 2001 18:40:31 +0100
Hello. I wonder if anybody could please help me with the following problem.
I am developing a website using the free 'PerlShop' program. The only flaw
is that it creates unencrypted files on the webserver which contain order
details, including name, address and credit card number. Clearly, this is
rather unsatisfactory because:
a) anybody with the root password at my ISP would be able to read the files
b) if somebody managed to crack my password they would be able to read the
files
I am therefore trying to find a way, in Perl, to encrypt this information
with a public key before it is written to disc. It has to be a public key
system since anybody who can read the order files would also be able to read
the Perl program and work out how they were encrypted. A symmetric cipher is
therefore inappropriate.
I have found the Crypt::RSA module on CPAN, which appears to be ideal.
However, I am developing the site on my Windows PC at home and it appears to
be impossible to get Crypt::RSA to work in this environment because of its
dependence on PARI. You might therefore ask why don't I just test it on my
ISP's webserver. The answer is that I have not yet forked out the cash for a
properly hosted web site with my ISP because I want to check it all works
first. So I'm in a bit of chicken and egg situation.
Does anybody out there know of a more simple way of performing public key
cryptography in Perl? (My ISP has already said that they do not provide PGP
because 'it would require root access'.) There are other pure Perl
encryption modules like Crypt::RC4 that work perfectly and which are simple
to install and to use... but which are symmetric ciphers. It seems quite
extraordinary that nobody has written a public key asymmetric cipher module.
Am I missing something really basic?
Help!
Thanks
Chris Eason
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Compression-encryption with a key
Date: Sun, 25 Mar 2001 12:42:52 -0400
What I said is "simultaneously".
That does not mean compression then encryption.
At the same time you compress, you encrypt.
In the process of compression, run the process of encryption.
Without dictionnary. I stress without dictionnary.
Does that system exist?
That is my question.
Mok-Kong Shen wrote:
>
> amateur wrote:
> >
> > Compression-encryption with a key is exist or no?
> > The same algo compress and encrypt simultaneously the plain-text with a
> > secret key, that is what I mean.
>
> You have the following possibilities (what you do is your
> own decision):
>
> (1) A fixed compression (without key) and then encrypt. This
> is common but is not what you are asking.
>
> (2) A variable compression dependent on a key, e.g.
> an adaptive Huffman compression, with an initial
> constellation (symbol frequencies) set so as to be
> dependent on a key value. One simple way of doing
> this is to use a PRNG with a key as seed to generate a
> sequence of a certain length and feed it into an
> adaptive Huffman and discard the output before feeding
> the proper sequence to be compressed. Without
> being followed by a normal encryption processing,
> this is considered insecure.
>
> (3) Do (2) and then encrypt.
>
> M. K. Shen
------------------------------
From: "Roman E. Serov" <[EMAIL PROTECTED]>
Subject: Re: Best encryption program for laptop?
Date: Sun, 25 Mar 2001 21:25:14 +0400
Well, Win2000 may be a solution. NTFS 5.0 provides for encryption of disk
files transparently for user.
------------------------------
** 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
******************************
