Cryptography-Digest Digest #991, Volume #13 Sat, 24 Mar 01 21:13:01 EST
Contents:
Re: Keyloging (nemo outis)
Re: A future supercomputer (Benjamin Goldberg)
Re: Idea - (LONG) ("Douglas A. Gwyn")
Re: RC4 test vectors after gigabyte output?. (Benjamin Goldberg)
Re: Fill-in-the-blank codes (similar to Error-correcting codes) (Ron Hardin)
Re: your computer is spying on you 1833 (Frank Gerlach)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be (Frank Gerlach)
Re: Idea - (LONG) (amateur)
Re: Crack it! (Mok-Kong Shen)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be (Bart Bailey)
Re: Crack it! (amateur)
Is this a solution to the PGP flaw (Nicholas)
Compression-encryption with a key (amateur)
Uniform random integer (Benjamin Goldberg)
64 versus 128 (or bigger) bits cipher data block (Peter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: Keyloging
Date: Sat, 24 Mar 2001 22:26:10 GMT
What you suspect re HD writes is generally true. However a program could
accumulate data in memory and do infrequent writes.
The usual ways of detecting ordinary keyloggers (i.e., most of them) is:
1. looking for places they start up (assuming, as is usually the case,
that they aren't patches to legitimate programs)
2. examining running processes (quite a few can deceive ctrl-alt-del, far
fewer msconfig or the special programs (e.g., filemon, regmon
fromwww.sysinternals.com, or ATM from http://atm.idic.caos.it). You can also
use, for instance, "anti-sniffer" against network-based spying. There are
also anti-trojans such as The Cleaner, etc.
3. looking for who has "hooked" the keyboard handler.
One good anti-keylogger program is PC Investigator (aka hookprotect) from
http://www.geocities.com/SiliconValley/Hills/8839/utils.html Cracks are
available on altavista/.box.sk Also check out http://www.spychecker.com/
For info on keyloggers and other snoopware wander over to:
http://www.trapware.com
There are also hardware keyloggers - for one example go to:
http://www.keyghost.com/
Incidentally, the most powerful spyware on the market seems to be the
little-publicized and less-documented SilentRunner. Some limited info is
available at the eponymous site:
http://www.silentrunner.com/
Most of this stuff is better discussed on the alt.privacy forum.
Regards,
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>Hi!
>
>1) I'm a newbie so don't get upset if I write nonsense, okay?
>
>2) I was think about the following situation: Someone installed secretly
>a keyloging program (k-p) to get my passwords. I really have no idea how
>a typical k-p works, but it must save all tracked pressed key somewhere
>(memory or harddisk), mustn't it?
>I'm not a programmer, but if a k-p scans my keyboard, it should be
>possible to write a program which emulates key pressing. After
>activating this my harddisk should start to "cook" and go silent again
>when the program is stoped, shouldn't it? This would give a clue if a
>k-p scans my keyboard.
>
>What do you think?
>
>cu
>Peter
>
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: A future supercomputer
Date: Sat, 24 Mar 2001 22:49:04 GMT
Bart Bailey wrote:
>
> Darren New wrote:
>
> > JCA wrote:
> > > There is probably so much we ignore on the human brain's
> > > internal working that the computing power afforded by Blue Gene is
> > > likely to make no substantial difference in the effort to attain
> > > the goal you mention. Hence my skepticism about Blue Gene being a
> > > solid foundation, etc.
> >
> > Most times I've seen computing power compared with a brain, it's
> > something along the lines of "each synapse is worth N bits" and then
> > you count the synapses and the number of bits in the omputer. Or say
> > "each nerve can fire Q times per second, and there are W nerves, so
> > the brain does Q*W MIPS" or something. In other words, I've never
> > seen a comparison where the actual structure of the brain is taken
> > into acount.
>
> I believe it's a 3 dimensional analog matrix, with a variable clock
> rate, all mediated by the results of the incessant struggle between
> serotonin and acetylcholine.
According to what I've read, some parts of the mind work an analog
manner, some work in a digital manner. Also, simply saying "variable
clock rate," is a vast understatement -- there isn't any central clock,
so each neuron has it's own internal clock -- and and each of these
clocks can go at a different speed in different situations, and they
often operate asynchronously.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Sat, 24 Mar 2001 22:50:21 GMT
amateur wrote:
> Even if I used a short key of 12 digits, it's hard to solve.
> With a key of 100 hundreds digits it's unbreakable.
Nonsense. You mean that *you* don't know how to break it.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: RC4 test vectors after gigabyte output?.
Date: Sat, 24 Mar 2001 22:57:15 GMT
ajd wrote:
>
> "Gregory G Rose" <[EMAIL PROTECTED]> wrote in message
> news:99c2pg$[EMAIL PROTECTED]...
> > In article <u5C3OpCcF7b2VNiAEyPmh3csFGJy@wingate>,
> > Luis Yanes <[EMAIL PROTECTED]> wrote:
> > >There is any RC4 test vectors after gigabyte output?.
> >
> > Well, not a gigabyte.
> >
> > Initialise RC4 (or equivalent) with the 8 byte key
> > "test key". Then the first 44 output bytes are:
[snip]
>
> What are the input bytes that go with this? All zeroes?
> ajd
The key which produces that output is: {'t', 'e', 's', 't', ' ', 'k',
'e', 'y' };
I can see how you missed it... it's a bit like the line "Speak, friend,
and enter" from Tolkien.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Ron Hardin <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.dsp
Subject: Re: Fill-in-the-blank codes (similar to Error-correcting codes)
Date: Sat, 24 Mar 2001 23:15:01 GMT
Ninety Nine Bottles of Beer Lyrics with Error Correction:
Ninety nine bottles of beer, three a's, three b's, one c, two d's, thirty
five e's, seven f's, four g's, eight h's, twelve i's, one j, one k, five
l's, one m, twenty one n's, seventeen o's, one p, one q, eight r's, twenty
six s's, twenty two t's, four u's, six v's, eight w's, four x's, six y's,
and one z on the wall,
Ninety nine bottles of beer,
If one of those bottles, four e's, one g, one i, one k, one m, six n's, seven
o's, one p, one q, one r, two t's, two u's, two w's, one y, and one z should
happen to fall,
Ninety eight bottles of beer, three a's, three b's, one c, two d's, thirty
one e's, seven f's, three g's, eight h's, eleven i's, one j, five l's, fifteen
n's, ten o's, seven r's, twenty six s's, twenty t's, two u's, six v's, six
w's, four x's, and five y's on the wall.
--
Ron Hardin
[EMAIL PROTECTED]
On the internet, nobody knows you're a jerk.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Crossposted-To: sci.cryonics
Subject: Re: your computer is spying on you 1833
Date: Sun, 25 Mar 2001 01:17:37 +0100
Stop that spamming
[EMAIL PROTECTED] wrote:
> http://www.evidence-eliminator.com/go.shtml?A654710
>
> You're in Serious Trouble - It's a Proven Fact!
>
> Deleting "Internet Cache and History" will NOT protect you because any of the Web
>Pages, Pictures, Movies, Videos, Sounds, E-mail, Chat Logs and Everything Else you
>see or do could easily be recovered to Haunt you forever! How would you feel if a
>snoop made this information public to your Spouse, Mother & Father, Neighbors,
>Children, Boss or the Media? It could easily Ruin Your Life! Solve all your problems
>and enjoy all the benefits of an "As New PC", Evidence Eliminator can Speed-Up your
>PC/Internet Browser, reclaim Hard Disk space and Professionally Clean your PC in one
>easy mouse click!
>
> Whatever reasons you have... for needing Evidence Eliminator, one thing is for sure
>- downloading Evidence Eliminator will be the most important thing you have ever
>done. Act now, try it risk free, and transform your computer into a safe, clean and
>faster machine!
>
> Download Evidence Eliminator right now - Click Here!
> http://www.evidence-eliminator.com/go.shtml?A654710
>
> -------------------------------------------------------------------
>
> tetzutzgmxjblwzxyizggvohfyhznevkohncgiszibxjollbbvgzhryehnghhwkhzwftduvwyyldmwmu
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy.anon-server,alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.resources,comp.security.pgp.tech
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be
Date: Sun, 25 Mar 2001 01:37:52 +0100
Bill Unruh wrote:
> In <[EMAIL PROTECTED]> Frank Gerlach <[EMAIL PROTECTED]> writes:
>
> ]Next time, please clearly state the THREAT MODEL. Telling people that write
> ]access to the secret key is necessary would have been easily possible. Also, if
> ]you call your self "cryptologist", be a little more scientific and less
> ]marketing-driven. Helps your reputation.
I was referring to their very first announcement, which sounded pretty dramatic. It
turns out that only people, who have their private key writable are affected. This is
qualifies for marketing-driven scaremongering in my opinion.
>
>
> ?? The secret key is encrypted precisely because the threat model that
> someone can read your secret key file is real potential threat. The possibility to
> write to the file is not far behind being able to read it.
> I have no idea if they released this for self aggrandizement, but that
> is also totally irrelevant. They have identified a weakhess in the
> OpenPGP specification. It is a real weakness of much greater threat that
> others that PGP already protects itself against. It needs to be fixed.
> It is not hard to fix which is good, but that does not mean it is
> inconsequential. It is definitely a breaking of the protocol.
> Remember, crypto is not the algorithm, it is the whole chain, which
> includes key protection. Would you have been as sanguine had they shown
> that the enryption of the secret key wa flawed and anyone could simply
> read it off from the secret key file.? After all that would require that
> someone else have read permission to the file, and anyone who was
> careful would never allow someone else to read their secret key file. I
> would sure call that a lousy--broken-- protocol.
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Sat, 24 Mar 2001 18:39:27 -0400
So do it! if it is easy to break.
I'm still waiting.
Send me your solution at [EMAIL PROTECTED]
If you find it I will never post anything to sci.crypt until I read the
50 best books in cryptography. It will take me more than a year.
"Douglas A. Gwyn" wrote:
>
> amateur wrote:
> > Even if I used a short key of 12 digits, it's hard to solve.
> > With a key of 100 hundreds digits it's unbreakable.
>
> Nonsense. You mean that *you* don't know how to break it.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Sun, 25 Mar 2001 00:50:41 +0100
amateur wrote:
>
> You wrote :
> "A substitution in modern crypto algorithms is commonly a
> mapping of n bit values to m bit values, with both n and
> m being constant. A typical example is the DES S-boxes
> with n=6 and m=4. That is, the input and output symbols are
> both from constant length codes (block codes). Evidently,
> however, there is no 'necessity' of using such constant
> length codes. Thus we describe in the present note a more
> general substitution from an input alphabet to an output
> alphabet, where the symbols of the alphabets have variable
> number of bits as code values."
What's wrong that I treated the general case (that takes
care of all special cases one ever needs) ?? It would
have been not so good, if I had instead treated only a
particular special case that could not be generalized to
apply to many practically interesting situations, isn't it?
The ASCII code is ONE special case of the (general)
variable length codes. If the frequency distribution of
the 256 symbols is uniform, then the Huffman code computed
will be such that all symbols are represented by 8 bits,
i.e. you have then in that special case constant number
of bits for each symbol. (In the general case, the Huffman
code will have symbols represented by differing number of
bits.) Is that clear to you?
Note that in a response sent earlier I have pointed out
that the exact representation of the symbols has NO
relevance to the argumentations we have been dealing
with up to the present time point. For we are discussing
whether using homophones for a two symbol alphabet (bit
is such a one, since it has two values 0 and 1) as such
(an issue that by itself is independent of the
representation of the homophones) is something
particular/ingeneous/novel or not. As I have repeatedly
shown, the answer is NO.
M. K. Shen
------------------------------
From: Bart Bailey <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be
Date: Sat, 24 Mar 2001 15:50:09 -0800
David Ross wrote:
> "Bob C." wrote [in part]:
> >
> > 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.
>
> So, if I rename my private key file and take the extra precaution
> of storing it in a folder other than where PGP and my public
> keyring are stored (possibly on another drive), I can then block
> the attack described by Klima and Rosa.
In win9x, go to [C:\windows\PGPsdk.dat]. open in a text reader and see how
secret your new name and location are.
~~Bart~~
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Sat, 24 Mar 2001 19:15:37 -0400
The core of your post is clear. Is about "Thus we describe in the
present note a more general substitution from an input alphabet to an
output alphabet, where the symbols of the alphabets have variable number
of bits as code values."
You are discussing the issue of length-block : variable or not. What
your are considering as new ( even if it is not new. I will send
references about variable block size) is the "variability " of
size-block.
You are talking about encrypting group of bits.
My idea is very simple : I encrypt every bit (stream cipher) by a value.
And not any value. This value has to be clearly belonging at one
category. I use two categories based on one property : (odd or even,
consonants or vowels etc...).
What I had hidden in my algo just to see how people react is more
complicated.
So before encrypting using the two categories, I use another algo which
allow me to assign to every character a single and specific symbol or
value. Without using any dictionnary. The recipent will retrieve all the
symbols using a long algo that I did not published yet.
In my idea the step cesar is useless. I knew it before.
I use another algo instead of cesar.
But it is very long to expose even if it is easy to compute.
You have to talk about the idea of two categories which is new. Not
about enciphering bit. All stream ciphers encrypt one bit at once.
You are denying what is new : the idea of two categories.
I hope it was clear.
Mok-Kong Shen wrote:
>
> amateur wrote:
> >
> > You wrote :
> > "A substitution in modern crypto algorithms is commonly a
> > mapping of n bit values to m bit values, with both n and
> > m being constant. A typical example is the DES S-boxes
> > with n=6 and m=4. That is, the input and output symbols are
> > both from constant length codes (block codes). Evidently,
> > however, there is no 'necessity' of using such constant
> > length codes. Thus we describe in the present note a more
> > general substitution from an input alphabet to an output
> > alphabet, where the symbols of the alphabets have variable
> > number of bits as code values."
>
> What's wrong that I treated the general case (that takes
> care of all special cases one ever needs) ?? It would
> have been not so good, if I had instead treated only a
> particular special case that could not be generalized to
> apply to many practically interesting situations, isn't it?
> The ASCII code is ONE special case of the (general)
> variable length codes. If the frequency distribution of
> the 256 symbols is uniform, then the Huffman code computed
> will be such that all symbols are represented by 8 bits,
> i.e. you have then in that special case constant number
> of bits for each symbol. (In the general case, the Huffman
> code will have symbols represented by differing number of
> bits.) Is that clear to you?
>
> Note that in a response sent earlier I have pointed out
> that the exact representation of the symbols has NO
> relevance to the argumentations we have been dealing
> with up to the present time point. For we are discussing
> whether using homophones for a two symbol alphabet (bit
> is such a one, since it has two values 0 and 1) as such
> (an issue that by itself is independent of the
> representation of the homophones) is something
> particular/ingeneous/novel or not. As I have repeatedly
> shown, the answer is NO.
>
> M. K. Shen
------------------------------
From: Nicholas <[EMAIL PROTECTED]>
Subject: Is this a solution to the PGP flaw
Date: 25 Mar 2001 00:19:53 GMT
If my understanding is correct, signatures made with the modified key
will not be valid. Is not a solution to the crack, therefore, for
pgp/gpg to verify any newly created signature and warn if a signature
fails to verify?
Since the extra time used for this would be a waste in situations where
the security of the key is more certain, this should I assume be an
option which could be turned on/off.
Any comments? Is my understanding correct or incorrect?
N
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Compression-encryption with a key
Date: Sat, 24 Mar 2001 19:33:52 -0400
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.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Uniform random integer
Date: Sun, 25 Mar 2001 01:05:15 GMT
I'm trying to find the name of the following algorithms:
rrange : An upper bound on the pre-existing rng.
rand() : An rng which produces integers in the range 0..(rrange-1).
int ranmod_a(int mod) {
int val = 0, max = 1;
do {
while( max < mod ) {
max *= rrange;
val *= rrange;
val += rand();
}
if( val >= (max%mod) ) {
return val % mod;
}
max %= mod;
val %= mod;
} while(1);
}
int ranmod_b(int mod) {
int max = rrange % mod, val;
do {
val = rand();
} while( val < max );
return val % mod;
}
Also, assuming that rand() gives a good distribution, and integers don't
overflow, are there any situations where the above algorithms don't
work?
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: [EMAIL PROTECTED] (Peter)
Subject: 64 versus 128 (or bigger) bits cipher data block
Date: Sun, 25 Mar 2001 01:36:25 GMT
Reply-To: [EMAIL PROTECTED]
Someone can explain me main reasons (or all) for which 128 bits block
is better than 64 bits block?. I had made think on this and I found
some goals for use bigger block but I still dont know if they are
primary.
Best regards
Peter
------------------------------
** 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
******************************
