Cryptography-Digest Digest #484, Volume #11 Tue, 4 Apr 00 11:13:01 EDT
Contents:
Re: Keys in blowfish (Tom St Denis)
Re: Passwords in Zip Archives (Tom St Denis)
Re: Passwords in Zip Archives (Martin Kahlert)
Re: summing hashes is not safe? ([EMAIL PROTECTED])
PGP webmail ([EMAIL PROTECTED])
Re: NSA (Richard Herring)
Re: BestCrypt and BCWipe for linux ("Keith Monahan")
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying
to silence our program? It's not working...) ("Gary Watson")
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is (Nick
Barron)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who (Nick
Barron)
Re: Passwords in Zip Archives ([EMAIL PROTECTED])
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Trevor L. Jackson, III")
Re: I will make ANY software for ANYBODY ("Trevor L. Jackson, III")
Re: GSM A5/1 Encryption (Matt Linder)
Re: GSM A5/1 Encryption (stanislav shalunov)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying
to silence our program? It's not working...) ("xyz")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Keys in blowfish
Date: Tue, 04 Apr 2000 11:19:43 GMT
Joey Moose wrote:
>
> I am looking at using blowfish to encrypt information within a Web page that
> is being transferred between servers. Do I need to worry about using
> different keys for each message I send? My guess is that a different key
> should be used each time to avoid someone comparing two messages...
You are on the right track. Generally you change session keys between
messages to avoid that such problem. In PK systems employing RSA for
example this is not a big deal since random keys are made for every
message, then RSA encrypted, etc..
However where you are not using that, [say peekboo v2 for example], you
must salt the key, which means you take the fixed secret password/key,
append a known 64+ bit random string to it, then hash it. So you get
A = K + SALT
K' = HASH(A)
Good luck,
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Passwords in Zip Archives
Date: Tue, 04 Apr 2000 11:22:43 GMT
Patrick Bangert wrote:
>
> Dear All,
>
> I recently created zip archives with some important work of mine for
> backup purposes. I need to unzip these now since I need the backup but I
> have forgotten the password I put on them. Is there some kind of a
> utility that will allow me to find the password? (This is not for
> illegal use - it is truly for my own files!)
>
If you know the alphabet and size of the password you can brute force it
:)
If you had a 5 letter password with a-z, you have a keyspace of 26^5 to
search [about 2^23.5] :-)
Tom
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Re: Passwords in Zip Archives
Date: 4 Apr 2000 12:01:48 GMT
Reply-To: [EMAIL PROTECTED]
[Posted and mailed]
In article <[EMAIL PROTECTED]>,
Patrick Bangert <[EMAIL PROTECTED]> writes:
> Dear All,
>
> I recently created zip archives with some important work of mine for
> backup purposes. I need to unzip these now since I need the backup but I
> have forgotten the password I put on them. Is there some kind of a
> utility that will allow me to find the password? (This is not for
> illegal use - it is truly for my own files!)
You could try this link:
http://131.155.140.135/~galactus/remailers/index-crack.html
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: summing hashes is not safe?
Date: Tue, 04 Apr 2000 12:18:54 GMT
In article <8ca83u$vmi$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8ca1b5$ob7$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > In this case there is a limitation of 24 bytes to the sum. So if
a+b >
> > 24 bytes (very likely) information of the hashes is lost.
> > In this case a few 100 message-hashes are added.
>
> No, you are probably mixing up concatenation with addition. If you add
> two 160-bit values the sum will be at most 161-bit, i.e. double the
> maximum value of a 160-bit value.
>
> ...but certainly this means that information is lost when you add
> values.
>
> > How hard is it to construct (multiple) messages which are added to
> > match the same sum of the orignal hashes?
>
> It is claimed to be very hard. In order to perform such an attack, you
> must find a message which matches at least one of a bounded number of
> hash values.
>
> > The summed hash is checked first, then the messages are decoded;
bogus
> > messages are discarded.
> > Mike
>
> May I ask: How do you know that the hash signature is intact?
>
The summed hash signature is signed afterwards.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: PGP webmail
Date: Tue, 04 Apr 2000 12:15:32 GMT
Hi
I recently discovered a new free secure webmail site, and I had a
question for the group:
how secure is the PGP and SSL- encrypted webmail offered at
www.lokmail.net? Are there any obvious security weaknesses to it?
I am curious to see what the group thinks of this.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: NSA
Date: 4 Apr 2000 12:33:31 GMT
Reply-To: [EMAIL PROTECTED]
In article <8cbou9$n32$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Supposedly, the UK's Defence Evaluation &
> Research Agency maintains the last 90 days of
> usenet messages
Wow. You mean they have <gasp> a *news-server* ?!
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Keith Monahan" <[EMAIL PROTECTED]>
Subject: Re: BestCrypt and BCWipe for linux
Date: Tue, 04 Apr 2000 13:18:13 GMT
I've been using their Windows version of it for quite some time and
have been pretty pleased with it. One of the nicest products
I have seen in its class.
I have spent considerable amounts of time pouring over their
Blowfish implementation(that I use) to ensure its correctness.
I'm not a cryptographer nor an expert programmer but I've been
comparing it with other known good implementations. They do
everything fairly standard and straightforward, no tricky stuff --
nice and simple. Easy to follow.
A while ago, despite being careful & well aware of the dangers
associated with losing my passphrase, I lost my passphrase. Jetico
was nice enough to provide me with a replacement .dll file which
was a passphrase guesser, which they created to test how well
they could attack their product -- from a pure dictionary guess
method. And of course, this is not an indication of cipher
strength. Or that they implemented Blowfish correctly.
Or product strength. In any event, after about 6 months worth
of work(and knowledge of 95% of the passphrase) I successfully
cracked my passphrase.
By far the most knowledgable and helpful support staff I have
EVER seen on ANY product.
Keith
Chem-R-Us <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Here I've been beating my head against a wall trying to develop
> encrypted volumes for my Linux box. http:www.jetico.sci.fi has released
> some beta code that does an exellent job of creatging encrypted volumes.
> As all Linux users know, Linux alpha code is much better than gatesware
> beta code. And BCWipe is simply excellent. Don't take my word for it, dl
> it and give it a whirl.
>
> I have been examining the sources and I have yet to find a problem with
> the code.
>
> --
>
> Chem-R-Us
------------------------------
From: "Gary Watson" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...)
Date: Tue, 4 Apr 2000 15:01:38 +0100
EE Support <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 15 Mar 2000 22:15:17 +0000, Withheld <[EMAIL PROTECTED]>
> wrote:
> >
> >Unless I've misunderstood the point, this would result in so many
> >possible thresholds for what was there before the multiple wipe passes
> >that it would be impossible to get anything meaningful from it at all?
> >
> >[cut]
>
> Hi
> A problem is RLL and encoding etc.
>
> The data sent to the disk isn't the same as the data physically
> written.
>
> Disks use encoding systems to maximise the on/off states available to
> the heads at a certain speed.
>
> What goes to the disk as
> 010101010101010101010101010
>
> Is magnetically saved more like
> 000000011111100000111111111
>
> We still think secure software overwriting trashes the data and nobody
> has found a practical way to beat our Evidence Eliminator software
> yet.
The cool thing about your software (as opposed to incinerating the hard
drive) is that it doesn't destroy data I want to keep. It just nukes areas
subject to forensic scavenging, which are of no practical use to me. To be
honest, I think it's irresponsible that Microsoft doesn't have this
functionality built-in. I've got IE5 and if you go to Internet Options and
Delete Temporary Files, you can still go to Explorer and see cached data
from all of the sites you have visited.
By the way, Evidence Eliminator seems to work better than other packages of
this type....
--
Gary Watson
[EMAIL PROTECTED] (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF ENGLAND
http://www.nexsan.com
------------------------------
From: [EMAIL PROTECTED] (Nick Barron)
Reply-To: [EMAIL PROTECTED]
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
Date: Tue, 4 Apr 2000 15:07 +0100 (BST)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Andrew
Carol) wrote:
> That said, the very people who are likely to really know are not
> talking. I am sure that when I worked with classified harddrives in
> the military there were VERY strict rules about declassification, none
> of which left the disk in a useable condition.
In the UK too... With the military, the very small residual risk that a
"wiped" hard drive may still be accesible to a hostile intelligence service
is not acceptable above a particular level.
There's also the labour costs to consider; with a typical PC drive costing
<UKP 100 these days, it doesn't take much before the time taken to wipe it
and fill in the relevant paperwork allowing its reuse simply isn't
worthwile, so physical destruction is a simpler option.
------------------------------
From: [EMAIL PROTECTED] (Nick Barron)
Reply-To: [EMAIL PROTECTED]
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who
Date: Tue, 4 Apr 2000 15:07 +0100 (BST)
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (EE Support) wrote:
> We challenge anybody to beat our software and will take pleasure in
> upgrading it to defeat their efforts.
Yeah, I'm sure the NSA and CESG will be happy to do your product testing and
development for you :-)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Passwords in Zip Archives
Date: Tue, 04 Apr 2000 14:10:04 GMT
FZC is the best to brute-force zip files, it's very fast:
http://www.netgate.com.uy/~fpapa/
Patrick Bangert <[EMAIL PROTECTED]> wrote:
>Dear All,
>
>I recently created zip archives with some important work of mine for
>backup purposes. I need to unzip these now since I need the backup but I
>have forgotten the password I put on them. Is there some kind of a
>utility that will allow me to find the password? (This is not for
>illegal use - it is truly for my own files!)
>
>Thanks.
>Pat
>
------------------------------
Date: Tue, 04 Apr 2000 10:26:49 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
DMc wrote:
> On Mon, 03 Apr 2000 23:09:46 -0700, Anthony Stephen Szopa
> <[EMAIL PROTECTED]> wrote:
>
> I get that you are attempting to sell your crypto system to some
> group of people. Do you honestly think you are going to do well with
> that goal by insulting people?
Actually it may be worse than that. If he's been selling software as
cryptologicaly secure in spite of the criticisms he's received and said
software turns out to be the junk/snake-oil the criticisms claimed it to be, he
may be subject to suits for recovery of the money he collected and any
consequential damages those customers sustains through the use of his
software. If someone publishes a credible "crack" of his software, those
customers may also have conversion costs attributable to their reliance on his
software and the need to hastily replace it with something that works.
On the criminal side, purveyance of a flawed product, one _not_ suitable for
its intended use, may be fraud. Ignoring cautions regarding the worthlessness
of said software may be negligence, which is manifest as a "careless disregard
for another's welfare".
Thus using insults as rejoinders may cost him much more than simply lost
customers. If insults are all he offers in defense of his actions and
statements those insults may be expensive in terms of money (damages) and time
(prison).
------------------------------
Date: Tue, 04 Apr 2000 10:28:47 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: I will make ANY software for ANYBODY
David A Molnar wrote:
> Paul Schlyter <[EMAIL PROTECTED]> wrote:
> > Perhaps the ultimate porting project would be to port Win-2000 to
> > a Turing machine.... :-)))))))))))))))))
>
> Only if it is an object-oriented Turing machine. :-)
>
> ObCrypto : Does there exist a general construction which will
> allow me to take a Turing machine, and then create a "blinded" Turing
> machine -- such that
> * L(blinded TM) = L(TM)
>
> I can give you a description (5-tuple) of the blinded TM and
>
> * You can determine whether an input is accepted or rejected by
> said blinded TM
> * You gain no information about the transition table of the
> original TM
> * You can do no better than guessing to determine in advance
> whether a given input will be accepted by the blinded TM
>
> There was a recent thread on comp.theory about determining if two
> NDFAs are equivalent which seemed somewhat relevant. The problem there
> was that they were considering whether you could determine if two NDFAs
> are equivalent given only black-box access to the NDFA. Here you might
> get to see the transition table as well.
>
> (why? don't want to decompile Windows 2000 for Turing Machines, do we?
> that's valuable intellectual property!)
While the magnitude of the value may be large, the sign of the value is
pessimistic. ;-)
------------------------------
From: Matt Linder <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: Tue, 04 Apr 2000 14:20:42 GMT
In article <8cc3hq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Gregory G Rose) wrote:
>
> Correction: TDMA (IS-136) does not use either A5.
>
What does TDMA use then?
What about CDMA for that matter!
>
> Well, if you think you want the truth, I don't
> know why you are here, but you can trust me...
>
> The key in current, deployed, GSM systems is
> artificially limited to 54 bits, not 64. (See
> www.scard.org). Even then, brute force is
> difficult but not infeasible. However you've
> specified "real time"... if an average call lasts
> 2 minutes, you don't have a big enough budget to
> break it before it ends. (Of course you could
> record it...)
>
> Biryukov/Shamir/Wagner have the combined technique
> that Tom mentioned, however it assumes *known
> plaintext*. While I agree that it means A5/1 is
> cryptographically broken, known plaintext for a
> voice call is pretty hard to arrange, what with
> vocoder compression and stuff happening to the
> signal. It is much easier for a data call
> though... send the guy some spam and wait for him
> to download it, then read the rest of his email at
> the same time. It is this difficulty which
> accounts for the crypto people saying it is broken
> and the telephone people saying it isn't.
>
> hope that helped,
> Greg.
>
Greg,
Thats what I am talking about when I say "real-time". I mean tune to a
spefic channel and time slot, analyze the data for up to about a minute
or so to break A5/1 then hear the audio without any known plaintext or
73 GB hard drives. Is this possible or not?
I think thats what the phone people mean when they say it has not been
broken, they are thinking of the old analog system, where anyone with a
scanner could pick them up.
Thanks in advance,
Matt.
> --
> Greg Rose INTERNET: [EMAIL PROTECTED]
> QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
> Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
> Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: GSM A5/1 Encryption
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Tue, 04 Apr 2000 14:39:17 GMT
[EMAIL PROTECTED] (Gregory G Rose) writes:
> Biryukov/Shamir/Wagner have the combined technique that Tom
> mentioned, however it assumes *known plaintext*. While I agree that
> it means A5/1 is cryptographically broken, known plaintext for a
> voice call is pretty hard to arrange, what with vocoder compression
> and stuff happening to the signal.
Bruce Schneier mentions in AC2 that, e.g., CELP was designed by the NSA.
The final encoding before encryption might provide enough known plaintext.
------------------------------
Reply-To: "xyz" <[EMAIL PROTECTED]>
From: "xyz" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...)
Date: Tue, 04 Apr 2000 14:47:51 GMT
Instead of using your commercial product, I use BC Wipe which is free from
http://www.jetico.com/ . Runs on Win9x, ME & 2K.
"EE Support" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 15 Mar 2000 22:15:17 +0000, Withheld <[EMAIL PROTECTED]>
> wrote:
>
> >[cut]
> >>I fantasize that your data is stored on hard disk tracks for a long time
> >>before it gets wiped (esp. with new users of your still improving
> >>software). So the magnetic data will leak over to the surface area next
> >>to the track. Then you overwrite with zero's once! That leaves traces of
> >>the previous data next to the track. Above a certain treshold the data
> >>will have been 1 and below it will have been 0. Not very commercially
> >>intesting until your product apeared, but it doesn't sound difficult to
> >>recover IMO.
> >>
> >>Better would be to steal the random data collection from the source of
> >>pgp 6.5.1i or use Jarrow from counterpane to generate some
> >>cryptographically strong random data and use it to overwrite previous
> >>data on the harddisk. It doesn't have to be 10Gig strong for a 10Gig
> >>harddrive, but hashing the initial random value a few times should do
> >>the job. At no loss of speed (maybe 0.01% due to the hashing) you now
> >>overwrite the previous data more securely than just by overwritting with
> >>zero's only. That would be great.
> >>
> >>Maybe the area close to the written track will still get magnetized by
> >>the previous data, but you can't just set a treshold. You'll have to set
> >>at least three treshold. One for going from 0->0 (very low magnetic
> >>treshold), 0->1 (higher), 1->0 (still higher depending on time of last
> >>wipe) and 1-1 (highest).
> >
> >I hope I'm not being ignorant here, but is a stream of random data
> >entirely necessary? Given you are trying to mask residues from previous
> >data, wouldn't a succession of alternating patterns 101010101010...
> >followed by 0101010101... do the same thing - blur any residues until it
> >was meaningless. Using memory blocks you could define this pattern and
> >then dump it into disk blocks wherever you wanted. Once this pattern had
> >been followed a suitable number of times it could all be overwritten
> >with 00000000 to clear the disk.
> >
> >Unless I've misunderstood the point, this would result in so many
> >possible thresholds for what was there before the multiple wipe passes
> >that it would be impossible to get anything meaningful from it at all?
> >
> >[cut]
>
> Hi
> A problem is RLL and encoding etc.
>
> The data sent to the disk isn't the same as the data physically
> written.
>
> Disks use encoding systems to maximise the on/off states available to
> the heads at a certain speed.
>
> What goes to the disk as
> 010101010101010101010101010
>
> Is magnetically saved more like
> 000000011111100000111111111
>
> We still think secure software overwriting trashes the data and nobody
> has found a practical way to beat our Evidence Eliminator software
> yet.
>
>
> --
> Regards,
> EE Support
> [EMAIL PROTECTED] (remove NO_SP_AM for e-mail)
> http://www.evidence-eliminator.com/
------------------------------
** 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
******************************
