Cryptography-Digest Digest #633, Volume #9 Tue, 1 Jun 99 18:13:04 EDT
Contents:
Re: The BRUCE SCHNEIER Tirade ([EMAIL PROTECTED])
Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
([EMAIL PROTECTED])
Re: Please recommend freeware encryption SDK ([EMAIL PROTECTED])
Re: Question about Cryptography/Encryption... (DJohn37050)
definition of public domain (Greg Bartels)
Re: Obscure Code (wtshaw)
Re: 576-bit blowfish?! (John Myre)
Re: The BRUCE SCHNEIER Tirade ("Nick Barron")
Re: P3 and OTP (John Savard)
Re: OTP Problems (Matthias Bruestle)
Re: Question about Cryptography/Encryption... (Sundial Services)
bareface ratio (Greg Bartels)
Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1) (Sundial Services)
Re: Reasons for controlling encryption (Paul Koning)
Re: The BRUCE SCHNEIER Tirade (Patrick Juola)
----------------------------------------------------------------------------
Date: Tue, 01 Jun 1999 04:11:42 -0400
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
John Savard wrote:
>
> [EMAIL PROTECTED] wrote, in part:
>
> >I agree that PK methods are not particularly useful for for data
> >storage. However, I do not see the conclusion that a one-time pad is
> >inappropriate as obvious.
>
> >If we view individual sectors or clusters of the storage device as
> >independent messages, then we'd have to consume a section of the pad on
> >each write to the device. However, if we view the entire device as a
> >message, we only "use" the pad when an adversary has access to it. Thus
> >we could use a pad exactly as large as the storage device and ignore the
> >fact that individual sectors/clusters/files were rewritten. (I consider
> >these operations as edits to a "draft" message).
>
> >Can you amplify your statement with the reasoning behind it?
>
> I suppose a person could, say, when he is away for the weekend, apply
> OTP to his hard drive, taking the key with him on a removable medium.
>
> But it would probably be more useful in that case to take the data
> with him, and just wipe the drive.
Yes.
Consider, the NEC case though. My information is anecdotal only, but it
appears to be a reasonable threat. The coporate headquarters in
Boxboro, Massachsetts sutains a burglary in which five machines are
stolen. Two of the machines contain the just-completed five-year
strategic plan. The company has to scrap the plan and come up with a
new one. The cost was some period of time in which to proeuce the new
plan, and the disclosure of the interests and corporate priorities that
coul be obtained by reading betweent he lines of the original plan; such
interests and priorities not being easily changed. The burglary was
never solved AFAIK.
If the machines had volatile images of an OTP and persistent images of
the encrypted information, the act of stealing the machines would have
wiped the keys due to lack of power. The information would have been
safe. An inadvertent power outage long enough to deplete any backup
power would be recoverable because the key could be retrieved from an
offsite vault.
Note that a compay is Merrimack, New Hampshire recently had an attack
that started with power cut off. The burglars killed power to the
entire building at 04:00 Saturday of last Easter weekend. They waited
for the backup power on the security system to run down (6-8 hours), and
entered the building that afternoon.
The reason this kind of thing appears in the adventure novels is that it
happens all the time in the real world.
I grant that any kind of real encryption (as opposed to access
passwords) would have been vastly better than none in the NEC case. Yet
against an adversary capable of coporate espionage at the level of a
megacorp either has or can hire serious crypto tools and toolsmiths.
Thus if they had used DES, they'd probably been forced to make the same
adjustments to their plans because it would not have been safe to assume
the data were still secure.
Provable security would have produced a different result. I'd like to
explore the cirsumstances in which it might make sense rather than
simply assume it never makes sense.
There appear to be two fundamental issues with OTPs used for data
storage. 1) it's a silly idea because there are better answers, and 2)
it doesn't work for technical reasons (several kinds of strawmen).
>
> Normally, however, memorizing a short passphrase is not only vastly
> more convenient, it solves the problem that there is a long key
> kicking around - which must be kept secure, and yet it has to be
> accessible whenever the data is to be used.
>
> For communications, it's clear that you can have a case where someone
> can intercept your communications who has no opportunity to break in
> to your computer room and steal a key.
>
> John Savard ( teneerf<- )
> http://members.xoom.com/quadibloc/index.html
------------------------------
Date: Tue, 01 Jun 1999 04:17:59 -0400
From: [EMAIL PROTECTED]
Subject: Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
Michael J. Fromberger wrote:
>
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nogami) writes:
>
> >If the software can't stand up to in-depth analysis by professionals,
> >it's completely worthless as an encryption scheme.
>
> >This is why all of the commonly recognized encryption software
> >packages, such as PGP, Bestcrypt, scramdisk, etc. use public
> >encryption algorithms. While you certainly don't have to release ALL
> >of your code, you should be releasing the part of the code that
> >actually does the encryption.
>
> Actually, I'd argue that ALL the code for any serious encryption
> package should be released. Most failed cryptosystems fall not to
> esoteric cryptanalytic attacks on the ciphers themselves, but to
> protocol and implementation failures in how the ciphers are used.
> Certainly, it is important that your implementation of the cipher
> itself should be correct -- but that is hardly the entire picture.
>
> Just as ciphers themselves need to be reviewed and attacked openly in
> order to test their strength, so too should the software that uses
> these ciphers in a particular context. After all, in a real security
> situation, the first thing your opponents are going to try is to
> exploit weaknesses in the way you use your encryption tools.
>
> If you're going up against a government, that probably includes
> attacking the ciphers you use ... but why should anyone waste time and
> money trying to crack a strong published cipher, if they can recover
> your cryptographic keys out of a preference file, or take advantage of
> a weakness in your encryption mode, or any number of other common
> attacks. Thus, being able to review the rest of the code is at least
> as important -- if not more so -- than reviewing the ciphers
> themselves.
>
> Cryptography is no place for secrecy ... an ironic axiom, to be sure,
> but true.
Do you believ thn that the United States would be better off in terms of
communication security if the NSA/CIA/FBI/DIA/TLA published all of their
working methods?
I think not.
>
> Cheers,
> -M
>
> --
> Michael J. Fromberger Software Engineer, Thayer School of Engineering
> sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
> Mp/8iFe3es7ycyzY8saI8mJI+TMcPxaY+4JFcOf+ximcYBCdQ87W0Sla7NDY9JGVWRe5dz8/
> Remove clothing if you wish to reply to this message via e-mail.
------------------------------
Date: Tue, 01 Jun 1999 04:26:11 -0400
From: [EMAIL PROTECTED]
Subject: Re: Please recommend freeware encryption SDK
Greg Bartels wrote:
>
> FYI (and slightly off-topic)
>
> just read a book called "Open Sources" by O'Reilly this weekend
> (highly recommended reading for anyone in computers)
If the following definitions are representative of the book, the book is
garbage.
>
> freeware is generally considered an out-of-date term, with no copyright
> backing. it is used to refer to several different types of copyrights,
> which have some pretty big differences, such as public domain,
> gnu public licence, and open-source
No. Freeware typically is distributed with out any form of compensation
(shareware is supposed to be compensated). But it is copyrighted.
>
> public domain, as a legal term, means that the software has
> no copyright, and someone can take public domain software, put their
> proprietary copyright on it, and remove it from the public domain.
No. Once in the public domain, it cannot be removed. Derived works can
be copyrighted, but the ownership interests acrues only tot he new
paterial. The original and and included parts thereof are still in the
public domain.
>
> gnu public license, guarntees that the software will be available
> as source code, that works derived from GPL must itself be GPL'ed
> (the copyright is viral).
>
> open source definition, defines what terms must be met by a copyright
> or licence to qualify as open source. it requires that source code
> be available. it does not require that derived works be open source as
> well.
>
> none of these require that the code be available for no money.
Freeware implies it. Public domain implies it.
>
> interesting book.
Who published this junk?
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Question about Cryptography/Encryption...
Date: 1 Jun 1999 20:39:04 GMT
Info on asymmetric crypto is on IEEE P1363 web site, use any search engine to
find it. Look for ballot version of P1363.
Don Johnson
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: definition of public domain
Date: Tue, 01 Jun 1999 15:50:12 -0400
the following definition is taken from
O'Reilly's book, "Open Sources"
(asterisks added by me.)
Public Domain
A common misconception is that much free software
is public-domain. This happens simply because the
idea of free software or Open Source is confusing
to many people, and they mistakenly describe these
programs as public-domain because that's the closest
concept that they understand. The programs, however,
are clearly copyrighted and covered by a license,
just a license that gives people more rights
than they are used to.
A public-domain program is one upon which the author
has deliberately surrendered his copyright rights.
It can't really be said to come with a license; it's
your personal property to use as you see fit.
Because you can treat it as your personal property,
you can do what you want with a public-domain program.
You can even re-license a public-domain program,
removing that version from the public domain, or
you can remove the author's name and treat it as
your own work.
If you are doing a lot of work on a public-domain
program, consider applying your own copyright to
the program and re-licensing it. For example, if
you don't want a third party to make their own
modifications that they then keep private, apply
the GPL or a similar license to your version of
the program. ***The version that you started with will
still be in the public domain, but your version will
be under a license that others must heed if they use
it or derive from it.***
You can easily take a public-domain program private,
by declaring a copyright and applying your own license
to it or simply declaring "All Rights Reserved."
John Callender wrote:
>
> Greg Bartels <[EMAIL PROTECTED]> wrote:
>
> > As it happend, I was at the bookstore
> > this weekend, browsing for a copy of
> > "The Mythical Man-Month" when I happened
> > across an O'Reilly book with the title
> > "Open Sources", with a big sticker
> > saying it was a "New Release".
>
> > if it isn't a book for everyone on this list,
> > it is at the very least a book anyone should
> > read before evangilizing for or against
> > open source.
>
> The full book is now available online, by the way. See:
>
> http://www.oreilly.com/catalog/opensources/book/toc.html
>
> --
> John Callender
> [EMAIL PROTECTED]
> http://www.west.net/~jbc/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Obscure Code
Date: Tue, 01 Jun 1999 15:07:06 -0600
In article <7j1aia$pjh$[EMAIL PROTECTED]>, "Oliver J. Hanau"
<[EMAIL PROTECTED]> wrote:
>
> As this is for an important side-note of a li'l thesis I'm putting
> together, I'd prefer a off-line sources (book/magazine).
>
The trouble is that you are more apt to get the actual information you
want online. Because of the nature of the information you request, it is
not apt to be main-street published. Online references and email can be
footnoted.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: 576-bit blowfish?!
Date: Tue, 01 Jun 1999 14:45:26 -0600
Matthew Bennett wrote:
>
> Just to test, I tried using a key longer than 56 characters in my blowfish
> implementation written C (my key is stored as an unsigned char). After
> increasing the defined maximum key length in the blowfish header file, I
> found I could get a different cipher-text output from changing any one of up
> to ~72~ characters in my key. For example, using a 100-byte key, changing
> only any of the last 27 characters of this key had no effect on the cipher
> output.
>
> So it seemed a maximum of 72 characters were being "used" - unlike the 56 it
> is supposed to be? This effect was seen in two separate blowfish source
> codes.
>
> Could someone point out to me where I've gone wrong :)
>
> /\/\/\//
I don't think there is anything wrong with your implementation,
at least not just because up to 72 bytes of key affect the
result. Indeed, it should work that way; the initialization
procedure starts by XOR'ing key material with the P array,
which is 18 words of 32 bits (i.e., 72 (8 bit) bytes).
The idea of restricting the key to 56 bytes is that the bytes
after that are not considered to be sufficiently diffused into
the Blowfish state. In other words, a smart cryptographer
might be able to deduce information about those last 16 bytes
(57 through 72) using appropriate cryptanalysis tools. Then
if the user is actually using a passphrase (not, say 72 bytes
of really random bits), knowing those last 16 characters
might be sufficient clue to guess the rest. Imagine, for
example, someone choosing a line from a movie...
Of course, I haven't detailed exactly *how* the cryptanalysis
would work. Someone smarter than me (or more motivated) might
be tempted to try that. Schneier's paper describing Blowfish
(I found it somewhere at http://www.counterpane.com) states
that "the ... limit on the key size ensures that every bit
of every subkey depends on every bit of the key," where "key"
refers to the 56-byte (or 72-byte, if you wish) input key,
and "subkey" refers to each of the words in the P and S
arrays (i.e., the internal Blowfish state). I didn't see
anything more specific in terms of an attack on key bytes
after 56 in that paper, but there are other interesting
details on the design rationale.
So the bottom line is this: keys up to 72 bytes work perfectly
well, but there is a potential security weakness in using keys
longer than 56 bytes. Of course, in most situations 56 bytes
of key would be adequate.
John M.
------------------------------
From: [EMAIL PROTECTED] ("Nick Barron")
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Tue, 1 Jun 1999 21:23:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (fungus) wrote:
> A one time pad has a key which is a big as the message. If you
> can securely transmit the key to the other party then you obviously
> don't need cryptography - you could just send the message by the
> same route.
Not quite true. First, the key must also be *random*. Secondly, the key
could be exchanged in advance, in the knowledge that at some future time
you will need to transmit a secret message. This is exactly how hardcopy
one time pads are used.
However, I would agree that for most practical applications OTPs aren't
realistic.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: P3 and OTP
Date: Tue, 01 Jun 1999 21:05:45 GMT
Greg Bartels <[EMAIL PROTECTED]> wrote, in part:
>two thousand dollars will get you a
>1) pentium III with random bit generator
>2) a DVD burner, and a lot of spare disks.
Actually, the P3 doesn't generate random bits - that generator is in a
support chip. And how to use it is being kept secret by Intel for the
time being.
>but if you just want to
>keep secret the email that you send to a friend
>of yours, then OTP is the way to go.
Other, more convenient methods, are also fully adequate for that
purpose. However, it _is_ true that it's hard to tell which of those
methods are good, and which ones are snake oil. Since the OTP is
provably secure, and easy to understand, when secure physical contact
is reasonably convenient, there is something to recommend it.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: OTP Problems
Date: Tue, 1 Jun 1999 21:33:45 GMT
Mahlzeit
[EMAIL PROTECTED] wrote:
> Matthias Bruestle wrote:
> > [EMAIL PROTECTED] wrote:
> > > A case in point. I'm pretty impressed with the specs of the iButton
> > > device. The current (initial) version stores about 2^10 bits in a
> > > physical device that is reasonably easy to deal with, yet is probably
> > > secure against anything less than "national technical means". Certainly
> >
> > I doubt it can withstand a skillfull student. (See papers of Kuhn&Anderson)
> Can you provide a pointer to a repository containing the referenced
> papers?
About attacks on smart cards:
http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
http://www.cl.cam.ac.uk/~mgk25/tamper.html
http://www.cl.cam.ac.uk/~mgk25/tamper2.pdf
About data retention in RAM, which is probably relevant for the iButton:
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Schnittchen-Schneider mit den elastischen Beilen
------------------------------
Date: Tue, 01 Jun 1999 14:40:51 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Question about Cryptography/Encryption...
Nicholas Zacca wrote:
>
> Hi. I'm a high school student looking for information about cryptography
> and software encryption. I'm doing a project on this topic and have been
> searching the web for information on the history behind encryption (ie.
> what was the first encryption? what came after that, etc. ) but I have
> come up short. I keep finding pages on encryption programs and
> algorithms but those really don't help me. :( Can anyone point me in
> the right direction of a good web site/book/resource/company I could
> contact, anything that would assist me with my topic? thanks for your
> help! :)
Fair warning, Nick... this subject is addictive! :-)
"The Bible" on this subject is David Kahn's work, "The Codebreakers,"
which is one of the most complete and authoritative works ever written
on the subject. Many later books are an obvious take-off on Kahn.
A more recent book that might be more approachable is Fred Wrixon's
book, "Codes, Ciphers, and Other Crypto and Clandestine Communication"
(ISBN 1-57912-040-7), which is also very thick but for a different
reason: it is set in very large type with wide margins, the very
opposite of Kahn. It appears to be original material and it covers the
same history but not in as much depth.
There are hundreds of web-pages on cryptography, as you have no-doubt
discovered by now from search engines such as Yahoo!, but many of these
cover only one particular segment of the history, such as World War II
or NATO-era cryptography, or the modern shenanigans of the NSA and GCHQ.
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: bareface ratio
Date: Tue, 01 Jun 1999 16:05:39 -0400
just an interesting phenomenon I've noticed
on newsgroups in general.
bareface ratio:
the number of people who respond
to tell you your information is wrong
versus
the number of people who respond
to your requests for information
on the same topic.
this seems to be about 3 (or more) to 1,
depending on the topic.
so, if you have a question, and no one
is responding, you can still get the
answer, all you have to do is make something
up first (bareface it), and the
corrections will flood in.
Greg
------------------------------
Date: Tue, 01 Jun 1999 14:52:59 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
[EMAIL PROTECTED] wrote:
>
> Michael J. Fromberger wrote:
> > Cryptography is no place for secrecy ... an ironic axiom, to be sure,
> > but true.
>
> Do you believ thn that the United States would be better off in terms of
> communication security if the NSA/CIA/FBI/DIA/TLA published all of their
> working methods?
>
> I think not.
>
> >
> > Cheers,
> > -M
> >
> > --
> > Michael J. Fromberger Software Engineer, Thayer School of Engineering
> > sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
C'mon, Michael... someday you'll encounter a professor who can't exactly
tell you what he's working on or why, and then you'll know where all
schools get their money.
You can be absolutely sure that all of the cryptologic algorithms used
by the "big boys" ARE subject to extensive peer-review.... within their
organizations and by individuals with sufficient security clearances.
This is obviously the world of "the need to know," and it uses its own
communication channels not accessible to the General Public, but the
fundamentals in the classified world must be no different from those in
the domain of the general public.
Persons operating in the classified stratospheres naturally assume that
their enemies, also operating in that sphere, have full knowledge of
their crypto systems and have access to a body of knowledge that is
classified. Even though their world is [supposedly] entirely separate
from ours, the rules of the game are no different.
If you are proposing a cipher algorithm for use in the domain of the
general public, and expecting anyone to trust it, then you MUST be
prepared to supply complete details about the algorithm, to show why it
is resistant to known attacks, and ... to show why it's even likely to
be better than what is already known. You have to expect to be asked to
show why your invention furthers the [unclassified] state of the art.
If it does.
Incidentally... your "8-bit encryption code" might be shown to have
advantages other than pure security. There is definitely a school of
thought which says, "okay, so WHAT if the NSA can break this?" Does
your idea provide certain favorable attributes (faster, smaller, more
error-free, more secure...) better than any other 8-bit cipher currently
known to the unclassified man? If so, let's hear it!
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Tue, 01 Jun 1999 15:35:28 -0400
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Pwrk) writes:
>
> >If you were to ban encryption, shouldn't that include everything that alters
> >information into a form which cannot be read by those not meant to read it?
>
> >Such as the encoding of cable TV so only those with the decoder box can watch
> >it?
>
> >Messages containing credit card info?
>
> You seem to think that the legislators are totally stupid. They would
> simply ban all encryption except... and then write a list of those which
> are OK. They already do that. Read ITAR or the EAR in the USA. Lots is
> exempted from the regulations (including bank transfers, etc)
I don't think so. It's common to say things like "40 bit crypto is
exempt" or "bank applications are exempt" but that's not what the
regulations actually say. Instead, nothing is exempt, but different
uses and different strengths are covered by different sets of rules.
Depending on which set applies to you, the amount of hassle imposed
varies greatly. But if you assume that certain application X isn't
covered, you may be in for an unpleasant surprise.
paul
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: 1 Jun 1999 16:25:45 -0400
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Consider, the NEC case though. My information is anecdotal only, but it
>appears to be a reasonable threat. The coporate headquarters in
>Boxboro, Massachsetts sutains a burglary in which five machines are
>stolen. Two of the machines contain the just-completed five-year
>strategic plan. The company has to scrap the plan and come up with a
>new one. The cost was some period of time in which to proeuce the new
>plan, and the disclosure of the interests and corporate priorities that
>coul be obtained by reading betweent he lines of the original plan; such
>interests and priorities not being easily changed. The burglary was
>never solved AFAIK.
>
>If the machines had volatile images of an OTP and persistent images of
>the encrypted information, the act of stealing the machines would have
>wiped the keys due to lack of power. The information would have been
>safe. An inadvertent power outage long enough to deplete any backup
>power would be recoverable because the key could be retrieved from an
>offsite vault.
On the other hand, they could instead simply have volatile images of
the actual data and an offsite backup.
This requires at least a third less storage (which costs money to buy),
is more error-resistant (there's no risk of, for example, a coding
error or malicious tampering destroying the encrypted data beyond
hope of recovery). and less wasteful of cpu cycles.
So the non-OTP system is simultaneously cheaper, more secure, and
faster. Kinda hard to beat a triple like that.
-kitten
------------------------------
** 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
******************************
