Cryptography-Digest Digest #876, Volume #13 Mon, 12 Mar 01 20:13:01 EST
Contents:
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: OverWrite: best wipe software? (Anthony Stephen Szopa)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Zero Knowledge Proof ("Douglas A. Gwyn")
Re: Encrypt then HMAC or HMAC then Encrypt? (Ben Cantrick)
Re: Question about double encryption ("Joseph Ashwood")
Re: => FBI easily cracks encryption ...? (CR Lyttle)
Re: Zero Knowledge Proof (SCOTT19U.ZIP_GUY)
Re: Encrypt then HMAC or HMAC then Encrypt? (Paul Rubin)
----------------------------------------------------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Tue, 13 Mar 2001 01:21:47 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98jkd8$1ft$[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >You were more or less arguing that PCFB mode would be too complicated to
use
> >for most software developers.
>
> No, I wasn't. My argument has nothing to do with complexity,
> and it has nothing to do with specific modes. Instead, I'm talking
> about explicit vs. implicit authentication.
It's perhaps semantics, but according to my way of thinking avoiding
failures is usually a complex task.
> My claim: The crypto layer should explicitly check all messages
> to be sure they are properly authenticated.
>
> The problem with error-propagating modes: The check is implicit,
> and it is left up to the application. Both of these introduce
> failure modes not present in my approach.
1. I am not sure I understand what you mean by "implicit". Yes, the check
might be intertwined with other processes the application would do anyway.
But that means that the check might be more efficiently implemented. Not
that the nature of it's design entails that there are any possible
situations where it would be unacceptably unreliable.
2. As I already mentioned, your approach introduces failure modes (some
extra "crypto engine" compatibility issues) not present in my approach.
3. The failure modes are known and might ultimately be dealt with, at least
by the application. Otherwise the underlying cipher (or hash or whatever
kind of diffusion method is used) has some weakness that would be present in
other modes as well.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Mon, 12 Mar 2001 16:31:03 -0800
Simon Johnson wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Benjamin Goldberg wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > > [snip]
> > > > In addition to the prior instructions here are the new
> > > > recommendations and facilities. What have I forgotten?
> > > >
> > > > "NOTE: For best results this program should be used only with
> > > > Windows OSs and there should be no other programs running while this
> > > > program is running. Maximum security from using this software
> > > > results when overwriting files that are stored on 1.44MB floppy disks.
> > > > Therefore, your most sensitive files should be written directly to
> > > > 1.44MB floppy disks if you must be as absolutely sure as possible
> > > > that this data is as nearly impossible as possible to recover once
> > > > overwritten using this software. SCSI hard drives are not
> > > > recommended. Nor are compressed drives. I use this software to
> > > > overwrite files on my own IDE hard drives.
> > >
> > > Bwahahahahaha! Now that you finally figured out that there's no way,
> > > using purely portable code (the stdio library), to do what you
> > > originally wanted to do with hdds, you added a disclaimer limiting your
> > > software's usage to only those cases in which it works, id est, the ones
> > > where we don't need your software anyway.
> > >
> > > If I've got data on a floppy, and I want it securely erased, I copy the
> > > stuff I want to save to a new floppy, and burn the old one. Floppies
> > > are cheap. The cost of buying new floppies is lower than the security
> > > risk of downloading binaries from your website.
> > >
> > > --
> > > The difference between theory and practice is that in theory, theory and
> > > practice are identical, but in practice, they are not.
> >
> >
> >
> > Do I detect anguish under this evasion?
> >
> > I told you that if you dedicate a partition of about 18,144,000
> > bytes on your hard drive, for example, let's call it drive H:\, that
> > you can be assured of overwriting any data you write there with
> > OverWrite if you follow my recommendations.
> >
> > For instance, write 14 files of dummy data of about 1,296,000 bytes
> > each to H:\ thus filling it up completely. Then delete, say the 7th
> > file. (This is a restricted example to highlight my contention.)
> > Write any sensitive data to this newly freed space in H:\ and perform
> > any processing you like there within this free space on H:\.
> >
> > When you want to subsequently overwrite this data using Ciphile
> > Software's OverWrite Utility, then delete any file(s) in this free
> > space. Now delete the 6th and 8th dummy data files which bound both
> > sides of this space. Now write a file of 3,888,000 bytes in this
> > free space. This should completely overwrite this newly freed space
> > that includes the original free space from the deletion of the 7th
> > dummy file originally. Now use OverWrite to overwrite this
> > 3,888,000 byte file. Overwriting a file of this size should be
> > larger than any hardware cache in your system so it will force a
> > flush and therefore a write to disk.
> >
> > To claim that my conclusions are wrong you have to argue that
> > the original dummy file, the 7th, was not between the 6th and 8th.
> > Or that the OS or hardware actually writes to another partition /
> > drive as part of its optimizations.
>
> hrm, i have no doubt that in the logical sense at least the file is
> overwritten. The fact that the OS can no longer read the file doesn't mean
> it can't be recovered however. This is the point in contention, I believe.
>
> > Additionally you will have to support your claim that my observations
> > of the hard drive LED are nothing more than a light indicating the
> > passing of data perhaps to the hard drive cache when I have in fact
> > observed that the hard drive heads not only move in association with
> > the LED lighting up but a vigorous write operation is obviously
> > taking place. If what you say is true why are the hard drive heads
> > repositioning and writing to the hard drive if this is only an LED
> > lighting up. What is going on here?
>
> Your in windows, it does not cache the same way as linux/unix systems.
>
> > I guess the bread and butter point I am making that OverWrite does
> > work if used according to my recommendations on hard drives is too
> > much for you or anyone else to handle so you go off on pathetic side
> > tracks some of which I have conveniently provided you to amuse
> > yourselves while you ponder the unthinkable: that Ciphile Software's
> > OverWrite program damn well works!
>
> I'm sure it works just fine, but its probably not doing what you want it to
> do.
>
> Simon.
The point is all but dead now for lack of counter arguments and lack
of enthusiasm from would-be detracters in the face of certain defeat.
I seem to have tightly boxed up for disposal all objections quite
tidily.
The point of contention was whether or not OverWrite does in fact
overwrite the intended file.
I have demonstrated to you a procedure whereby the OverWrite program
is certainly forced to overwrite the file. I have not heard one
proposition that can be used to dispute this since I posted these
procedures and updated the software less than a week ago.
Prior to this, the what-ifs were coming hot and furious. Now nothing
but flagrant BS.
Ciphile Software's OverWrite Security Utility program Version 1.21
is available now for direct download at http://www.ciphile.com
That's Version 1.21 uploaded 3/12/01
Signed,
Anxious for the Lewis - Ruiz bout.
(I believe this is the last revision I will be making for some time.
These have mostly been in the explanation in the instructions to
clarify exactly how to use the software to achieve thoroughly
overwriting your intended file using the OverWrite program.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Mon, 12 Mar 2001 23:37:44 GMT
Mok-Kong Shen wrote:
> My point is essentially the following: If one can define and
> quantify 'propagation of information' (rigorously), then
> one must be able to measure the information content in
> an arbitrarily given bit sequence in exact terms.
But that's wrong. Information is inherently contextual (relative);
it does not inhere in individual, out-of-context bit values.
A given bit sequence might or might not convey information,
depending on one's expectations. E.g. if you expect to receive
a 0 bit and someone sends you a 0 bit, you do not receive "1 bit"
of information (more nearly 0 bits, depending on how strong your
a priori expectation is).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Zero Knowledge Proof
Date: Mon, 12 Mar 2001 23:44:21 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Guys if I made any errors correct me.
It didn't sound to me like you know what is generally meant
by "zero-knowledge proof". It means, essentially, a method
whereby one person can convince another through an exchange
of messages that he knows some piece of information, without
disclosing any of that information. It's not a method of
encryption, but it may have applications in authentication.
Please read up on this in one of the cited textbooks before
continuing the discussion.
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
Date: 12 Mar 2001 17:34:17 -0700
In article <[EMAIL PROTECTED]>,
Bjorn Forsberg <[EMAIL PROTECTED]> wrote:
>I am storing an encrypted data packet. Typically small (less than 1K
>FWIW). I am encrypting the data, then taking an HMAC of the encrypted
>data plus other plain text data. The HMAC is appended to the plain text
>data and cipher text data over which it operates on.
>
>I know SSL takes an HMAC of data then encrypts everything including the
>HMAC. I can't see anything really definitive that would say that one
>method is better over the other?
>
>Can someone please give me some good reasons to pick one way vs the
>other?
If you transmit the MAC unencrypted, and an attacker intercepts the
message, tries to break it, and thinks they have, they may be able
to verify their guess by running the MAC on the possible plaintext.
Admittedly, this isn't helping an attacker much, because if they get
even one (possibly trivial) byte wrong in their guess, the MAC
shouldn't give them anything close to the value they see.
Transmitting the MAC unencrypted also makes it slightly easier for
the attacker to corrupt messages and fake their MACs. But if they
can corrupt messages, they can probably pull a man in the middle
attack and you're screwed unless both parties have previously
exchanged keys in a secure fashion.
MACing the plaintext first, then putting the MAC at the front of the
plaintext before encryption might actually help increase security, in
that the MAC would presumably be less predictable than the normal first
few bytes of a message. Enigma was weakened, one might reasonably say
fatally so, by having a predictable first few characters in most messages.
But, I suppose there might be some unforseen consequence of putting
a MAC at the front of an encryption stream if the MAC algorithm and
the encryption algorithm are similiar.
If you really want to be paranoid, I suppose you could encrypt the
plaintext to cyphertext, MAC the cyphertext, append/prepend the MAC to
the cyphertext, then re-encrypt the whole thing with the same key used to
do the original encryption. Whether this would weaken the encryption or
not I don't know. It would probably depend on the algorithm.
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
"Konya wa hurricane, Nene! <Giggle>" -Nene Nukem
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Question about double encryption
Date: Fri, 2 Mar 2001 16:10:34 -0800
[sent by private e-mail as well as newsgroup]
If it weakens security it will not weaken security below that offered by
3DES. The proof of this is quite simple, if encrypting a 3DES stream with
Blowfish weakened the stream a 3rd party could easily encrypt with Blowfish
to encrypt the stream, rendering it equivalent. I won't go into more details
about it, but you can prove that the opposite is not necessarily the case,
it need not be minimally equivalent to blowfish, however since it's 3DES I'm
inclined to say that (without any evidence to the contrary) I must side with
intuition and state that this will be at least as strong as either one
individually.
Joe
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> First of all I'm fairly new to all this, so apologies if this is a
> stupid question.
>
> Is it possible that the following scenario actually *weakens* the
> encryption strength :
>
> A TCP/IP link exists that uses Blowfish (128 bit). The link is used
> for multiple ports, one of which is ssh. The ssh link uses 3DES (in
> CFB mode I believe), so effectively you have a 3DES stream encrypted
> by Blowfish and then transmitted. The receiving machine decrypts the
> Blowfish algorithm and forwards on the ssh stream to another machine
> which decrypts the 3DES.
>
> Note that I am not concerned about the security at the receiving side
> - I'm primarily concerned about the implications at the transmitting
> side.
>
> Please don't hit me with too much math - links to sites with papers on
> this or similar topics would be good.
>
> TIA.
>
> ________________________________________________________________________
> Protect your privacy! - Get Freedom 2.0 at http://www.freedom.net
>
------------------------------
From: CR Lyttle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 13 Mar 2001 00:46:36 GMT
Phil Zimmerman wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Exchanging keys does not involve any public contact what so ever. That is
> the beauty of the public-key encryption system. Had Hansen used a single key
> system, or a self-decrypting archive system, then Hansen would have had to
> transmit the "passphrase" to his Russian handlers, thereby exponentially
> compromising his ID.
>
> I don't know what encryption system he used. Now the NSA is years ahead of
> public cryptography, hence one of its former algorithms was a defeated
> candidate for AES. I don't know whether or not the NSA was involved in
> helping the FBI decrypt Hansen's data.
>
> BTW, I usually use 4096 length. Anyone have any comments on which algorithm
> they prefer? TwoFish, AES, CAST, IDEA, TripleDES???
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
> Comment: Trust But Verify
>
> iQA/AwUBOqxOpYQHeAMpsuAHEQK7EgCglwPPxbKQaPFXIVjDfCU9e8GldQwAnR3G
> M+DRW0fqwS0rxhZwKu60gY86
> =ODxk
> -----END PGP SIGNATURE-----
It does involve contact (an exchange of information). If public key is
used, both parties have to publish their public keys. The spy has to
publish his in a way that doesn't draw attention to him. Thus he has to
visit a drop or take out a newspaper ad or some such. That creates a
risk of detection. Likewise the handler has to get his key to the spy,
which involves another contact. The spy has to use a public key from the
handler, the handler has to use a p[ublic key from the spy. If the keys
are contained in a drop, then reading a drop gets the keys and possibly
all older keys. To read what the handler is giving the spy, the FBI has
only to find the private key the spy kept on his computer. To read what
the spy gave the handler, the CIA has to monitor the handler and grab
some of his keys. But more likely, they would just get the raw
information from the spy.
In any event, exchanging keys requires two communications channels and
two contacts.
I like to try out protocols by getting a group of people together and
have them do a physical walkthrough. For this you could put the "spy" in
one room, the "hanlder" in another, and the "FBI" in a third. Exchage
information could take place in a 4th room. After the first meeting, the
spy and handler cannot be in the 4th room together. But at some random
time, the "FBI" can begin watching what the "spy" and "handler" do in
the 4th room. Neither the "spy" nor "handler" are told when the "FBI"
begins watching. Its a fun game, and can reveal some subtile flaws in
plans
--
Russ
<http://home.earthlink.net/~lyttlec>
Home of the Universal Automotive Test Set
Linux Open Source (GPL) Project
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Zero Knowledge Proof
Date: 13 Mar 2001 00:47:21 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in
<[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>> Guys if I made any errors correct me.
>
>It didn't sound to me like you know what is generally meant
>by "zero-knowledge proof". It means, essentially, a method
>whereby one person can convince another through an exchange
>of messages that he knows some piece of information, without
>disclosing any of that information. It's not a method of
>encryption, but it may have applications in authentication.
>Please read up on this in one of the cited textbooks before
>continuing the discussion.
>
As far as crypto goes. I do know that the key exchanges that
occur involve zero knowledge methods. Which may be different
from what your calling zero knowledge proofs.
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: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
Date: 12 Mar 2001 16:55:42 -0800
[EMAIL PROTECTED] (Ben Cantrick) writes:
> If you transmit the MAC unencrypted, and an attacker intercepts the
> message, tries to break it, and thinks they have, they may be able
> to verify their guess by running the MAC on the possible plaintext.
No. Computing the MAC requires a secret key.
------------------------------
** 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
******************************
