Cryptography-Digest Digest #228, Volume #12 Sat, 15 Jul 00 08:13:00 EDT
Contents:
SECURITY CLEAN freeware text editor in win95 ? (jungle)
Re: what is the symmetric algorithm for protection of classified info by gov
agencies ? ("Scott Fluhrer")
Re: Has RSADSI Lost their mind? (Greg)
Re: what is the symmetric algorithm for protection of classified info by (jungle)
Re: Idea for CFB-like cipher (Mack)
Re: Win2000 Encryption (Mack)
Re: what is the symmetric algorithm for protection of classified info by gov
agencies ? (Jerry Coffin)
Re: what is the symmetric algorithm for protection of classified info by gov (Paul
Rubin)
Re: I need a rough estimate. (Mok-Kong Shen)
Re: On intermixing as encryption processing (Mok-Kong Shen)
Re: what is the symmetric algorithm for protection of classified info by (jungle)
Re: what is the symmetric algorithm for protection of classified info by gov (Simon
Johnson)
Discreate logrithms in GF(p) (Simon Johnson)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: Discreate logrithms in GF(p) (Scott Contini)
Re: Quantum Computing (Was: Newbie question about factoring) (Nick Maclaren)
Re: Defeating the RIP bill (phil hunt)
----------------------------------------------------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: SECURITY CLEAN freeware text editor in win95 ?
Date: Sat, 15 Jul 2000 01:02:22 -0400
most of the programs are very smelly & dirty ...
any help for freeware in win95 :
SECURITY CLEAN text editor [ like NOTEPAD ] that can be used to edit
up to 1 MB files ?
SECURITY CLEAN =
- no temp files
[ permanent or / and intermittent = deleted after program closed ]
- no entries in registry
- no windows folder messing
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by gov
agencies ?
Date: Fri, 14 Jul 2000 22:12:16 -0700
jungle <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> FIPS 46-2, The Data Encryption Standard (DES), is the approved symmetric
> algorithm for protection of sensitive but unclassified information by
> government agencies.
>
> what is the symmetric algorithm for protection of classified info by gov
> agencies ?
>
I'm pretty sure that information is classified...
--
poncho
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Sat, 15 Jul 2000 05:33:27 GMT
When RSADSI told us the $70k up front and 6% gross royalties (IIRC), we
decided to do our own crypto. We have RC6 available, but if we ever
have a client who asks for it, then we will begin negotiating with
RSA. Until then, we don't use it in our product.
Our strategy with RC6 is that it might become AES and then we can
use it for free, so we made a place at our table for RC6 ahead of
time. We are deploying Blowfish and Twofish right now with an ECC
that I wrote and a pretty neat protocol to rotate ciphers and keys
using the padding of the cipher buffers.
I don't want to bad mouth RSADSI. They are a formidable work of
art in marketing and you have to respect that. But there is some
information from the makers of Blowfish that present a clear
challenge to RSADSI's claims on RSA itself. You should go visit
their web site and check out their challenge. See it at:
http://www.cyberlaw.com/rsa.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by
Date: Sat, 15 Jul 2000 01:41:01 -0400
which is paraphrase of "I don't know." ?
Scott Fluhrer wrote:
>
> jungle <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > FIPS 46-2, The Data Encryption Standard (DES), is the approved symmetric
> > algorithm for protection of sensitive but unclassified information by
> > government agencies.
> >
> > what is the symmetric algorithm for protection of classified info by gov
> > agencies ?
> >
> I'm pretty sure that information is classified...
which is paraphrase of "I don't know." ?
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Idea for CFB-like cipher
Date: 15 Jul 2000 06:11:59 GMT
In a message dated 7/14/00 10:52:33 PM Central Daylight Time,
[EMAIL PROTECTED] writes:
> Mack wrote:
> [snip]
> >
> > The MDC-MD5 use the same method but with MD5 as the
> > hash function.
> >
> > This is also similar in structure to the SCOTT ciphers
> > as well as my X8 series which is based on the same idea.
>
> What are the SCOTT ciphers? Ciphers by SCOTT19U.ZIP_GUY?
Yes ...
>
> Where can I find your X8 series?
>
It is available at www.cryptography.org under file encryption as x8.zip.
> >
> > Only those ciphers use a truly shuffled lookup table rather than
> > a computed function and have multiple rounds of chaining.
> The problem with using a truly shuffled array, rather than one with
> array[i] != i for all i, is that it's possible for array[0] to be 0,
> which would mean, that with probability 1/256, a string of 0's in the
> plaintext will become a string of 0's in the ciphertext. If a modified
> array is used, then a repeated byte in plaintext will be a random string
> the ciphertext. Repeated bytes in the ciphertext *can* occur, but will
> decrypt to a random-looking string of plaintext.
>
At the time I was experimenting with the idea and did not consider
this however a new cipher which I have worked on (about two years old)
checks that array[array[0]]!=0 and swaps this element until this condition
holds.
> > M8 the only secure (so far 3 years) variant of the X8 series
> > also adds a round key at the begining of each block and uses a
> > modified chaining method.
>
> When you say round key, would the equivilant for my H be: in the place
> where I have 'out' initialized to 0, it would be initialized by some
> psuedo-random, key-dependant value? This would, I suppose, eliminate
> the problem of a repeated byte in input becoming a repeated byte in
> output, maybe even better than my modifying the shuffling of the
> key-array. It occurs to me, though, that using a simple 8 bit counter
> here would work nearly as well.
yes it would be similar to initializing out to some value. not precisely
but similarly. It does prevent a repeated byte of input from becoming a
repeated byte of output. Since M8 uses multiple rounds the propagation
eliminates patterns fairly quickly.
>
> What kind of "modified chaining method" do you use? Different from
> mine, I suppose, but different how?
>
RS8 used CBC in the same manner. IS8 used a non-linear chaining
function with c[n]=(p[n]^c[n-1])+p[n+1] where c[-1]=p[max] and p[max+1]=c[0]
M8 used PCBC with special handling of the first two bytes.
Note that RS8 and IS8 are NOT SECURE due to the lack of round keys.
Both could be modified by simply using the M8 round keys and adding them
to P[0] and P[1] at each stage. This should make them secure for sufficient
rounds.
An additional note on the security of M8. I currently recommend using
a minimum of 9 rounds rather than 6. Also I recommend that the number
of rounds be increased for increasing block sizes.
> > >The H I would use is more-or-less grabbed from lja1:
> > >
> > >/* K is the key, in is the input, N in the size */
> > >/* K is a shuffled array 0..255, which has been */
> > >/* changed so that for all i, K[i] != i */
> > >char H(char *K, char *in, int N) {
> > > int i, out;
> > > for( i = out = 0; i < N; ++i )
> > > out = key[out+key[in[i]]];
> > > return (char)out;
> > >}
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Win2000 Encryption
Date: 15 Jul 2000 06:19:31 GMT
Greg [EMAIL PROTECTED] wrote:
>I tried out the Win2000 encryption property on a file and found that
>the file does not appear to be encrypted even though the attribute
>says it is.
Transperent decryption in the file system.
>
>And what is more odd is that there is no password provided to me.
Should be the same as the password for your user name.
>
>Can anyone explain what is happening? Do I need to install some
>software component to make this work or am I doing something wrong?
>
Have you tried booting from linux or some other OS and accessing
the same file? Possibly with a disk editor from DOS?
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by gov
agencies ?
Date: Sat, 15 Jul 2000 00:59:06 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> FIPS 46-2, The Data Encryption Standard (DES), is the approved symmetric
> algorithm for protection of sensitive but unclassified information by
> government agencies.
>
> what is the symmetric algorithm for protection of classified info by gov
> agencies ?
There is not simply one algorithm for protection of all classified
data, or anywhere close to it.
About the only dependable source of specific information about a
specific encryption algorithm is going to be direct from the NSA
when/if they believe you need to know about it.
If you want general information about how the NSA designs ciphers,
consider looking at SkipJack. Though _it's_ not approved for
classified data, I'd almost bet that they have similar ciphers that
are, adjusted (larger key, larger S-boxes, more rounds, etc.) to
provide the level of security they consider necessary.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by gov
Date: 15 Jul 2000 07:26:17 GMT
In article <[EMAIL PROTECTED]>, jungle <[EMAIL PROTECTED]> wrote:
>FIPS 46-2, The Data Encryption Standard (DES), is the approved symmetric
>algorithm for protection of sensitive but unclassified information by
>government agencies.
>
>what is the symmetric algorithm for protection of classified info by gov
>agencies ?
If they told you, they'd have to kill you.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: I need a rough estimate.
Date: Sat, 15 Jul 2000 11:04:00 +0200
Simon Johnson wrote:
> And the euler Phi-function is?
This is explained in all textbooks on elementary number theory. You
have to be familiar with that anyway, if you have need to operate with
primitive elements. See also the book of Knuth, vol. 2.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On intermixing as encryption processing
Date: Sat, 15 Jul 2000 11:04:08 +0200
David Hopwood wrote:
> Mok-Kong Shen wrote:
> > David Hopwood wrote:
> > > Mok-Kong Shen wrote:
> [...]
> > > > That is, we intermix the bits of the two given streams in
> > > > such a manner that the resulting bits have equal chance of
> > > > being originated from the one stream or the other.
> > > >
> > > > Obviously this materially enhances the difficulty of the
> > > > opponent,
> > >
> > > I don't see that this is obvious at all; it depends how the input
> > > bit streams can be attacked. If either of the two mixed streams are
> > > biased, for example, then the output will also be biased. As a method
> > > of combining three (including r()) possibly-random bitstreams in order
> > > to produce a hopefully stronger bitstream, I don't see that this method
> > > is very efficient or effective.
> > >
> > > > since he has to identify (guess) which bits of
> > > > u_i belong to the first stream and which to the second.
> > >
> > > That may or may not be true.
> >
> > The processing here introduced is not stand-alone but is a step
> > supplementary to an encryption algorithm and enhances its strength.
>
> I don't think you've established that it does enhance the strength.
> I described a case in which it doesn't, and you haven't provided any
> specific response to that. In any case, even where it does increase
> the strength, it isn't a very efficient method of doing so compared
> to, say, using one cipher and increasing the number of rounds.
You only mentioned the general situation that the streams to be mixed
are biased. (Well, these can indeed never be perfect in practice, right?)
But, firstly, they are outputs of presumably not too bad block ciphers,
so the bias should be small. Secondly, even if with relatively large bias,
we know from classical cryptography that it takes some non-trivial
techniques and effort to work on the result of a polyalphabetical
substitution through exploiting the freqeuncy characteristics. (Note
here we are not working on the character level as in the old times
but on the finer bit level.) If one takes sometime to try to device
a method to exploit the frequency characteristics of the bits of the
u_i sequence, I suppose that the difficulty should be apparent.
(Note that all bits are alike. The task is not like separating out a
heap of mixture of grains of different sizes.)
The efficiency issue is another matter. It has always been raised in
such connections. Here my standard opinions: One never gets
anything useful for free. If one already has a system that (one believes)
is secure enough, then one needs nothing more (including the
supplementary measure presented here) and it would indeed be
irrational to look for add-ons. Otherwise, any means of improvement
may be worthy of consideration. Such means may not be economically
justified in some enviroments but in others, depending on constraints
actually present and objective and non-objective factors. Last but not
least, having a larger repertoire of encryption processing methods is
an essential advantage by virtue of the variability one has in a game
that one plays with the opponent. (This certainly can never convince
those who believe that there is, or will shortly be, one single block
cipher that is most efficient and secure for all applications of the world
for all times.)
> > That mixing something together (in other context) renders the
> > separating the stuffs out rather difficult is a common experience
> > and should be intuitively clear.
>
> No, it isn't clear, nor is it true in general. For the above
> technique, all you can say in general is that the mixed sequence
> is no weaker (in the sense of indistinguishability from a random
> sequence), than the *weakest* of the input sequences c1 and c2.
Certainly I can't give you a (mathematical) formal proof. It appeals
to your intuition and common sense/experience to accept my
scheme. Look at the somewhat analogous case of transposition in
classical cryptography. All the characters of the plaintext are there
but only in a different order and one has difficulties to put these in the
original order. Such difficulty is certainly not insurmountable, but it
is some, isn't it? Yes, if you consider constructed pathological cases,
e.g. if one stream consists of all 1's, then your conclusion could be
right. But I am targeting at practical situations and not establishing
theorems.
BTW, I purposedly left out a point in the original article because I
think that it is not relevant to the main issue and would distract the
reader. In the first described scheme, the order of c1_i and c2_i
bits remain unchanged in the resulting u_i sequence. But we could
certainly at this opportunity do a little bit additional work to disturb
that order somewhat. Normally the inputs are delivered in computer
words of n bits. We can rotate these words by pseudo-randomly
determined amounts before feeding them to our scheme.
Finally, I like to say that the flexibility of choosing the value of the
probability t is a feature that one may find to be quite useful. The
implementation I mentioned can be found on my webpage under
the name WEAK4-EX.
M. K. Shen
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: what is the symmetric algorithm for protection of classified info by
Date: Sat, 15 Jul 2000 06:18:52 -0400
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>, jungle <[EMAIL PROTECTED]> wrote:
> >FIPS 46-2, The Data Encryption Standard (DES), is the approved symmetric
> >algorithm for protection of sensitive but unclassified information by
> >government agencies.
> >
> >what is the symmetric algorithm for protection of classified info by gov
> >agencies ?
>
> If they told you, they'd have to kill you.
the encryption software is allocated into lev 1, therefore tell / kill option
is not applicable ...
------------------------------
Subject: Re: what is the symmetric algorithm for protection of classified info by gov
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 15 Jul 2000 03:18:55 -0700
I agree with the people above........
There will be various different algorithms for various levels of
security. Precisely how these algorithms consist of is probably
classified (i'd say that probable with 99.9% certainty.)
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Discreate logrithms in GF(p)
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 15 Jul 2000 03:31:18 -0700
Is there a techique for z, if x, y, p are known:
x = y^z mod p.
n.b. p is a prime.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
from: [EMAIL PROTECTED]
reply-to: [EMAIL PROTECTED]
Date: 15 Jul 2000 10:41:46 GMT
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Discreate logrithms in GF(p)
Date: 15 Jul 2000 11:42:25 GMT
In article <[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
>Is there a techique for z, if x, y, p are known:
>
>x = y^z mod p.
>
>n.b. p is a prime.
>
>
The best method known is the number field sieve.
For a survey of algorithms, see:
"Discrete Logarithms: the Effectiveness of the Index Calculus Method"
by Schirokauer, Weber, and Denny
which seems to be on this web site:
http://www.informatik.tu-darmstadt.de/TI/Veroeffentlichung/reports/README.year.author.html
Scott
------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Crossposted-To: comp.theory
Subject: Re: Quantum Computing (Was: Newbie question about factoring)
Date: 15 Jul 2000 11:42:37 GMT
In article <8kob9r$ruh$[EMAIL PROTECTED]>,
Jeffrey Shallit <[EMAIL PROTECTED]> wrote:
>In article <8kg1gj$5mk$[EMAIL PROTECTED]>,
>
>Maclaren is wrong because he misunderstands the model used to generate
>real numbers with a finite automaton that Warnock is referring to. In this
>model, the finite automaton is equipped with an output function for each
>state, say from Q (the state set) to {0, 1, ..., b-1} for some integer
>b >= 2. We say such a machine generates the real number
> . a_0 a_1 a_2 ... in base b
>if, when fed with the base-k expansion of i, the machine reaches a state
>q whose output is a_i.
>
>Under this model, it is easy to create finite automata to generate
>transcendental numbers. For example, a 2-state machine can
>generate the Thue-Morse real number
> .0110100110010110 ...
>whose i'th bit is the sum (mod 2) of the bits in the binary expansion of i.
>This number is known to be transcendental; Dekking proved this some
>time ago (although his published proof has an flaw that can be repaired).
Oh, hell, OF COURSE a finite automaton can generate such things if
you allow it to be fed an infinite input tape or use an infinite
working tape (in the Turing model)! There are lots of other similar
models, such as the one where the input is a true random sequence of
bits. That can clearly generate the expansion of ANY real number,
provided that you don't want any particular one :-)
However, whether you can call such a thing "a finite state machine"
is more debatable ....
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: Defeating the RIP bill
Date: Sat, 15 Jul 2000 02:03:40 +0100
Reply-To: [EMAIL PROTECTED]
On Fri, 14 Jul 2000 20:53:44 GMT, Kad <[EMAIL PROTECTED]> wrote:
>I just thought I would make a suggestion as to how easy it is
>to write a crypto program which makes the RIP bill the lame duck
>it already is. For those not aquainted with it's many provisions
>one of them is that it requires a user with encrypted files on there
>system to provide the decryption key for that data. Of course this
>provision can only work if it is known that there is encryted data
>files on the computer hd .It is not very easy to hide encryted data itself
>but it is very easy to hide the number of encrypted data files if all encryted
>files are mingled together in one large file block.This one large file is set aside
>at the first running of the crypto software and always kept full of random numbers
>( setting aside 500-1000 meg of file space to hold all ones future encryted files
>even though you may only require a few meg may seem wastefull but considering the
>size of todays hd which is fastly approaching 1Tb this is peanuts) .All encrypted
>data is then stored within this one file under one or as many passwords as the user
>requires.Thus you can have as many layers of security as required with less sensitve
>stuff being stored under one password and more sensitive material being accesed
> with a higher level password/s if required.The important thing here is that It is
>impossible for the attacker to know how many layers of security or how many files
>are stored within the single set size crypto block. Any average user of such sofware
>(doesn't know or care about underlying working's of crypto software) would be well
>within there right's to declare there is no other encrypted files (after being
>forced to disclose password ) within the cryto block, the onus would then be on the
>courts to prove that there where more layered files within the crypto block
>(impossible).
What a clever idea.
I wonder if anyone's thought of implementing something like that :-)
(You might want to look at the current thread "Steganographic encryption
system" which describes my stes program).
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
** 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
******************************
