Cryptography-Digest Digest #763, Volume #10 Sat, 18 Dec 99 19:13:01 EST
Contents:
Re: Keystrokes monitored/encryption useless (Steve K)
Re: question (David A Molnar)
Re: How do you get past the password screen to the crypto? ("Chuck")
compression & encryption (Raddatz Peter)
Re: Analogue encryption (Paul Johnstone)
Re: First Bijective Arithmetic Compression ("Gary")
'Simple' password storage (Paul Johnstone)
Re: 'Simple' password storage ("Robert C. Paulsen, Jr.")
Re: More idiot "security problems" (Jerry Coffin)
Re: compression & encryption (Jerry Coffin)
Re: 'Simple' password storage (John Bailey)
Re: 'Simple' password storage (Jerry Coffin)
Re: US Patent Office: How Stupid? Look Here... (Anthony Stephen Szopa)
Sorry, I was unclear... (Paul Johnstone)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Keystrokes monitored/encryption useless
Date: Sat, 18 Dec 1999 21:22:12 GMT
On Fri, 17 Dec 1999 19:06:47 GMT, [EMAIL PROTECTED] (Stefek Zaba)
wrote:
>In sci.crypt, Bauerda ([EMAIL PROTECTED]) wrote:
>
>> Before I upgraded to Windows, I had my startup files set so that they traced a
>> few interrupts (DOS, disk access, and keyboard) and checked most of the
>> interrupt table against stored results. While this is harder under Windows, it
>> is still relatively easy to get a program which looks at the devices and
>> threads running (hidden or not).
>
>Sussing which threads are running can help, but will only detect whole new
>threads, not modifications to the code being executed by the "standard"
>Windows handlers. Similarly, knowing that some piece of malware has not
>hooked a particular low-level interrupt is nice, but doesn't tell you that
>the "normal" interrupt routine, or any of the "standard" DLLs/VXDs, is
>unmodified. For that you need hashes of the trusted versions (and why do
>you trust the shipped versions anyway?), a non-modifiable store of the
>hashes and the hash-computation code, and non-bypassable alerting when
>the hash check fails.
>
>Stefek
Ah-yup. Once in a while I run down a line of shortcuts to PGP
detached signatures, just makin' sure, for the heck of it.
According to a rather hostile NAI software review, BO2K manages to
hide itself inside an existing thread when it starts. Pretty slick
trick, actually. I am sure that by now lots of "official" folks have
taken BO2K source in directions that suit their purposes...
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: question
Date: 18 Dec 1999 21:11:46 GMT
Atcherem <[EMAIL PROTECTED]> wrote:
> I'd like to know whether there exist ciphers where the length of the ciphertext
> is LARGER then the length of plaintext (with factor 2 or 3, for instance)?
Many. Consider a padding scheme for RSA - for instance OAEP. The
ciphertext is the length of the modulus, but only some fraction of
that is meaningful message. Thus you have message expansion.
Elgamal encryption -- you compute a g^k and send this along with your
g^xk * m value. This effectively doubles the size of the ciphertext.
If you read through the Handbook of Applied Cryptography (available
online), you can probably find more schemes like this. I think that
one of David Pointcheval's recent papers on the "Dependent RSA Problem"
also included the amount of ciphertext expansion in a table comparing
the efficiency of several signature schemes.
-David
------------------------------
From: "Chuck" <[EMAIL PROTECTED]>
Subject: Re: How do you get past the password screen to the crypto?
Date: Sat, 18 Dec 1999 14:02:59 -0800
Joseph Durusau <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> <[EMAIL PROTECTED]> writes:
>
> >My PC harddrive is encrypted, so when I start it up, it asks for a
> >password to decrypt. If the wrong password is entered 3 times then the
> >computer jams up.
> >
> >The question is how does an attacker get past the password bit to the
>
> Assuming that it is really 'your' computer, and that you
> have a lot of time on your hands, go into the bios setup and make it
> boot from floppy first. Put a DOS floppy into the A drive ( you might
> have to install one if it has been removed). Then turn the machine off
> and back on. Once DOS boots, you can either use debug or one of the
> disk utility progs to probe the disk till your heart is content.
>
> If someone who uses the machine regularly knows how to use
> it, a better solution is to install a bus monitor card with lots
> on memory inside the thing. Set the monitor up to record the first
> bus cycles, then read it out later. You will probably have to try
> several times until you find out what you need to look at, but
> finding the password stuff should not be all that hard.
>
> Speaking only for myself,
>
> Joe Durusau
------------------------------
From: Raddatz Peter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: compression & encryption
Date: Sat, 18 Dec 1999 14:05:16 -0800
Forgive me for being stupid about this...
I keep on reading about weak compression for encryption etc.
Here is what baffles me. Let's say I use Zlib for compression and then
encrypt the result with RC4 - why is that weak? If Zlib leaves a header,
which I have not seen, that header gets encrypted through RC4.
Trying to crack the cypherfile you must first reverse the RC4 code and
then unzip. So WHY is the use of Zlib weak????
Peter Rabbit
------------------------------
From: Paul Johnstone <[EMAIL PROTECTED]>
Subject: Re: Analogue encryption
Date: Sat, 18 Dec 1999 22:28:43 +0000
Fishfone, I like that :)
Were you aware that pressing Ctrl+Alt+F in Netscape takes you to Fishcam?
-Amos :)
Jim wrote:
> On Sat, 18 Dec 1999 12:34:52 -0000, "Gary" <[EMAIL PROTECTED]> wrote:
>
> >In old B&W films telephone conversations were scrambled.
> >Since digital modems weren't around then what did they do?
> >Did they overlay waveforms over the voice?
>
> In some system they did superimpose waveforms at the sending end
> and subtract them out at the receiver. I.e. the ciphony system
> Turing was working on at the end of the war.
>
> The more usual analogue type is a band-splitter with shuffling
> or a splitter with shuffle and time transposition.
>
> Basically the telephone bandwidth (300-3300 Hz approx) can be
> split into discrete bands, which can then be put back into the
> system in jumbled order, making the speech unintelligible.
> A very simple system just inverts the 'phone bandwidth so that
> the high frequencies transposed to the low end and the low end to
> the high.
>
> >How did they synchronise? Did they have a tracking control on the phone?
>
> Modern systems, such as those used by the Spanish fishermen (analogue
> enciphered fishfone!) uses a digital key transmitted within the
> telephone bandwidth using frequency-shift (or tone) keying; a new
> transposition key is sent with each 'over'.
>
> >If a pseudo one time pad is used to generate a wave form that overlays a
> >voice could this ever be as percievably secure as digital encryption?
>
> No. Which is why all serious ciphony systems are digital or at worst
> digitally-coded and encrypted vocoders. (And if you've ever used a
> secure 'phone incorporating a vocoder, you'll know why I said 'at
> worst' !!!)
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sat, 18 Dec 1999 22:28:54 -0000
You introduce rules,
>You wrote in your rejected ACM paper:
>What follows is a set of rules that guarantee ''one to one'' compression in
a Huffman file >where one uses a table of all 256 leaves:
why are these rules here?
There here to make your decompression work!
I'm babbling about the fact that you should trip these rules randomly in a
legit compression that doesn't require them. Otherwise their non-tripping
would tip off an analyst to a legit decompression.
Anyway it's academic as your compression is little more than a two way
process an analyst has to go thru before getting to the actual information.
People are better off adding more rounds to their cipher or doing loads of
time consuming all or nothing transforms, key strenghening etc.
I've taken the time to read and think about your proposal, the least you can
do is....
...the same!
------------------------------
From: Paul Johnstone <[EMAIL PROTECTED]>
Subject: 'Simple' password storage
Date: Sat, 18 Dec 1999 22:34:53 +0000
Hi folks,
I have thoroughly enjoyed reading this newsgroup. Learnt some new
things (which I suppose is one of the reasons it exists) and had a laugh
or three.
I have good programming abilities, but have no concept to program on for
a relatively simple task. A way to store a password (simple and short
text) on to a hard disk, with the same algorithm using the same key.
But not so easily that it can be attacked in 5 minutes. The amount of
storage space the ciphertext takes up isn't really a problem, just the
strength.
I have never thought about applying my programming to cryptography or
steganography and have become quite interested in it. Searching the web
for cryptographic concepts does not really return enough technical
information about how to go about it, just a description designed for
the layman on how it works.
If anyone would be kind enough to point me in the direction of a useful
resource or post a reply containing a pseudo code example, I would be
extremely grateful.
Thanks for your time.
Live long and prosper :)
-Amos
------------------------------
From: "Robert C. Paulsen, Jr." <[EMAIL PROTECTED]>
Subject: Re: 'Simple' password storage
Date: Sat, 18 Dec 1999 16:49:26 -0600
Paul Johnstone wrote:
>
> Hi folks,
>
> I have thoroughly enjoyed reading this newsgroup. Learnt some new
> things (which I suppose is one of the reasons it exists) and had a laugh
> or three.
>
> I have good programming abilities, but have no concept to program on for
> a relatively simple task. A way to store a password (simple and short
> text) on to a hard disk, with the same algorithm using the same key.
> But not so easily that it can be attacked in 5 minutes. The amount of
> storage space the ciphertext takes up isn't really a problem, just the
> strength.
>
> I have never thought about applying my programming to cryptography or
> steganography and have become quite interested in it. Searching the web
> for cryptographic concepts does not really return enough technical
> information about how to go about it, just a description designed for
> the layman on how it works.
>
> If anyone would be kind enough to point me in the direction of a useful
> resource or post a reply containing a pseudo code example, I would be
> extremely grateful.
>
Why not simply keep your passwords in a text file and encrypt that
file? There are plenty of programs available to do the encryption (PGP
will do the job).
If you prefer to try your hand at writing your own encryption program
see:
http://ciphersaber.gurus.com/
which will get you started on writing an RC4 implementation. Once
you've got that working you can use it as a basis for writing a
program more focused on the task of managing a list of passwords.
--
____________________________________________________________________
Robert Paulsen http://paulsen.home.texas.net
If my return address contains "ZAP." please remove it. Sorry for the
inconvenience but the unsolicited email is getting out of control.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: More idiot "security problems"
Date: Sat, 18 Dec 1999 15:57:55 -0700
In article <83e2lv$fc0$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ terse, since it's off-topic ]
> There's got to
> be a million sitcoms where someone gets instant-expert syndrome
> about something he doesn't understand and accidentally creates
> a plotline. Who does that a lot?
Don't watch sitcoms for people like this. Watch the news, politicians
in particular...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: compression & encryption
Date: Sat, 18 Dec 1999 16:10:47 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Forgive me for being stupid about this...
> I keep on reading about weak compression for encryption etc.
> Here is what baffles me. Let's say I use Zlib for compression and then
> encrypt the result with RC4 - why is that weak? If Zlib leaves a header,
> which I have not seen, that header gets encrypted through RC4.
> Trying to crack the cypherfile you must first reverse the RC4 code and
> then unzip. So WHY is the use of Zlib weak????
The general idea is that if the compression includes a predictable
content, you give the attacker some known-plaintext to work with.
Quite a few ciphers are easier to attack with known plaintext than
without.
The alternative view is that the amount of known plaintext revealed by
this is typically so small that it makes no real difference -- the
attacker has to have broken the encryption quite thoroughly before a
tiny amount of known plaintext is even marginally useful. A known-
plaintext attack against a block cipher normally has to have ALL the
plaintext for a complete block (e.g. 256 bits) known before it's of
any use at all.
Just for example, many compressors leave a signature at the beginning
of their output. This is typically around 3 bytes or so,
substantially smaller than a single block with nearly any reasonably
recent block cipher of which I'm aware.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: 'Simple' password storage
Date: Sat, 18 Dec 1999 23:19:58 GMT
On Sat, 18 Dec 1999 22:34:53 +0000, Paul Johnstone
<[EMAIL PROTECTED]> wrote:
>I have good programming abilities, but have no concept to program on for
>a relatively simple task. A way to store a password (simple and short
>text) on to a hard disk, with the same algorithm using the same key.
>But not so easily that it can be attacked in 5 minutes. The amount of
>storage space the ciphertext takes up isn't really a problem, just the
>strength.
Your specifications are somewhat subject to interpretation. I think
you want a way to use an easily remembered string to produce a hard to
infer password. It is not clear whether you want to generate an
already selected password or whether you will use whatever the
encrypted storage procedure generates as a password. If you want to
regenerate a determine password, it is not clear whether or how you
want to store the passcode which might regenerate the recovered
password.
With all these caveats, how can I loose? Here is what you can do.
On your herald line of your web browser (into which you would normally
enter directly a URL you want to jump to) enter the word javascript:
(note the following colon)
In Netscape, this brings up a dialog box into which you can enter
data. I have no idea what it does with the other primary brand
browser. Nor do I care.
enter: number1^number2 and hit return
The result is displayed at the top of the page.
The operand ^ for integers in javascript is an exclusive or.
Used in the way described it results in an essentially OTP conversion
of number 2 to the encrypted value.
If you remember the two numbers you entered, you can always recreate
the resulting number. Alternately, enter one number which you must
remember and one that you want to generate. Then you must store the
resulting number to recover the one you want to regenerate.
I hope this helps.
John
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: 'Simple' password storage
Date: Sat, 18 Dec 1999 16:19:59 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> I have never thought about applying my programming to cryptography or
> steganography and have become quite interested in it. Searching the web
> for cryptographic concepts does not really return enough technical
> information about how to go about it, just a description designed for
> the layman on how it works.
If you want real security, it makes no sense to encrypt the storage of
a single password -- you need a password to decrypt the password, so
you might about as well memorize the original password.
If you have a number of passwords, it's convenient to be able to store
all of them securely, using a single password. Counterpane systems
(for one example) has a utility to do this, though they don't publish
source code for it.
You mention simply being unable to break the program in "5 minutes."
In a case like that, you can pretty easily place the password in a
file, and encrypt the file using a password embedded into a program.
This will usually take more than 5 minutes to break, though it's never
going to be particularly secure -- it can often be managed in a few
hours.
Even if you're not interested in extremely high security, you might as
well use a strong algorithm though -- for example, source code for all
the AES finalists are easily available, so for many purposes it's
simply a question of picking one and writing a small program to use
it. I doubt that any of these is going to be broken to the degree
that the algorithm wouldn't be substantially more secure than the way
you're apparently planning to use it...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: US Patent Office: How Stupid? Look Here...
Date: Sat, 18 Dec 1999 15:21:58 -0800
Reply-To: [EMAIL PROTECTED]
+-Anthony Stephen Szopa wrote:
> US Patent Office: How Stupid? Look Here...
>
> Here is a patent that has already been issued:
>
> Use a random noise generator and connect it to an analog to digital
> converter. Run it through a bias monitor to eliminate bias. Record
> the random noise bits on a CD-ROM disk. Create about 1000 such
> disks.
>
> <snip>
>
> For all you random noise generator buffs, he suggests using one or
> more analog noise generators such as an NC manufactured by NOISE/COM
> of Paramus, N.J.
Here is an email reply post I got:
"In order to discuss your question it would be necessary to
have the exact wording of the already issued patent.
It might well be that your short description holds only one
specific embodiment of the invention.
Regards
x. x."
Well, of course the invention claims that any hardware and any
software can be used to merge these random bit sequences in any
way known, imaginable, or heretofore yet to be conceived.
In other words, the invention claims any and all and everything
under the sun. And it is this interpretation that the patent
office is using to give me a hard time.
The fact still remains that the invention must still be specific
and this is not the interpretation the patent office is giving in
its objection to my filing.
In EVERY embodiment CLAIMED, Fawcett, Jr. uses one or more analog
random noise generators (with perhaps one or more digital random
noise generators where the random bits are merged) to produce his
initial random bit sequences. These random bit sequences are then
monitored and corrected for any bias according to a mathematical
formula he uses. Then these random bit sequences are written to
storage media such as CD-ROM.
Then at least two or more of these CD-ROMs is read and the bits
merged using modulo 2 addition to generate random bits / digits /
numbers. The only variables being which CD-ROM sequences are used
and where each CD-ROM sequence the read operation begins. The read
operations then SEQUENTIALLY reads each random bit and these bits
are merged, etc.
The fact still remains that the use of any random noise generator
will not produce the randomly ordered sequences of the possible
permutations of the digits 0 - 9 with no digit repeated in each
sequence that must be used in my method. The laws of probability
make this impossible to be done using the method of Fawcett, Jr.
Therefore, Fawcett, Jr. clearly did not contemplate nor intend to
include my method in his filing.
To conclude otherwise is to assume that it is obvious that he did
so, or at least, even reasonable that he did so. And it is not
possible to do so since there is no way his random noise generators
can create such a file as I describe in my invention. To attempt to
justify the patent office's contention is to accept that any software
that Fawcett, Jr. wants us to assume with his hand waving over broad
claims is reasonable: he actually claims in his specification that he
does assume any and all hardware and software to merge his random
sequences of which his specific use of modulo 2 addition is but only
one possible way.
It is like saying that just because I wrote a novel that through
hardware and software I contemplate and therefore claim all
exclusive rights to all novels past, present, in the works, and to
be written in the future.
Then having government authority say: "Yep. Yesseree Bob. You
have cornered the market on novels and we agree that no one
will until about 2010 be able to write another because you have
contemplated them all with your novel and your claim to any
and all novel writing through hardware and software past, present,
and future! Yesseree Bob.
This is ridiculous on its face, at least to honest people with
integrity.
This never even occurred to me before:
Is it possible that the US patent office has been politicized and
therefore corrupted by the interests the rich and powerful?
I never thought about it but I realize that this is quite possible
and I might assume that it has. When it comes to money and power
what has NOT been corrupted?
Over broad claims are specifically not allowed in patents. This is
why there must be specificity in all filings. The fact that Fawcett,
Jr. claims use of random noise generator(s) in all of his embodiments
clearly limits his patent which is the intent of the patent
regulations.
And it is this limitation or required narrowness in scope that
clearly shows that Fawcett, Jr. did not contemplate nor intend to
cover my method / invention.
Fawcett, Jr.'s method is clearly intended to limit his scope and it
is obvious that his invention was not intended or contemplated to
cover my invention thus my invention cannot possibly be interpreted
as suffering the same limitations as Fawcett, Jr. nor can it be
interpreted as being specifically analogous as it must be to be
rejected on the above basis.
So, again, why has the patent office given such an over broad
interpretation to this particular patent?
Thank you.
------------------------------
From: Paul Johnstone <[EMAIL PROTECTED]>
Subject: Sorry, I was unclear...
Date: Sat, 18 Dec 1999 23:38:07 +0000
Hi again,
Thanks for your quick feedback. I was, however, a little unclear as to
exacly what I wanted to use it for.
Think of programs like WS_Ftp that store the passwords in its .INI file in
ciphertext. Only WS_Ftp can decode the files (theoretically - although I
know that this is not the case).
I want to write a program that stores several passwords as ciphertext in a
file that can be attacked and distributed until the cows come home, but
theoretically only the program can decode it, unlike WS_Ftp.
It is unsuitable to have the user remember passphrases or store keys on a
floppy etc. It it assumed that only the intended user can run the program,
or enter a single program "startup" password - before it will decipher
entries in the .INI file and display the plaintext password.
I hope that I am explaining this on the sort of high wavelength you are used
ot thinking in :)
Again, thanks for your feedback.
-Paul 'Amos' Johnstone
------------------------------
** 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
******************************
