Cryptography-Digest Digest #860, Volume #13 Sun, 11 Mar 01 09:13:01 EST
Contents:
Re: OverWrite: best wipe software? (those who know me have no need of my name)
Re: Really simple stream cipher ("Henrick Hellström")
Re: PKI and Non-repudiation practicalities (those who know me have no need of my
name)
Re: The Foolish Dozen or so in This News Group (those who know me have no need of my
name)
Re: The Foolish Dozen or so in This News Group (those who know me have no need of my
name)
Re: Applications of crypto techniques to non-crypto uses (those who know me have no
need of my name)
Re: Encryption software (Bram Labarque)
FIPS 140-2 PRG ("Yoad Lustig")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: Applications of crypto techniques to non-crypto uses (Mok-Kong Shen)
Re: Super strong crypto (Mok-Kong Shen)
Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
Re: => FBI easily cracks encryption ...? ("Tom St Denis")
Re: OverWrite: best wipe software?
Re: Encryption software ("Henrick Hellström")
Dumb inquiry....
Re: Question ("Dragon")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Sun, 11 Mar 2001 09:54:24 -0000
<wtCq6.10367$[EMAIL PROTECTED]> divulged:
>"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> I think I have made Ciphile Software's OverWrite Security Utility
>> Version 1.2 perhaps the best wipe utility available for Windows.
>Why do you think that?
i suppose we shouldn't be too hard on anthony. he doesn't know better,
and at times he does appear to learn. the really annoying "wipe" program
is the one that comes with nai's pgp products -- they make the same
ludicrous claims, and likewise barely mention the constraints.
--
okay, have a sig then
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Sun, 11 Mar 2001 11:03:45 +0100
"Thomas Wu" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> But code in application layers is often written without the assumption
> that the format check has security implications. Imagine an FTP daemon
> that rejects an unknown command by including the offending command name
> in the response; "FOO" results in "FOO: unknown command". Under these
> circumstances, it seems possible that an attacker could exploit this
> behavior under your model to get chosen ciphertext pairs and use it
> to leverage attacks that would not be possible with explicit MACs.
> A user-friendly feature at the application level suddenly turns into
> a security weakness when these abstraction barriers aren't respected.
I came to think of some other things:
1. No matter how the encryption is arranged, the attacker will always have
partial knowledge of the plain text: All commands are four characters wide
and are separated from the parameter line by a space or tab character, all
replies begin with a three digit decimal number, etc. To prevent cipher text
only attacks or known plain text attacks, a new session key should always be
generated, ECB mode should not be used and the vector should not be reset to
the same value prior to each message within a session.
2. If e.g. a CBC mode cipher is used and the vector is either reset or
chosen by the sender prior to each command, an attacker could easily mount a
copy-and-paste chosen cipher text attack even if a MAC is used. If the
vector is not reset or if it is set in advance by the recipient, then a
denial-of-service attack is possible. In this respect, there is no
difference between e.g. CBC-MAC and an error propagating cipher.
Now, suppose that an error propagating cipher is used without padding the
messages and without vector resets. Then the following seems to be true:
(a) The probability will be higher that random chosen cipher text will
decrypt into intelligble plain text.
(b) The probability that a specific cipher text will decrypt into the same
plain text twice, is equal to the probability that any other random cipher
text will decrypt into that plain text once.
(c) Due to the abscence of padding, an eaves dropper will learn the length
of each message, but:
(d) Due to the abscence of padding and of a MAC, an eaves dropper will be
given less plain text and thereby less information about the key and the
vector.
(e) Due to the error propagation, a chosen cipher text attack might be
mounted at most once each session.
Considering (a)-(e), yes, it would be possible to mount attacks against an
error propagating cipher you could not mount against e.g. a CBC-MAC, but
since the converse is also true, does this really make the error propagating
cipher encryption setup weaker? Suppose you send a five character cipher
text to the server and by chance you did get a reply back indicating that
the server sent something like "500 xxxx: Command unknown", what information
would that give you that a cipher text only attack wouldn't give you?
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: PKI and Non-repudiation practicalities
Date: Sun, 11 Mar 2001 10:11:45 -0000
<xMiq6.686$[EMAIL PROTECTED]> divulged:
>Well, in somne cases, it makes for good customer retention.
they seem to like keeping you on a leash. i don't see how they'd like
you being in charge of your own secret. (to wit, most institutions
will not allow you to select an alternative to your ssn or mother's
maiden name as additional security verifiers.)
>What's the difference between the 2 environments we've been discussing?
scale.
>About the same as most shared secret models and all CRL based models
i'm not overly interested in the crl models.
i don't see the same effort as most shared secret models. i suspect
i'm missing something, so i need to think about it some more.
>That is always the revocation challenge, PKI, shared secret or whatever.
>Commercially, I (non-lawyer that I am) think most companies would revoke
>on the suspicion of compromise, to avoid their own negligence liability
>for insisting something is safe for a relying party to act upon, when it
>may not be.
and that shows the other half of the revocation challenge -- a denial of
service attack. and if there is but one secret that can be so revoked it
can be even more devastating (when even a mistake happens).
>Commercial implementation issues are outside the standard as with all
>well crafted standards.
i'm not sure i agree that what i described is an implementation issue, if
the standard makes no allowances.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 11 Mar 2001 10:20:47 -0000
<[EMAIL PROTECTED]> divulged:
>What I propose is that you give OverWrite the ability to do two things:
>
>1) Be able to find the actual physical blocks on disk that correspond to
> a file (i.e., make it able to understand the common Windows file
> systems),
>2) Make it read and write raw blocks directly to hard drives and
> disk controllers, totally bypassing the operating system. This way
> you can even tell the disk drive to flush its own internal buffers
> between operations.
some versions of windows even have an o/s interfaces to do all the hard
part of #1 for you. they're meant for defragmentation utilities to use.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 11 Mar 2001 10:22:35 -0000
[oops, missed this part.]
<[EMAIL PROTECTED]> divulged:
>When you open a file for r+ access, Windows
>"locks" the file. You can virtually guarantee that the blocks on disk
>that correspond to that file is not going to move.
not always. as long as the filesystem always knows where the clusters
are it's happy. the defrag interface can be used though.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Applications of crypto techniques to non-crypto uses
Date: Sun, 11 Mar 2001 10:25:11 -0000
<E6tq6.355392$[EMAIL PROTECTED]> divulged:
>Really? Do you have a link to the algorithm?
<url:http://www.itu.int/> should have something of use to you.
--
okay, have a sig then
------------------------------
From: Bram Labarque <[EMAIL PROTECTED]>
Subject: Re: Encryption software
Date: Sun, 11 Mar 2001 10:42:58 GMT
On 09 Mar 2001 16:12:32 -0800, Paul Rubin <[EMAIL PROTECTED]> wrote:
> "Henrick Hellström" <[EMAIL PROTECTED]> writes:
> > I haven't heard much but complaints about PGP from ordinary end users. They
> > find it too complicated, and don't like to mess with the security issues
> > involved in exchanging public keys with others. Someone ought to be able to
> > design an application better than PGP in these respects.
>
> I agree with this, though the PGP integrations with MS Outlook and
> similar programs are reasonably easy to use. I do think PGP
> inconveniences users too much for the sake of stopping MITM attacks.
> Those attacks aren't an important threat in most current situations.
> That may change in the future of course.
What are MITM attacks?
Greetings and thanks in advance.
Bram Labarque
------------------------------
From: "Yoad Lustig" <[EMAIL PROTECTED]>
Subject: FIPS 140-2 PRG
Date: Sun, 11 Mar 2001 12:45:33 +0300
I've recently implemented the test (FIPS 140-2) and run it on the first
three files from marsglia's
random CD. I got considerably more failures then the expected 0.0001
(time 5 tests).
Does anyone know whether there is a mistake in the document? or
there is an implementation of the test I can use as reference to check my
code?
thanks in advance
yoad
[EMAIL PROTECTED]
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 11 Mar 2001 11:42:27 GMT
"Phil Zimmerman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What encryption was Hansen using that it was
> so easily cracked?
I am wondering the same thing, since I haven't seen the actual method
described anywhere.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 11 Mar 2001 11:44:22 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> ? How do we know this?
The majority of governments in the world have virtually nothing valuable
enough for anyone else to wish to steal, particularly if it requires
codebreaking. Does anyone really care how large Vulgaria's annual
output of waxed paper in bulk will be for the year 2001?
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 11 Mar 2001 11:52:36 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm sure that's a popular *opinion*, but how
> do we *know* that it is so?
By looking at the algorithms. In RSA, for example, the resources
required to generate and use keys don't increase nearly as fast as the
resources required to factor them, with increasing key length. Other
computer cryptosystems follow the same pattern. The more horsepower you
can bring to bear, the greater the gap between what is required to use
the cryptosystem and what is required to crack it.
> The only arguments I've heard so far have been
> based on an erroneous assumption, that C/A has
> to proceed by brute-force key search or else
> that the best possible attacks are certain
> horribly weak ones that happen to have already
> been published.
Why do you consider this latter assumption to be in error? And who has
assumed the former? Factoring a RSA modulus isn't a brute-force attack,
it's just a very inefficient one; do you know of others (for RSA and
similar systems)?
> Most attacks do not recover just a single bit ...
What do they recover, then, and how?
> ... new information could be constant-folded into
> the problem to produce an easier new problem, and
> iterating will eventually get all the bits.
Over what period of time? It has to be timely and practical, not
something that will take ten years to accomplish.
> The problem is that people are *using today* block
> ciphers as though they were unconditionally secure,
> with no extra margin of safety if that assumption
> happens to be wrong.
So? Compared to what they were using a few years ago, these
cryptosystems _are_ unconditionally secure. Besides, there aren't any
better cryptosystems publicly available.
> There *are* additional, easy to afford, measures
> that could be applied to cover one's @$$.
Unless one is an international terrorist or head of a drug-smuggling
cartel, additional measures are overkill. Anyone with the resources and
motivation to crack one of the good publicly-available cryptosystems out
there isn't likely to stop once he does so, if additional obstacles
remain.
Actually, the best way to crack modern public cryptosystems is to kidnap
the person with the key and torture him until he provides it. It's a
lot cheaper and more efficient than trying to crack the encryption, and
in fact it may be the only practical way to proceed.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 11 Mar 2001 11:53:59 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Although quite often "special circumstances" do
> provide the opening wedges into systems, without
> genuine cryptanalysis a lot of them would not
> have been exploited to nearly the extent that ocurred.
And without those "special circumstances," all of that genuine
cryptanalysis would have produced nothing at all, over any time period.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Applications of crypto techniques to non-crypto uses
Date: Sun, 11 Mar 2001 12:52:13 +0100
those who know me have no need of my name wrote:
>
> <E6tq6.355392$[EMAIL PROTECTED]> divulged:
>
> >Really? Do you have a link to the algorithm?
>
> <url:http://www.itu.int/> should have something of use to you.
Could you provide a hint to ease searching or could
you write a few lines to explain a bit the matter in
question (the issue mentioned by John Savard)?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sun, 11 Mar 2001 12:52:36 +0100
"Douglas A. Gwyn" wrote:
>
> David Wagner wrote:
> > What's lacking is not desire, but knowledge how to proceed.
>
> Step one would be to develop a formal treatment of the propagation
> of information through Boolean functions. The nice thing about
> such functions is they are equivalent to questions. And we know
> how to apply information to evaluating answers to questions, namely
> though weight of evidence aka discrimination information. I would
> feel much better about the state of the art if I could find
> *any*thing along these lines in crypto textbooks..
I am afraid to define and qualtify 'propagation of
information' is a task that is practically imfeasible in
the rigorous sense (which a formal treatment requires),
otherwise one could as well also decide whether a given
bit source is perfectly random.
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Sun, 11 Mar 2001 13:11:30 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >Um have you even picked up a copy of applied crypto?
> >
>
> I am not sure. If its the one Mr BS wrote I picked it up
> at Barnes and Noble. Read part on compression before encryption
> didn't say much. Look at a few other chapters but did not buy.
> I use to have an early copy of the CODE BREAKERS year ago.
> But I also liked the Puzzle Palace. ANd have checked many out
> or read at library.
Impressive.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 11 Mar 2001 13:11:50 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Phil Zimmerman) wrote in
> <[EMAIL PROTECTED]>:
>
> >What encryption was Hansen using that it was so easily cracked?
> >
> >
>
> Well Phil maybe it was PGP.
Or scottu19.5
Tom
------------------------------
From: <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Sun, 11 Mar 2001 08:17:02 -0500
Tom St Denis wrote in message ...
>
-snip flame-
What ever did you do w/your junky PeeBoo, Tom?
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Encryption software
Date: Sun, 11 Mar 2001 14:19:41 +0100
Man In The Middle. Carol tries to connect to Steve, but Eve has tampered
with the DNS service Carol is using (whatever), so Carol connects to Eve
instead. Eve might thereby obtain enough information to impersonate Carol
and connect to Steve. Plain Diffie-Hellman provides no protection what so
ever against such attacks. PGP is vulnerable to MITM attacks in so far that
you usually can't be sure that the public keys you have are authentic. For
example, the owner of the SMTP/POP server you are using might in theory
replace all PGP keys included in e-mail passing through your account and
thereby be able to decrypt/read/encrypt each encrypted e-mail sent later on.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Bram Labarque" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> On 09 Mar 2001 16:12:32 -0800, Paul Rubin <[EMAIL PROTECTED]> wrote:
> > "Henrick Hellström" <[EMAIL PROTECTED]> writes:
> > > I haven't heard much but complaints about PGP from ordinary end users.
They
> > > find it too complicated, and don't like to mess with the security
issues
> > > involved in exchanging public keys with others. Someone ought to be
able to
> > > design an application better than PGP in these respects.
> >
> > I agree with this, though the PGP integrations with MS Outlook and
> > similar programs are reasonably easy to use. I do think PGP
> > inconveniences users too much for the sake of stopping MITM attacks.
> > Those attacks aren't an important threat in most current situations.
> > That may change in the future of course.
>
> What are MITM attacks?
> Greetings and thanks in advance.
> Bram Labarque
>
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Dumb inquiry....
Date: Sun, 11 Mar 2001 08:25:51 -0500
If a PHT is (modular addition) x = 2a+b, y = a+b what if you use 2a+b,
2b+a? Does it have an mathematical inverse? (I don't consider an S-box)
What kind of statistics does it produce? Is it unwise for cryptography?
------------------------------
From: "Dragon" <[EMAIL PROTECTED]>
Subject: Re: Question
Date: Sun, 11 Mar 2001 13:45:29 GMT
Thank you for your reply. Unfortunately, the only thing I remember is that
it was some program which helped you save your password, address lists, or
something and entered them automatically. I think it also saved my bank
account and credit card numbers. so I really can't send it to someone for
decryption. The only other choice I have is to destroy the file. I asked the
question only so I could see if there was a program which could decrypt
based on if you knew some of the contents of the file.
Thank you.
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Dragon wrote:
> > Now that I have cleared that, I was wondering if someone can guide me
> > to any decrypting program. I have this encrypted file which I need to
> > decrypt. I know some of the exact contents of the file. It was
> > encrypted with a program I no longer have. As a matter of fact, I
> > don't even remember the program name any more. One thing I do
> > remember is that I did not have to enter any password or keys to
> > encrypt the file.
>
> It would be a rather strange notion of encrypting if *some* key
> weren't used, because otherwise anyone could execute the decryption
> program to read the original file. If you didn't have to manually
> provide the key then it must have been provided automatically,
> perhaps using a PGP "key ring" or data on a floppy disk, etc.
>
> Anyway, to address your situation directly, there is no such thing
> as a general-purpose program capable of decrypting arbitrary
> encrypted files. If you can't at least find the name of the program
> used to do the encryption, which would enable you to ask the "hacker"
> community, then your best bet would be to give whatever information
> you have to a professional cryptanalyst and pay him to try to crack
> it. Success would not be guaranteed (although perhaps payment could
> be contingent on success).
------------------------------
** 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
******************************
