Cryptography-Digest Digest #635, Volume #9 Tue, 1 Jun 99 23:13:03 EDT
Contents:
Re: Viability of encrypted flash cards? ("Cor!")
Re: Obscure Code (Y. Oakmerlin)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Question about Cryptography/Encryption... (SCOTT19U.ZIP_GUY)
Re: The BRUCE SCHNEIER Tirade (SCOTT19U.ZIP_GUY)
Re: Question about Cryptography/Encryption... (JUzarek)
Re: Viability of encrypted flash cards? (Boris Kazak)
----------------------------------------------------------------------------
Reply-To: "Cor!" <in the newsgroup. Unless it's important. PGPkeys:
http://get.to/the.cor.website/>
From: "Cor!" <[EMAIL PROTECTED]>
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: Wed, 02 Jun 1999 01:03:44 GMT
If such a system became widely available, then I guess it would be used
by criminals more than anyone else (ie. peadophiles, Chinese workers at
Los Alamos, etc.).
--
Cor!™
>[EMAIL PROTECTED] wrote:
>>
>> 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] (Y. Oakmerlin)
Subject: Re: Obscure Code
Date: Wed, 02 Jun 1999 00:44:48 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>... many who look at it (Scott's code) get very
>confused and they think it is obscure.
That's pretty much the dictionary definition of "obscure", Scott.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Wed, 02 Jun 1999 02:17:42 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>------------------------------------------------------------------------
> **** Some Background info for Newbies ****
>------------------------------------------------------------------------
>
>David A Scott released an algorithm
>he called scott19u.zip. He has made many
>claims about the security his algorithm
>offers.
>
>However after being available for
>quite some time now, no-one has yet shown
>it to be insecure. Paul Onions did show
>a known plaintext attack (I don't know the
>details), but David modified his algorithm
>to avoid this attack.
>
>Usually, if an algorithm has not been broken
>for a couple of years, then people start to consider
>it to be secure. However, this is not the case
>with the scott19u.zip algorithm.
>
>Why's that ? Well, no accurate concise
>descrption of the algorithm has been provided
>by the designer. He claims the source code
>is there and this is the best description that anyone
>could possibly have. If you think he may have a
>point here, it's a fair bet you haven't
>looked at the source code he provides.
>
>Judging by the posts to this group I am
>not the only one that would like to have
>a go at breaking scott19u.zip, however,
>every body has been severely hampered by
>source code that is not human readable (even
>for programmers) and the lack of a clear, accurate
>description.
>
>So here's where the challenge comes in .......
>
>------------------------------------------------------------------
> ******* THE CHALLENGE ******
>------------------------------------------------------------------
>
>David, if you think the algorithm is as secure
>as you claim, then take the following challenge.....
>
>Rewrite the source code in a form that is
>easily readable by humans. Use descriptive variable
>names, avoid macros, etc..
I can't use long names. I actaully bent over backwards to
use long names. At work the only time I could use long names
was to name varibles after people I know. I worked on a quaterion
update for a interial navagation system one time and they begged
for long names. If you ever see the term "directional analog scaler"
I made it up. Some one asked a few years later where I got the math
for it. I said I made it up look at the initials. Again i like x y z for
variables. I can't speel consistantly enough to write like words.
At work I have had to debug look programs one of the first things i do
is change the varibles to shorter names so I can look at code and get
the stupid words out of the way. It would not be possible to use more
descriptive varables. I wish you knew my former bosses they would back
up this claim.
>
>Take a few days to write an accraute, concise
>descrption of the algorithm that can be used by
>those who have no programming background to
>have a go at analysing it.
I am writting in straight C no GNU or DJGPP or endian stuff
a wrapper program for "wrapped PCBC" so any one can use
it I think this will go a long way to anwsering any questions
it will be as short a listing as possible.
>
>Make the source and the description
>available as a single download, so that
>people can read them offline.
>
>The description can
>be in any format as long as most people are likely
>to have software to view it (postscript, html, word,
>pdf, wordpad, or any other popular format).
>
>Please also include clear, tidy diagrams.
>
>----------------------------------------------------------------------------
>
>If you take this challenge seriously, and your algorithm
>isn't cracked in the next few months, then others
>may start to have some confidence in your algorithm and
>possibly even take it seriously.
>
>As it is, it's a fair bet that you are the only one thats
>currently using it.
>
No I have had letters from people as far away as germany
thanking me for this product so some people are using it
but I think they are keep a low profile.
>Please respond to this post with a post confirming
>if you accept this challenge or not.
>
>If you don't accept it, please, calmly give your reasons for
>all to read.
>
>- Tim
I can't rewrite it easily but wait till you see the easy to use
wrapper code. It will be written for understanding not for efficency
and will have no macros.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Question about Cryptography/Encryption...
Date: Wed, 02 Jun 1999 02:00:22 GMT
In article <[EMAIL PROTECTED]>, Nicholas Zacca <[EMAIL PROTECTED]> 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! :)
>
>Nick
Take a look at my site you can get the C code from some pointers
and it is made for a PC.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Wed, 02 Jun 1999 01:56:35 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>I didn't mean they would be forced to, but you cliam your encryption
>product to be the best around and anyone with a need for security, who
>has any sense, should be using it, but what I suggest is as follows.
>The practical proplems of using scott19u.zip are similar if not
>identical to the problems of using a OTP, and therefore if someone
>finds a practical use for scott19u.zip then they would be better
>off going for the proven OTP.
I think you are being mislead in that you feel one needs to use
the long key feature. You could in theory use almost any file as
the source of keyenc.key And then use a short phrase of 128 bits
or whatever your heart desires. It is just that you don't have to
use a short key of less than a thousand bits unless you really
have your heart set on it.
>
>>>Any way, isn't the maximum key length of SCOTT19u.zip the
>>>same as the maximum file length it can encrypt ?
>>
>> Tim no the maximun length is a function of your virtual memory. On
>>a 4 meg machine I have encrypted files 8 megs in lenght
>>
>
>My mistake, I trawlled through the source for half an hour to confirm
>this.
>
>Please, please, please, please, please, please, please can you release
>
>a tidied up version of the source that can be easily read by a human -
>
>at the very least use descriptive variable names - these are tokenized
>
>by the compiler so long names won't affect the running of your
>program, but it will make the source a heck of a lot easier to read.
>
I plan on releasing a more complicated version but still waiting for
the price of a k6-3 machine to drop in price. Then I will have more
time. I think you may be getting lost in the menu section which I admit
is very poor. But the method really is in the last four subroutines
>
>The macros used for the 19bit access also make it extremly hard
>to read, but add nothing to security - the NSA, MI6 , DFS, and other
>gourps (only joking on the DFS one before any complains) would give
>new recruits the task of 'deciphering' your source and then
>it would probably only take a few days to crack your algorithm
>(Yes - that is my opinion based solely on the fact that you, the
>designer, couldn't accurately determine the
>effective key length of your own algorithm)
>
It took a long time to develop those macros I had many more but the
compiler barfed when the level got deeper. The macros were meant to
make it easier in the main program since they hanfle most of the problems
of 19bit access on a machine that really was made to do 8 16 or 32 bits.
>>>
>>>In effect, if you want to use SCOTT19U.zip at it's
>>>maximum strength, then you have all the problems of a OTP, ie a huge
>>>key that needs securely transmitting, storing or remembering,
>>>with the added bonus of *provably* less security.
>>>
>>
>> Actally if you want to use it at full strength the keyenc.key file is
>>a little over one meg in size. however there are many ways to send
>>portions of text that can be use for the key. But as other methods
>>you still would need some sort of key sequence to use to unlock the
>>key. IF it becomes comprimised you need a new key.
>> But it is not a OTP you can use the same key several times
>>so don't confuse the two.
>>
>
>Every time you reuse a key, you double the amount of information
>that an attacker has as to the value of the key. With all your
>paranoia over security, million bit keys, etc, I would have thought
>that reusing a key would be the last thing you would do.
Well you thought wrong however in the next version I may have the ability
of a changing key each time 2 people exchange messages the key they use
would change. I feel this is an important feature that is lacking. It also
makes it such that if the NSA or other group was saving your old encrypted
messages then even you would not be able to recover the previous keys.
>
>As far as I can tell, but for the reasons mentioned above - ie
>hard to read source code, I can't be sure, I think that the
>main security of scott19u.zip lies in substituting from the
>key dependant S-Box.
The reason the Key is so long is that I wanted the ability for
any single cycle S-table to be used. However I am writting and
will put out a program that allows one using AES or IDEA or
what ever and still be able to use "wrapped PCBC" however
using this chaining will require for 3 rounds that the block cipher
be exercised 3 times as much. But it will allow one to easly
create an all or nothing encryption that matches the input
file in length and only full blocks will be encrypted no padding
of any kind is needed.
>
>Apologies, I didn't state it very clearly, I meant encrypting single
>files on a hard disk, as opposed to email where there is a sender /
>receiver.
>
I use it for files I like to zip files up and then encrypt them
>Becasue of the size of the key, it is not possible to memorize it, so
>some means of securely storing it is necessary. most people
>have only small amounts of information that needs really securely
>storing (ie their bank details, medical records, emails etc, in which
>case if they have a way of securely storing the scott19u.zip key, then
>why not just use that means to store the data they need securing.
>
Well you can use any size you want so it is as easy to rember
as anything else.
>
>Also,long keys, while offering potentially high security (dependant of
>course on many other factors), have to be stored somewhere.
>They are then vulnerable to searches by police with search warrants,
>MI6 etc sneaking into your house etc. While 128bits might not offer
>huge security (dependant on your opinion) they are at least
>memorizable and if handled properly, ie not written down, they are
>secure from search warrants, intruders etc.
use a 128bit key as your password to some other file which you copy
to keyenc.key when you run the program no problem.
>
>I'm writing this offline, because phonecalls in the UK are charged
>on a time basis, and I can't afford to spend a longtime online
>searching deja news for bits and pieces of useful information
>buried deep within your usual rantings. If you separated
>your posts into two sections, a facts section and a rants and
>raves section, it would help ..... well, it's just a suggestion....
>
good idea
>If you think people should use your algorithm then you should give
>them all the information they need, whenever they ask for it nad
>even when they don't -but only if it's genuine.
>There could be some newbie reading this now that is thinking
>of seriously using scott19u.zip .........deep breath.......and they
>may need to know these things, who hasn't had the luxury
>of past posts, and who is also in the same position as me and
>many others in the UK over phone call charges.
>
look at the web pages horst wrote at my site
>Don't worry, I'm not using it, I'm just looking forward to the day
>that someone actually manages to 'decipher' your source code
>and show that it is less secure than blowfish........ I believe it's
>only a matter of time, that time period being determined by how
>soon you *********stand up to the challenge******* and
>provide clear easily readable source code, (with the exception
>of yourself, not one person that I know of has had any positive
>comments to say about the readability of your source code by humans),
>or .....better still.... provide a clear concise description of the
>algorithm (ignore file handling and any other parts not directly
>related to cryptography), in such a way the somebody could implement
>the algorithm itself in their own apps.
I hope that some one writes it in a way you can see it.
>
>Oh well........ heres to dreaming ....... I'm sure all these things
>have been requested before.........well.... if you're too scared to
>rise to the challenge .........thought so ........ carry on handwaving
>and insulting all those that are trying to help you.
>
I can;t write sorry my friend
>> And as you know every day on this form I jump to say hay this is a good
>>place to use it. So don't act dumb I am not going to type pages and pages
>>of stuff
>>
>
>Please remind me of those places ......I haven't got time to go
>through your past posts to extract them.
>
>
>- Tim.
>
>
Tim I never even saved the comments they are a one time thing even the
comments you wrote on enctropy have given me more ideas for the next version
but i never saved your comments after I verifed you calculated it correctly
and came up with a way to increasce the entropy.
I also don't have a printer so I have never seen the source of scott19u.c
other than on a CRT
Hamilton is the only one I know of that keeps tracks of posts maybe he could
help but I doubt if he would he seems to act as if he has a bug up his ass.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (JUzarek)
Subject: Re: Question about Cryptography/Encryption...
Date: 2 Jun 1999 01:51:34 GMT
>In article <[EMAIL PROTECTED]>, Nicholas Zacca <[EMAIL PROTECTED]>
>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.
David Khan's "The Codebreakers" covers the history of codes and ciphers .
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: Tue, 01 Jun 1999 19:30:47 -0400
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> (*********)
> "Oops I forgot the passphrase."
>
"Sorry, my friend, we have no reason to keep you here
any more... Jonny, use this chunk of meat to feed
the sharks..."
RIP and best wishes
------------------------------
** 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
******************************
