Cryptography-Digest Digest #169, Volume #11 Sun, 20 Feb 00 16:13:01 EST
Contents:
Re: Question about OTPs (Arthur Dardia)
Re: Processor speeds. (Wesley Horton)
Re: OAP-L3 Encryption Software - Complete Help Files at web site (Chuck)
Re: NSA Linux and the GPL (Vernon Schryver)
Re: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP (David A.
Wagner)
Re: Question about OTPs (Jim)
Re: Question about OTPs (Jim)
Re: Question about OTPs (Jim)
Beginner Help ? ("Norman Little")
Re: NIST publishes AES source code on web (John Savard)
Re: NSA Linux and the GPL (John Savard)
Re: OAP-L3 Encryption Software - Complete Help Files at web site ("Joseph Ashwood")
Re: NIST publishes AES source code on web (Mok-Kong Shen)
Re: NIST publishes AES source code on web (Mok-Kong Shen)
Re: Beginner Help ? (John Savard)
----------------------------------------------------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Sun, 20 Feb 2000 11:31:19 -0500
"Douglas A. Gwyn" wrote:
> Arthur Dardia wrote:
> > I still say make a recording of what happens outside the window by your
> > computer and mix that with your swap file (which should be really, really
> > random - unless I'm mistaken), in addition to recording timings between
> > keypresses, etc.
>
> None of those are very "random", so combining them won't
> produce a very random bit stream.
>
> > Does it make sense that the more stupid stuff you include,
> > the more random your data will become, or ...
>
> That depends. Why not just use a hardware random bit generator?
>
> > Also, when combining multiple sources of data, should you conectate the two
> > files or data, or should you xor them together or perform some other operation
> > on them. Xoring the two would yield as much data as the bigger file holds,
> > but conectating the two files would give you more data. Which is better,
> > assuming you don't really need that much data...
>
> Obviously, concatenation does not improve the "randomness"
> of the bits of the sources. XORing might help, but only
> under some circumstances.
>
> It appears to me that you're tackling a bigger problem
> than you are currently equipped to solve. That is
> usually a mistake..
I don't have a problem I'm trying to solve, I'm just trying to learn about OTPs. I
wanted to write a program tht would keep track of the starting/ending offsets you
used in your OTP so you don't reuse any part of the pad file; however, it turns out
it was already written, but it's shareware. :(
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Wesley Horton <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Processor speeds.
Date: Sun, 20 Feb 2000 11:23:52 -0600
You know the computing power issue is really getting moot when there was
a Cray X/MP on ebay last week that went for $14.59 (plus shipping.) ;)
Regards,
Wesley Horton
------------------------------
From: Chuck <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Sun, 20 Feb 2000 09:26:45 -0600
On Sat, 19 Feb 2000 04:49:56 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>No one has been able to or capable of or willing to address the
>primary issue here in this news group: is the theory and operation
>of OAP-L3 credible for its intended purpose?
The people in this group aren't experienced cryptologists. They would
be fools to trust your algorithm just because it "seems good" to them.
In the privacy and encryption communities, an algorithm or
implementation is considered guilty until proven innocent. Many a
clever algorithm that was "mathematically proven" by its designer to
be unbreakable has quickly fallen when analyzed by the world's leading
codebreakers. I remember reading in some encryption book that 95% of
the algorithms submitted for consideration fall just on initial
inspection alone. Of all the algorithms subjected to rigorous analysis
over the past 15 years, there are fewer than ten survivors that are
trusted well enough by governments to be used in military and
spy-vs-spy communications.
The people who do these analyses are very busy and you're not the one
paying them. They owe you nothing, yet your algorithm will not be
accepted until they've seen fit to spend their precious time attacking
it. It's up to you to figure out how to get them interested.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: NSA Linux and the GPL
Date: 20 Feb 2000 10:25:17 -0700
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> ...
>Doubtless, one could add a sort of MLS to Linux with a few changes to
>the kernel - add a security level attribute to each file, keep track
>of when a file is "contaminated" by being written to by a program that
>also read from one of a higher security level - but the ordinary
>security mechanisms that keep users from reading each other's files in
>Linux or other ordinary operating systems probably aren't strong
>enough to make that more than pretending to provide MLS.
HAH! Those views are similar to what the secure UNIX managers and
salescritters say, but I think they have as much connection with
reality as the sales talk of the artificial intelligence advocates
of the 1980's. The standard spiel is "we just need to change a
few things, since the standard UNIX model is insecure."
As a senior kernel/networking hack at my previous UNIX vendor employer,
I watched about 10 years of efforts to add and maintain MAC (mandatory
access controls) and other stuff to a system based on System V and 4.*BSD
to pass the TSIG certifications. In my view, the result was no more
secure than standard UNIX. The government reviews found none of the
root exploits and other problems reported to CERT, bugtrack, and
elsewhwere. The "trusted unix" group found a few holes, but none compared
to the number found by customers and the rest of us. In at least the
early years you could configure the system with a magic password that
turned off all of the nosense. While dealing with problems in one of
those places without outside network connections, where outsiders have
an armed companion when they visit the toilet, and where you can bring
media in but absolutely never remove it, I saw that feature used a lot
by the customer. It was present, because otherwise necessary system
maintenance was too much hassle.
Much worse than that feature, about every 100 lines of the kernel and
every command that root might use (not only SUID=0) were touched.
Never mind about covert channels, just dealing with the explicit ways
in which information can be passed around requires changes everywhere.
There are so many changes and they're so repetitive and boring, so
that they don't get done by the strongest programmers, or with any
thinking attention to each change. Changes to the rest of the system
by the rest of the company were continually stepping on the "trusted"
stuff, and vice versa, and that was in a company where the "trusted"
group was originally sold by a VP as a way "to get engineering under
control." Keeping so called real security in a live freeware effort
like {Free,Net}BSD or Linux would be incredibly funny and silly.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP
Date: 20 Feb 2000 09:42:06 -0800
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> Best I've heard for factoring is square root improvement [...]
Well, probably the single most famous result in the field is Shor's
algorithm that does factoring and discrete log in quantum-poly time.
That's much more than square-root improvement.
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Question about OTPs
Date: Sun, 20 Feb 2000 18:26:12 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 19 Feb 2000 12:41:02 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]>
wrote:
>Computer implemented OTP encryption is available at
>http://www.ciphile.com
>
>If you want to use your own true random numbers instead of the
>random number files generated by the software, basically all you
>have to do is organize the OTP files using the necessary file
>format which only requires:
>
>a naming convention such as, F0000001, F0000002, F0000003, etc.
>for each consecutive OTP file;
>
>and each file must be the same length.
>
>The software will keep track of which OTP file you are currently
>using and where to offset it. When the file has been used once
>completely it is overwritten and deleted. Then the next file is
>used. If this file is not used up completely a pointer file is
>created that records the offset so the next time you encrypt a
>message it will begin using the OTP where you just left off. Etc.
I'd prefer it to delete key as it is used.
Is this system exportable?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Question about OTPs
Date: Sun, 20 Feb 2000 18:26:14 GMT
Reply-To: [EMAIL PROTECTED]
On 20 Feb 2000 04:37:11 GMT, [EMAIL PROTECTED] (ChenNelson) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Actually, in my lab class I think I've stumbled across a very
>efficient way of generating a OTP. Take an oscilloscope, hook it to an
>A/D board on the computer, and have the oscilloscope record noise.
>Then, for all voltages >0 output a 1, and all voltages <0 record a 0
>(or the other way around). Have the sample rate fast enough to be
>efficient, but not too fast to preserve randomness (must statistically
>test here, better to sample slower and be surer).
How do you make a 'scope record noise?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Question about OTPs
Date: Sun, 20 Feb 2000 18:26:16 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 20 Feb 2000 10:30:25 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>ChenNelson wrote:
>> Actually, in my lab class I think I've stumbled across a very
>> efficient way of generating a OTP. Take an oscilloscope, hook it to an
>> A/D board on the computer, and have the oscilloscope record noise.
>> Then, for all voltages >0 output a 1, and all voltages <0 record a 0
>> (or the other way around). ...
>
>Where is the source of that "noise"? I bet there is a substantial
>component at 60Hz (in the US, 50Hz in Europe).
Eggsackly! Better to use FM radio or TV noise.
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: "Norman Little" <[EMAIL PROTECTED]>
Subject: Beginner Help ?
Date: Sun, 20 Feb 2000 18:58:27 -0000
Hi,
I have undertaken a cryptography assignment for my final year at University.
The plan is to write JAVA applets that "demonstrate" the various encryption
algorithms. This has varied from the very old ciphers such as caesar,
playfair, and vigenere....etc and now I am moving onto DES and RSA etc.
The problem is, the books I am reading on DES, they explain the algorithms
in terms of dividing the plaintext into 8-bit blocks. The reduced block
size is to help understand the algorithm. Anyway, what I would like to
know, is if anyone can help me how to split my plaintext up into 8-bit
blocks or whatever, or even if there is a way for me to demonstrate this by
dividing the message into characters.....
I am not sure how I would divide my message in the way the book details....
thanks
Norman
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST publishes AES source code on web
Date: Sun, 20 Feb 2000 18:58:39 GMT
On Sun, 20 Feb 2000 10:32:04 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>John Savard wrote:
>> ... I am somewhat puzzled by that comment.
>I'm sorry you're puzzled, but it directly addressed the point
>raised in the message to which it was a response.
Oh, I liked the post: but applying the adjective "thankfully" to a
statement that the U.S. hasn't ratified a treaty that would obligate
it only to do much less than it already voluntarily does in the way of
export control was the one thing that puzzled me.
Perhaps either I'm missing some restrictions in Wassenaar that are not
in force under U.S. law, or you are thankful that the U.S. has the
power to change its mind in the future.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA Linux and the GPL
Date: Sun, 20 Feb 2000 18:56:11 GMT
On 20 Feb 2000 10:25:17 -0700, [EMAIL PROTECTED] (Vernon
Schryver) wrote, in part:
>In article <[EMAIL PROTECTED]>,
>John Savard <[EMAIL PROTECTED]> wrote:
>>but the ordinary
>>security mechanisms that keep users from reading each other's files in
>>Linux or other ordinary operating systems probably aren't strong
>>enough to make that more than pretending to provide MLS.
>HAH! Those views are similar to what the secure UNIX managers and
>salescritters say, but I think they have as much connection with
>reality as the sales talk of the artificial intelligence advocates
>of the 1980's.
Although I thank you for an interesting and informative post, I
thought it was clear in my post that, while I noted that one could
attempt to add MLS to Linux, I didn't think the result would provide
real security either.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Sun, 20 Feb 2000 12:19:18 -0000
Crossposted-To: talk.politics.crypto,alt.privacy
[snip stuff I'm not replying to]
> Support your conclusion with fact-based logic citing the
theory and
> operation of the OAP-L3 encryption software package as
presented in
> the Help files available at http://www.ciphile.com
[snip other stuff I'm not replying to]
Well, let's do it this way.
On your claim of originality:
Your random number generator may or may not be original, but
you use of XOR is certainly not, I hereby propose renaming
this cipher to YEST, Yet Another Stream Cipher. Of course if
you don't use XOR, then your comparison to OTP is likely to
fail on more levels.
On your naming:
You claim absolute privacy, yet even OTP does not gaurentee
that, just that the plaintext cannot be found.
On your comparison to OTP:
OTP offers absolute secrecy, it is impossible to determine
the contained information without already knowing it. It
also requires true random numbers, something which you have
yourself admitted your program does not offer.
On your use of permutations of base 10:
You severely limit the possibilities for keys, even if you
were to limit against having the same base 10 digit repeated
immediately your security could potentially rise a
significant amount.
Any questions?
Joe
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Sun, 20 Feb 2000 21:26:47 +0100
Brian Gladman wrote:
>
> The Wassenaar Arrangement (WA) is no more than an informal agreement and
> this means that the extent to which national laws implement its provisions
> is highly variable since there is a legal obligation on any of its
> participants to do anything.
What is your definition of 'informal' where high government offcials
from ministries signed for their respective countries? It is known
that the agreement has to be ratified. But is that the 'characteristic'
that led you to consider that the agreement is 'informal'? (Even
a peace treaty ending a war needs ratification, if I don't err.)
>
> The US has generally gone way beyond what is required and recent changes
> have simply bought US regulations somewhat closer to its provisions.
>
> Many other countries do not implement any restrictions on commercial
> cryptographic products because the WA does not require this. In practice
> only a few countries now intepret the crypto controls in Wassenaar as having
> any impact on such products. There are token restrictions on export to
> 'naughty countries' but everyone involved knows that these are of little
> practical value.
Could you please cite the text of Wassenaar Agreement that exempts
'commercial products' from its crypto restrictions?
Your sentence 'The US has generally gone way beyond what is required'
is indeed interesting. The US seems to do that in one AND also the
other direction. Previously it posed in its own territories
crypto restrictions much more severe than what the other countries
were ready to pose. Now that there are, after much lobbying, finally
crypto clauses of the Wassenaar Agreement (US was the main pushing
force in that!), the US, for reasons (in my view) not very apparent
(or convincing) to the outside world, suddenly wanted to relax the
restrictions and, according to an official document quoted in this
thread, even now permits strong crypto of 128 and 256 key bits
freely accessible from terrorist countries, which is certainly
contrary to the spirit of the Wassenaar Agreement.
>
> Of course it is important to remember that Wassenaar is about much more than
> cryptography since its real purpose is to stop the spread of military
> weapons, especially those of mass destruction. The danger in the crypto
> debate has always been that the crypto restrictions that the US has
> attempted to justfy by quoting the WA would bring it into disrepute and
> hence undermine its real purpose in making the world a safer place.
>
> Sadly, as we are now seeing on the Internet, crypto restrictions have had
> exactly the opposite effect. They have been kept in place because of hidden
> agendas that are now (partly) out in the open for all to see.
In one particular sense I would say that 'fortunately' we are now
seeing on the internet that crypto restrictions have had exactly the
opposite effect. Through the discussions in internet groups on the
topic, more people are becoming aware of the ineffectiveness and
hence (among other reasons) the nonsense of crypto restrictions,
in particular key-escrow. Further, more people become interested (as
a result of the publicity of the topic) in the field of crypto
and this tends in the long term to accelerate the progress of this
subfield of science and, as a consequence, there will be more strong
crypto products available to the public than in the case if there
were no crypto restriction issue at all on the internet or in the
other public media.
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Sun, 20 Feb 2000 21:26:54 +0100
John Savard wrote:
>
> <[EMAIL PROTECTED]> wrote, in part:
>
> >I must logically conclude that AES is
> >in fact NOT a strong crypto.
>
> Actually, although that might seem like a sensible conclusion to make
> at first glance, it is a sufficiently unlikely conclusion that I think
> one must take the time to consider other alternatives.
Yes. I was expressing with a bit of sacarsm.
> The AES algorithms have been freely published worldwide.
>
> Even in Cuba, North Korea, Libya, and so on, there are people who know
> how to program computers. Sure, crypto algorithms are finicky, but
> they're really not all that hard to program.
>
> Thus, if subroutines that perform strong symmetric crypto algorithms
> are really a worry for the NSA, their worries are profoundly perverse
> and irrational.
>
> The alternative is that they're worried about something *else*.
>
> That there is a certain class of cryptographic program that would be a
> serious concern to the NSA were it to become commonly available...but
> the NSA can't say in public exactly what that class consists of, as
> doing so would
>
> a) just encourage somebody to write one, and
>
> b) give away some inside knowledge about the real world of crypto.
You have given an extremely interesting viewpoint. This is certainly
also in conformity with the fact that governments (plural) don't seem
to like to see advancements of the science of cryptology in the
public (i.e. excepting advancements in their own three-lettered
agencies). Cf. the history (in the sixties, if I remember correctly)
that crypto publications should be suppressed or (as is later
implemented) the manuscripts are subject to voluntary presentation
by the journal editors to the authorities for prior 'review'.
We can't know the 'certain class' you mentioned. More exactly, we
will never 'know' whether certain stuff belong to that class, even
in case we possess some solid scientific knowldege of that stuff.
But, as I also mentioned in another follow-up, internet discussion
groups have contributed (in non-trivial ways) to the advancement of
cryptology and there is some real good chance that part of the
matters being discussed in our group indeed belong to that 'certain
class' (by chance or not).
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Beginner Help ?
Date: Sun, 20 Feb 2000 20:12:48 GMT
On Sun, 20 Feb 2000 18:58:27 -0000, "Norman Little"
<[EMAIL PROTECTED]> wrote, in part:
>The problem is, the books I am reading on DES, they explain the algorithms
>in terms of dividing the plaintext into 8-bit blocks. The reduced block
>size is to help understand the algorithm. Anyway, what I would like to
>know, is if anyone can help me how to split my plaintext up into 8-bit
>blocks or whatever, or even if there is a way for me to demonstrate this by
>dividing the message into characters.....
>I am not sure how I would divide my message in the way the book details....
Your question is somewhat puzzling.
In order to divide your plaintext into blocks of eight bits, it first
has to be composed of bits. If you represent the characters of your
message, assuming it is a text message, using either ASCII or EBCDIC,
the result will already be in groups of eight bits, since that is the
size of a character in those codes (although ASCII can also be thought
of as a 7-bit code).
------------------------------
** 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
******************************
