Cryptography-Digest Digest #350, Volume #11 Thu, 16 Mar 00 19:13:01 EST
Contents:
Re: Enigma encryption updated (Adam D) ("Adam Durana")
Re: Magnetic Remenance on hard drives. ([EMAIL PROTECTED])
Re: Universal Language (Paul Koning)
Re: US export status of RC4? (Paul Koning)
Re: Enigma encryption updated (Adam D) (Nemo psj)
Re: US export status of RC4? (Impervious)
Re: Off Topic AND Newbie-ish! Security... (Mike Andrews)
Re: Universal Language (Mike Mccarty Sr)
Re: Kosherising (Anton Stiglic)
Re: SALT with RC4, where do I store the SALT? (Impervious)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying
to silence our program? It's not working...) ("Scotty")
Re: NIST, AES at RSA conference (John Savard)
Re: SALT with RC4, where do I store the SALT? (Doug Stell)
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Enigma encryption updated (Adam D)
Date: Thu, 16 Mar 2000 16:24:13 -0500
I read your paper, its much more confusing than it was at first. You should
read other papers which describe ciphers and see how they do it.
Pseudo-code and diagrams may help.
Why is my name in the subject of this post? Or is there another Adam D.
reading sci.crypt?
- Adam
"Nemo psj" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi everybody i have found a RC4 method of encryption and have
incorperated it
> into my algy for those of you who have mailed me suggesting i change it to
> include a "Better" system i have done so check it out here.
>
> http://www.puregold.cjb.net/
>
> click on the link labeled "Method"
>
> -Pure
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Magnetic Remenance on hard drives.
Crossposted-To: alt.privacy,alt.security.pgp
Date: Thu, 16 Mar 2000 21:33:45 GMT
In sci.crypt Withheld <[EMAIL PROTECTED]> wrote:
> 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.
The actual bit pattern written to disk will vary depending on the
encoding sytem used by the drive. So, there's no way to insure that
you're actually flipping bits by writing fixed paterns. For a more
detailed explanation of the problem, see
http://www.cs.auckland.ac.nz/~pgut001/secure_del.html.
The algorithm described in this paper is the backbone of at least two
programs. My own srm (http://srm.sourceforge.net) and wipe
(http://wipe.sourceforge.net). srm is a drop in replacement for the
Unix rm(1) whith an emphesis on being coded at an increadably simple
level to discourage unitentional bugs. It's perfect if you just want
somthing you can call rm and always overwrite files.
Wipe is a more complete solution with its own command line args and
additional features, such as configurable amounts of overwriting,
support for wiping the empty blocks on a device, etc. It's perfect if
you want a more industrial-strength, one-stop file shredder.
There are a few other packages I looked at while developing srm, all
of which had one or more problems. The wipe man page has a list of
some, and a bit of searching should turn up more.
> 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?
The problem here is that noone knows how much information physical
examination of the disk can recover. It's a safe bet that the newer
the disk, the more passes you need to obliterate information. It's
also a safe bet that a well-funded laboratory can recover more than
someone doing it with home built equipment in their garage. Beyond
that, until someone with the equipment and expertise actually tries
various combinations of disks and destruction methods, there's no way
to tell how well they work.
In the long term, your best bet is to store sensetive information
encrypted on removable media only, and incinerate it when you're
finished.
--
Matthew Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Universal Language
Date: Thu, 16 Mar 2000 16:30:05 -0500
[EMAIL PROTECTED] wrote:
>
> Richard Herring wrote:
> >...
> > Are there *any* instances where the vocative can be distinguished
> > from the nominative, or is it just a grammarians' invention?
> > Richard Herring | <[EMAIL PROTECTED]>
>
> I dont know Russian that good, but in Latvian there is
> difference between nominative and vocative
Yes, but that doesn't help, because Latvian is a very
different language...
It's been a long time. I believe the answer to the question is
"yes -- but not all that many cases". The same, FWIW, applies
to Latin, which is generally thought of as having 5 cases but
the correct answer there is 6 for the same reason (vocative).
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: US export status of RC4?
Date: Thu, 16 Mar 2000 16:33:57 -0500
Guy Macon wrote:
>
> In article <8apn7d$ktg$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bill Unruh)
>wrote:
>
> >Tell us more. As I saw the regs, if you publish the source and make it
> >freely available ( eg GPL) then you can export almost anything.
>
> I would be willing to export it for him - I don't think that doing
> so is illegal in the U.S.
It's either legal for both of you, or for neither of you.
Bill makes the point I was going to. Manuel, be sure to read
the *current* export rules carefully. There's a lot you can do
freely now. Do *not* rely on unofficial summaries that are
more than a month or two old, because they are likely to describe
the bad old days before 1/15/2000. Not that what we have now is
perfect -- but it is a whole lot better than what it was.
paul
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: Enigma encryption updated (Adam D)
Date: 16 Mar 2000 22:27:26 GMT
Well i need help then in how to "properly" write descriptions and in what
language to do so.. And yeah i have read through chapter 6 of Applied crypto
and my cipher can be explained in similair terms but it makes it more
confusing. Any other papers you might know of? Also your name is in subject
because in a mail you sent me you suggested i get back to you when and or if i
change my cipher...so i did
-Pure =)
------------------------------
From: [EMAIL PROTECTED] (Impervious)
Subject: Re: US export status of RC4?
Date: Thu, 16 Mar 2000 22:33:32 GMT
On Thu, 16 Mar 2000 16:33:57 -0500, Paul Koning <[EMAIL PROTECTED]>
wrote:
>Bill makes the point I was going to. Manuel, be sure to read
>the *current* export rules carefully. There's a lot you can do
>freely now. Do *not* rely on unofficial summaries that are
>more than a month or two old, because they are likely to describe
>the bad old days before 1/15/2000. Not that what we have now is
>perfect -- but it is a whole lot better than what it was.
Thanks for the input guys! From what I read, they still don't want you
exporting anything with over a 56-bit key. Am I reading it wrong? My
program is RC4 based and uses a 256-bit key with SHA. I am working on
the SALT now..
Thanks,
Manuel Alvarez
------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: Off Topic AND Newbie-ish! Security...
Crossposted-To: sol.lists.freebsd.questions
Date: Thu, 16 Mar 2000 22:41:52 GMT
goodleaf <[EMAIL PROTECTED]> wrote:
: Apologies for off-topic post. <sycophant>But the people on this list have
: the highest average competence I know of--mailing list wise.</sycophant>
: How secure is a pkzipped file that has been zipped with a password? My
: company is considering exchanging data, possibly sensitive, with another
: company who wants to "encrypt" by pkzipping to a password. Isn't the
: algorithm for pkzip too well known to be secure?
: I think they want to use it because they can easily call it from a command
: line; they batch data from their dbase and ship it out to us. They don't
: like human intervention, and pkzip works with batch files. Does PGP (Yes,
: we would pay for appropriate licenses.) have a similar capability?
: Any thoughts are appreciated. I'm relatively new even to thinking about
: security, and here I am having to make a decision about it. I love the
: corporate life.
This question would be more fully answered in sci.crypt, and I recommend
that you post it there. But from my readings in sci.crypt, I have come
to the conclusion that password security in pkzipped files is, for all
practical purposes, nonexistant.
It isn't because the algorithm is well known, either; many very secure
cryptosystems use well known algorithms. It's simply that the algorithm
used by pkzip is very weak.
(followups redirected to sci.crypt)
--
Life is complicated, but winter narrows it down to a few simple problems: heat,
food, shelter, plumbing. And it focuses you in wonderful ways. You don't have
to search for your personal identity in winter; winter gives it to you. You are
prey in winter; nature is making a serious attempt to kill you. - GK/PHC
------------------------------
From: [EMAIL PROTECTED] (Mike Mccarty Sr)
Subject: Re: Universal Language
Date: 16 Mar 2000 22:22:59 GMT
The answer is "yes, but don't ask me to give you an example, it's been
too long!" IIRC, the vocative for god is BOGA while the nominative is
BOG. (Hopefully obvious transliteration being used.)
Mike
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
)[EMAIL PROTECTED] wrote:
)>
)> Richard Herring wrote:
)> >...
)> > Are there *any* instances where the vocative can be distinguished
)> > from the nominative, or is it just a grammarians' invention?
)> > Richard Herring | <[EMAIL PROTECTED]>
)>
)> I dont know Russian that good, but in Latvian there is
)> difference between nominative and vocative
)
)Yes, but that doesn't help, because Latvian is a very
)different language...
)
)It's been a long time. I believe the answer to the question is
)"yes -- but not all that many cases". The same, FWIW, applies
)to Latin, which is generally thought of as having 5 cases but
)the correct answer there is 6 for the same reason (vocative).
)
) paul
)--
)!-----------------------------------------------------------------------
)! Paul Koning, NI1D, D-20853
)! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
)! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
)! email: [EMAIL PROTECTED]
)! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
)!-----------------------------------------------------------------------
)! "A system of licensing and registration is the perfect device to deny
)! gun ownership to the bourgeoisie."
)! -- Vladimir Ilyich Lenin
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Kosherising
Date: Thu, 16 Mar 2000 18:00:09 -0500
==============F581CCB9A3C8CB824F5D00C5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
O.k., I have the answer. It was the FIPS pub 186 report (but I
don't think they explicitly used the verb kosherising).
You guys can stop with the jokes now.....
Anton Stiglic wrote:
> Does someone have a ref on Kosherising primes, where
> was it introduced?
>
> I need it for a bib.
>
> Thanks!
>
> Anton
--
___________________________________________
Anton Stiglic
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________
==============F581CCB9A3C8CB824F5D00C5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
O.k., I have the answer. It was the FIPS pub 186 report (but I
<br>don't think they explicitly used the verb kosherising).
<p>You guys can stop with the jokes now.....
<br>
<p>Anton Stiglic wrote:
<blockquote TYPE=CITE>Does someone have a ref on Kosherising primes, where
<br>was it introduced?
<p>I need it for a bib.
<p>Thanks!
<p>Anton</blockquote>
<pre>--
___________________________________________
Anton Stiglic <[EMAIL PROTECTED]>
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________</pre>
</html>
==============F581CCB9A3C8CB824F5D00C5==
------------------------------
From: [EMAIL PROTECTED] (Impervious)
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 23:10:04 GMT
On Thu, 16 Mar 2000 10:34:41 -0000, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
Thanks for all the info guys, the only thing I'm fuzzy on is this:
>In order to eliminate the attackable data more easily you
>may want to pull a few hundred initial bytes out before
>performing the encryption, 512 is a common (and fairly good)
>number.
I don't understand where to drop the bytes from... Can I just generate
an 80 character salt and then drop the first 40 characters before
encrypting for example?
Many Thanks,
Manuel Alvarez
------------------------------
From: "Scotty" <[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: Thu, 16 Mar 2000 20:35:18 -0000
Withheld wrote in message ...
>[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]
>
No, if you know the pattern used to overwrite its quite easy to 'peel' it
off.
See the following paper for a detailed discussion of recovery and overwrite
techniques:
http://www.cs.auckland.ac.nz/~pgut001/secure_del.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 16 Mar 2000 16:51:25 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>Unfortunately, the problem of hidden malicious code is not prevented
>by having one cipher and then never changing it, since in that case
>users are locked into whatever funnyness happens to be there already.
No, it isn't. But the problem is made more complex, if the idea is to
make it relatively easy to accept cipher modules from a variety of
suppliers.
And institutions that deal with the public might need to use a wide
variety of cipher modules to be able to establish a connection with
clients with different cryptographic tastes. (If, instead, we have a
situation with only a few ciphers being _de facto_ standards, isn't a
big portion of the rationale for multi-ciphering being lost? I'm
assuming you are proposing significantly more than a hot-swap
capability.)
>First, we have no idea what the probability of AES weakness really is.
>Without knowing that probability, we cannot compare it to some other
>probability and say it "pales in comparison." So there is no
>comparison here, no reasoning, no science, just your opinion expressed
>in a different way.
We do know how easy it is to penetrate systems using malicious code,
and how difficult it is to protect against that.
If breaking the AES were *that* easy, we _would_ have to "rethink the
very nature of ciphering".
Also, this statement certainly _sounds_ like "since the AES isn't
provably strong, it might be terribly weak", which is why people turn
around and say that multi-ciphering, not being provably strong either,
has the same problem. Unless this is all an argument about who should
bear the burden of proof, you will need stronger evidence of a
probability that the AES may be weak to get people to take the extra
effort that multi-ciphering involves.
>And the argument itself is yet another continuation of "if it won't
>solve everything, it's useless." No, multiciphering does not solve
>everything. But it does improve the unknown ciphering strength
>problem, which is a fundamental, scientific crypto problem. Yes,
>implementation problems will still exist. And cipher program
>authentication problems will still exist. But the problem of unknown
>cipher strength can be brought under our control. "We have the
>technology."
The problem is, instead, that if it doesn't address what people are
worried about, it is likely to be greeted with a yawn. (Yes, under
some circumstances, that's merely an argument for only solving
fashionable problems.)
And if it seems like it will worsen the risk of attacks that people
are familiar with, that are typically carried out by amateurs instead
of three-letter agencies, that are known from experience to be a real
hazard, it will definitely recieve limited consideration.
Whether or not these implementation issues are "killers" depends
strongly on the intended area to which multi-ciphering is to be
applied. For something like PGP, they wouldn't be serious problems;
but to guard the "infrastructure of our society", they are very
serious.
If one is going to integrate multi-ciphering into web browsers that
run on existing computers, something like P-code _will_ be needed,
since in that context, no other technical solution is available at
present, and achieving the required level of trust to operate without
a technical solution is not practical.
Multi-ciphering of a limited kind - using a fixed set of ciphers in a
product designed entirely by a single vendor - certainly could be used
for things like bank-to-bank communications, because that wouldn't
create security problems not present in the status quo (aside from
more lines of code = more bugs, which would be minor for that
situation). But to get the full benefits, such as an open-ended choice
of ciphers, and a vigorous marketplace in cipher module designs, and
to have it applicable to at least most low-bandwidth uses of
cryptography, then the computer security issues have to be confronted.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 23:30:30 GMT
On Thu, 16 Mar 2000 23:10:04 GMT, [EMAIL PROTECTED] (Impervious)
wrote:
>On Thu, 16 Mar 2000 10:34:41 -0000, "Joseph Ashwood"
><[EMAIL PROTECTED]> wrote:
>
>Thanks for all the info guys, the only thing I'm fuzzy on is this:
>
>>In order to eliminate the attackable data more easily you
>>may want to pull a few hundred initial bytes out before
>>performing the encryption, 512 is a common (and fairly good)
>>number.
>
>I don't understand where to drop the bytes from... Can I just generate
>an 80 character salt and then drop the first 40 characters before
>encrypting for example?
Different issues, salt and pulling extra bytes. The suggestion has to
do with RC4 and not the salt.
The suggestion is that you pretend encrypt or decrypt so many bytes of
ether, before beginning encryption or decryption of your data. The
reason is that the RC4 algorithm has been shown to have some
weaknesses in its key preparation routine. This action stirs up the
key state to get past that weakness.
------------------------------
** 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
******************************
