Cryptography-Digest Digest #627, Volume #9 Mon, 31 May 99 16:13:04 EDT
Contents:
Re: 8Bit encryption code. Just try and break it. (Phoenix)
Viability of encrypted flash cards? ([EMAIL PROTECTED])
Re: The paradox of secure key distribution channel (Jim Dunnett)
Re: OTP Problems ([EMAIL PROTECTED])
Re: The BRUCE SCHNEIER Tirade ([EMAIL PROTECTED])
Re: The BRUCE SCHNEIER Tirade ([EMAIL PROTECTED])
Re: HushMail -- Free Secure Email ([EMAIL PROTECTED])
Re: The BRUCE SCHNEIER Tirade ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Phoenix <[EMAIL PROTECTED]>
Subject: Re: 8Bit encryption code. Just try and break it.
Date: Mon, 31 May 1999 11:03:25 -0700
I'll tell you right now I know nothing of encryption as a (science?). I
only know that my VB prog changed text or files into unintelligable
garbage and then ressurects them. Other than that I haven't even read
the entire algorithm. I only program the GUI and other features.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security,talk.politics.crypto
Subject: Viability of encrypted flash cards?
Date: Mon, 31 May 1999 19:04:05 GMT
This message isn't too scientific, but I think the implications could
be pretty broad if it turns out to work.
Newspapers have traditionally considered their sources very saced.
Last month there were some riots at Michigan State University and the
cops wanted access to the papers' camera footage for use in convicting
people. Obviously the papers declined, but a judge forced them to give
their negatives to the cops. This hatched an idea in my mind.
Some of the new digital cameras save their images on a tiny Flash RAM
card. I already know that simple crypto has been implemented on
smart-cards. How feasible would it be to make a RAM card that
automatically encrypts data when it's stored, and forgets the key as
soon as it's removed from the camera? Then only the person who
programmed the key in at first would be able to read the pictures.
Very similar to exposing the film in a regular camera.
As an extension, we need cameras that'll recognize memory devices as
"write only", so that the pictures can't be retrieved even while the
card is still in the camera. The card would implement some form of a
paired-key system so that it couldn't even decrypt its own contents.
Much more secure than the above solution, more secure than traditional
cameras.
Alternately, the crypto could be built into the camera. This would
give such a device an immediate edge in the marketplace, but it'd be
harder to change cryptosystems if one implementation turns out to be
weak.
Thoughts?
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The paradox of secure key distribution channel
Date: Mon, 31 May 1999 18:11:04 GMT
Reply-To: Jim Dunnett
On Mon, 31 May 1999 19:42:04 +0800, Nathan Kennedy <[EMAIL PROTECTED]>
wrote:
>Jim Dunnett wrote:
>> > It might be useful in some narrow applications, like the
>> >Moscow-Washington hotline,
>>
>> Uses one-time-tape I believe. Telegraphic equivalent of
>> an OTP.
>>
>> > spy messages
>>
>> Spies have traditionally relied on OTP.
>
>Does anyone truly believe that US intelligence uses such technology
>anymore? When handheld satellite communications and computers are
>available?
Yes. The CIA has a network of radio stations ('Numbers Stations')
set up around the world which use very old-fashioned letters and
figure codes/ciphers to broadcast to their agents.
So does Mossad, successor to the KGB, and the British
agencies.
>Certainly OTP has been a traditional spy code, used universally. That was
>back when spies couldn't carry around computers and OTP was the simplest,
>securest, most sensible paper-and-pencil code there was for a spy. I doubt
>that the US government uses One-Time-Tape or spies with OTPs except in the
>remotest, primitive and hostile field conditions out there, and probably
>not there either.
I meant 'traditional' to mean more-or-less 'in the past they relied
on OTP' (Read Kahn). But if they're now using mobile phones, the Net,
EMail or whatever, why do we still have these radio stations using
antiquated methods?
--
Regards, Jim. | If you want a picture of the future,
olympus%jimdee.prestel.co.uk | imagine a boot stamping on a human
[EMAIL PROTECTED] | face for ever.
dynastic%cwcom.net |
nordland%lineone.net | - George Orwell 1903-1950.
Pgp key: pgpkeys.mit.edu:11371
------------------------------
Date: Mon, 31 May 1999 03:12:36 -0400
From: [EMAIL PROTECTED]
Subject: Re: OTP Problems
Patrick Juola wrote:
>
> In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >Dan wrote:
> >>
> >> >Wait for the next shipment of key material, or switch to another cipher,
> >> >or reuse portions of the key material in some way (and sacrifice
> >> >unconditional secrecy in the process, if acceptable).
> >>
> >> [snip]
> >>
> >> >This problem can be solved quite easily. (Re)synchronization can be
> >> >achieved by transmitting in the clear the offset of key bits in the
> >> >one-time pad.
> >>
> >> Assuming the following scenario:
> >>
> >> Bob meets Alice once a month and delivers to her a CD-ROM containing
> >> 650MB of randomly generated data. Each time Alice and Bob communicate,
> >> the message of length n is sent, and is prefixed with offset y. Starting
> >> at offset y, using n bytes, the message is decrypted.
> >>
> >> The problems with this are obvious:
> >>
> >> i) Anyone duplicating the CD can read messages
> >
> >Let's see if I understand your point. You are critizing the OTP system
> >because anyone with the proper key can read the messages? Can you
> >describe what is bad about this property?
>
> The fact that the CD is physically persistant; if I can get a copy
> of your CD, I can read everything that has ever been encrypted with
> that CD.
The physical existence is distinct from the continuing utility of the
key.
So the key-security issue becomes one of physical security
> as well as information security -- not only do you need to transmit
> the key securely, but you need to store it securely for a potentially
> unbounded length of time.
These requirement are standard for all keys, not just OTP keys. Given
the exponential increase in data density we can expect the relative
operational costs of the large and small keys to decrease.
If you have to transmit anything securely (meaning out of band) the
incremental cost of the big key (2^20-2^8 bits) is small in comparison
to the overall cost of securing a small key (2^8 bits).
If you have to store anything securely the incremental cost of the extra
2^20-2^8 bits is still small compared to the overall cost of securing a
small key (2^8 bits).
Yes, the costs are higher. Does this increase puch the cost into the
"unusable" category? Sometimes. But less and less often as data
densities increase.
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
it is more secure than the weakest link in any information system with
humans involved.
Now, where do we expect the iButton to be capacity-wise in 10 years? By
standard extrapolation (Moore) we'd be around 2^17 bits. I suspect that
the increase will be much more dramatic in the next couple years and
then level off at around the growth of semiconductor technolocy. So I'd
project around 2^25 - 2^27 bits in 10 years. That's plenty for a month
of email.
If we wanted a larger-capacity device, say 2^32 bits ~ 1 CD, we could
probably build one today. Non-copyable devices have been around for
decades (to defeat reverse engineering).
Lastly, the need to store keys securely is a much smaller problem than
transmitting them securely. The OTP as a transmission mechanism is
easily viable. Complaints about the need to store the key securely
forever are silly because all of the same requirements apply to the
plaintext.
Note that with a multiple-use-key, we have to preserve it during its
lifetime. An OTP key can be destroyed immedidately, and only the
plaintext preserved as necessary.
------------------------------
Date: Mon, 31 May 1999 03:24:00 -0400
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Geoff Thorpe wrote:
>
> Hi,
>
> Anthony Stephen Szopa wrote:
> > I told BRUCE SCHNEIER that any publicity is good publicity and thanked
> > him.
>
> Exactly, publicity. You're hear to sell your software, not to
> "contribute" anything - at least as far as I've seen following your
> posts and the many replies thereof. Under the circumstances I would hope
> you can understand and acknowledge that there is a burden on you higher
> than anyone simply saying "here's some ideas and code I came up with -
> use it or don't, it's like you want" ... you cannot come in advertising
> your "crypto" product on a scientific "crypto" newsgroup and expect to
> play the martyr when people start to poke holes. We don't have to run
> off and research your website before commenting when it seems that the
> thin (and suspicious) descriptions you DO make appear to be wrong by
> definition, rather than interpretation. If you have some info to
> contribute on how your product works, and why it deserves merit (or at
> least non-inflammatory comment) then summarise it, prune out any/all
> hype and anything else not required to illustrate the principles to
> competent cryptographers, and bring it here to be examined.
>
> There are other individuals on the list who seem to proclaim the value
> of their "contributions" and that nobody pays enough attention to them.
> Of course, shortly thereafter somebody actually looks at the thing in
> question and very little remains standing afterward. You seem to want
> commercial interest in what you're offering, but not cryptographic
> attention.
>
> BTW: If you really think "any publicity is good publicity", including a
> respected professional slamming your claims as mere snake-oil, then it
> simply goes to show that you really just want any attention you can get
> and will accept the mathematical side-effect that 1% of that attention
> will spend their money on something they don't comprehend.
>
> > The NSA has visited my web site repeatedly. They are professionals.
> > You can be sure they have a thorough analysis of my encryption method.
>
> So? This means what? Perhaps they'll even grant you an export license?
>
> > And hey, bub, they are not sharing it with any of you.
>
> Why would they - they probably want us to use your software, why would
> they publish anything they might have found? Or they may, in all
> likelihood, consist of cryptographers of the callibre of Bruce Schneier
> who drew much the same conclusion that Bruce did. Once again, please
> remember who you're posting to - and say things that actually have some
> hope of differentiating you from a desperate salesman.
>
> > I pretty much hear nothing but cop-out replies to my posts that avoid
> > the issues, and nearly all fail to demonstrate even the simplest
> > understanding of what I am proposing as a secure encryption method. If
> > none of you are willing to make an intelligent criticism why waste your
> > time. I would think a serious person or professional would have more
> > important things to do.
>
> I've conversely seen plenty of intelligent criticism on what you've
> said, including the original comment from Bruce Schneier that started
> this whole thing off. What I've heard in your defense seems to be more
> ducking and weaving, political-style martyrdom than anything
> cryptographic, scientific, or informative.
>
> Even those here who've in any shape or form begun to "defend" you are
> usually actually just defending that maybe OTPs are sometimes feasible,
> usually with the obvious comment that they're speaking about real OTPs,
> not what you have.
Since I've been advocating the utility of True OTP systems, a comment
may be called for here.
I have not analyzed his software. I do not intend to. It is obvious by
inspection of his comments that his product is garbage.
In the present discussion he has failed to provide the single figure of
merit by which systems such as his might be avaluated: The period of
his keystream generator. We should assume that he has failed to provide
the information not because he is proud of it.
------------------------------
Date: Mon, 31 May 1999 03:46:43 -0400
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Nathan Kennedy wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > John Savard wrote:
> > >
> > > Obviously, though, for something like ScramDisk, neither a one-time
> > > pad nor public key methods make any sense.
> >
> > 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).
>
> Oh come come. You can't possible consider OTP appropriate for fs
> encryption? You'd have to carry around a secret storage medium much larger
> than the storage device you were encrypting, and you'd have to generate
> those massive amounts of bits, and continually destroy and replenish them,
> and keep track of what blocks of key encrypt what blocks of storage, blah
> blah.
Of course. That's why the paragraph prior to yours states that we
ignore the rewrite issue. If you must flame the idea at least take aim
before you cut loose.
That scheme is ludicrous. There are so many places where secret key
> could be lost and this and that, not to mention how SLOW, LIMITED, and
> INCONVENIENT it would be. When I could use a memorizable (with effort)
> password of 128 bits of entropy, or a key diskette or smartcard or ring
> (contents encrypted with weaker passphrase)? Good grief, you must be some
> kind of masochist.
No, I'm discussing a gedanken design. Please address the actual
proposal.
>
> Contrary what you seem to imply, you COULD NOT just use a key as large as
> the device... You couldn't rewrite a sector encrypted with the same key
> sector that the previous version was... you could use the two encrypted
> versions to easily derive both.
Here you are making a false assumption, and, natuarally, reaching a
false conclusion. The threat model is not an adversary watching
everything that passes over the IO channel to the device. The threat
model is someone who obtains an image of the device, probably by theft
or seizure of the physical storage mechanism.
An intermediate threat model might include an adversary obtaining
multiple instances of an image backup or equivalent. But this is a
pretty remote scenario. Given the reliability of modern RAID designs,
daily backups are unnecessary. backups are used to insure against fire
or other site-wide disasters. And the type of information you'd store
on an OTP system is exactly the type that you'd prefer to lose rather
than chance any leaks.
In order to protect against this threat you'd have to use something
other than 1:1 XOR as your fundamental operation. BFD.
OF COURSE it won't be as convenient PGP, PGPdisk, Scramdisk, et al. OF
COURSE it is more hassle than a small-key cipher. But we don't know how
secure small-key ciphers are. We _do_ know how secure an OTP system is
if it is properly implemented. That may be valuable enough in some
circumstances to put up with the hassle.
Point is that the hassle is becoming less cumbersome as time passes and
technology advances.
>
> OTP could work for write once, read once/many mediums or archived data,
> albeit much worse and more inconveniently than traditional symmetric, but
> couldn't possibly be practical for random-access FS encryption.
Here we disagree. Futher comment on your part appears to be pointless.
------------------------------
Date: Mon, 31 May 1999 03:54:10 -0400
From: [EMAIL PROTECTED]
Subject: Re: HushMail -- Free Secure Email
fungus wrote:
>
> Terry Ritter wrote:
> >
> > HushMail does seem to be missing things, including the ability to
> > validate public keys end-to-end,
>
> You *can* view key fingerprints but they're well hidden at the moment.
> I hope they will make this easier.
>
> > and some way to check that the
> > executable applet corresponds to the examined source.
>
> I checked it, and it matches.
>
> What would really be cool would be for the HushMail people to allow
> you to load the applet from your own hard disk. You could maybe set
> this as a preference or something, and the system could adjust their
> CGIs as necessary.
>
> This would also save them a lot of bandwidth. Are you listening,
> Hushmail???
>
> The only downside would be that you would have to manually update
> the applet when the software was updated.
And te update would trigger a need for revrification of the updated
source, and then confirmation that the new executable matched the new
source. Perhaps we need the equivalent of Underwriter's Laboratories
for crypto products. Sounds like an interesting business opportunity.
>
> > Without these features the system cannot reasonably be called secure,
> > so there would seem to be scant reason to really get into the code.
> >
> > As far as I know, none of their technical people are talking about
> > these problems, or what they intend to do about them. It is a beta
> > system, but maybe they are just selling the site as is.
> >
>
> Do you know who the people are? Maybe we could make the two
> suggestions above...
>
> --
> <\___/>
> / O O \
> \_____/ FTB.
------------------------------
Date: Mon, 31 May 1999 03:48:41 -0400
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Nathan Kennedy wrote:
>
> I wrote:
> > OTP could work for write once, read once/many mediums or archived data,
> > albeit much worse and more inconveniently than traditional symmetric, but
> > couldn't possibly be practical for random-access FS encryption.
>
> Actually, scratch that. OTP is worthless for archival purposes. If you
> could securely stow that much key, you could securely stow that much data.
> Unless you wanted to distributed the archive among various untrusted agents
> or locations in fear of one location being discovered to provide a small
> measure of security, tiny compared to a decent symmetric algorithm.
Crap. Storing the plaintext is harder than storing the pad. You can
destroy the pad once you've obtained the plaintext.
------------------------------
** 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
******************************
