Cryptography-Digest Digest #643, Volume #13 Tue, 6 Feb 01 17:13:01 EST
Contents:
Re: Free Encryption Software (Greggy)
Re: Encrypting Predictable Files (Bryan Olson)
Re: Pseudo Random Number Generator (Mok-Kong Shen)
Re: One way function for Passwords. ("Joseph Ashwood")
Re: Free Encryption Software (Greggy)
Re: Free Encryption Software (Greggy)
Re: One way function for Passwords. ("Moritz Voss")
Re: Actually I monitored activities of this NSA�s P1363 Group for many years .....
actually was just around 5 % of my interest in this specific fields .... I have always
liked non-random random number ...I like to use ever changing environment for randomne
("Amaury Jacquot")
Re: Questions about Diffie-Hellman (DJohn37050)
Re: Mod function ([EMAIL PROTECTED])
Re: On combining permutations and substitutions in encryption (Terry Ritter)
Re: Scramdisk, CDR and Win-NT ("Sam Simpson")
DSA flaw - RNG biased (David Crick)
Re: CipherText patent still pending (Bryan Olson)
Re: Encrypting Predictable Files ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Free Encryption Software
Date: Tue, 06 Feb 2001 20:09:31 GMT
In article <#MX$hlxiAHA.273@cpmsnbbsa07>,
"George Peters" <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> An entire suite of encryption applications are available at
> http://www.endecs.com/uenigma.zip . It contains two file systems,
client
> internet email, ftp and point to point communications and some source
code.
> Well worth the download.
>
I just looked at the web page and thought, Why would I want to let you
handle my personal communications? I thought encryption was designed
to keep you from it?
No response is necessary. I merely wished to point out that the idea
is just silly...
> GP
>
>
--
I prefer the fourth amendment over a drug free society.
Did W declare the national emergency over yet and give us
back constitution rule? No? Why am I not surprised?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Tue, 06 Feb 2001 20:13:44 GMT
Paul Housley wrote:
[...]
> There are some parts of the files which are predictable.
[...]
> I am concerned that, by knowing what part of the file is
> supposed to decrypt to, this may help people to find the
> encryption key.
>
> Any advice, particularly concerning the RC4 algorithm?
RC4 is designed to resist known-plaintext attacks, and so far
no one has shown it doesn't.
It is _not_ designed to encrypt multiple messages with the
same key. Always derive a new key RC4 key for each message.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Pseudo Random Number Generator
Date: Tue, 06 Feb 2001 21:28:49 +0100
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > What can be proved is the following:
> >
> > For m non-degenerate independent integer random variables
> > over [0,n-1] their sum mod n approaches a uniform random
> > variable as m increases. If one of the random varaible is
> > uniform, then any value of m results in a uniform random
> > variable.
>
> Counterexample: Lent n = 49, and the distribution of each
> variable be uniform over the 42 integers in [1..48] that are
> not divisible by 7, and zero elsewhere.
That's what is excluded by 'non-degenerate'. Sorry, if
the term is not standard or common.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: One way function for Passwords.
Date: Tue, 6 Feb 2001 12:11:14 -0800
Well I can't speak for LotusNotes, however such functions do exist and are
actually fairly commonplace. The most popular ones are MD5, and SHA-1.
There are several others of varying degrees of strength and size. The
property you are looking for is commonly expressed as finding x, and x' such
that F(x)=F(x') and x =/= x'. Since this is being used for passwords it is
actually a slightly different problem, given H find x such that F(x)=H.
These are actually very similar statements and one commonly implies the
other. What I would recommend, and would probably be the concensus here
would be to use SHA-1, it's fast, strong, free, respected, etc, and it's
available several places the original documentation is available in the NIST
FIPS (www.nist.gov), and implementations are available several places
including www.openssl.org
Now about verifying against those passwords. You might want to discuss that
here also, there are several issues with it.
Joe
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Free Encryption Software
Date: Tue, 06 Feb 2001 20:16:42 GMT
In article <unkXjC0iAHA.272@cpmsnbbsa09>,
"George Peters" <[EMAIL PROTECTED]> wrote:
> ...All of your questions and concerns would have answered if you
> had investigated it futher.
Do you know how to say, "Snake oil"?
--
I prefer the fourth amendment over a drug free society.
Did W declare the national emergency over yet and give us
back constitution rule? No? Why am I not surprised?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Free Encryption Software
Date: Tue, 06 Feb 2001 20:15:42 GMT
In article <957tgn$aje$[EMAIL PROTECTED]>,
Splaat23 <[EMAIL PROTECTED]> wrote:
> Couldn't find any concise description of the algorithms used, so I
> deleted it. That .zip file has ~1000 files, a little much for me to
> wade through. Why is it using Enigma? Any particular reason I should
> use it? I really hope this message is real and not some stupid attempt
> at advertising...
>
When I wrote my ECC software, having hundreds of files was exactly what
I wanted to avoid. The simpler the algorithm, the more certain it was
correctly implemented. I created only four C++ files that represent my
elliptic curve math template library files.
--
I prefer the fourth amendment over a drug free society.
Did W declare the national emergency over yet and give us
back constitution rule? No? Why am I not surprised?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Moritz Voss" <[EMAIL PROTECTED]>
Subject: Re: One way function for Passwords.
Date: Tue, 6 Feb 2001 21:38:36 +0100
"Ichinin" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:95p5us$7o5$[EMAIL PROTECTED]...
> One way hash functions (OWHF) create so called hashes = could be
That's exactly what I was looking for. I'll do some research on the topic,
thank you very much...
I have a few questions though, if you bother answering...would be nice
=^-.-^=
> Yes, Passwords that have been run through a OWHF is not
> directly "breakable", but you can make guesses.
> A Dictionary attack:
> (Note: I use short 16 bit hash values because my Afternoon break is
> almost over; normally you get 128-160 bit hashes out of MD5 and SHA-1)
Okay, lets assume the hash has 160 bit... 20 bytes, if I have a password
that is longer than that (and Lotus Notes allowed passwords like "This
Password has more than 20 characters"; that would mean you "lose" precision
on your password so the function converting your password into the hash is
not injective. Sure, that mathematically /implies/ there's no real inverse
to the function, but then, since it's limited to a scope of the numbers from
0 to (2^160)-1, there will be multiple (and depending on the allowed
password length, possibly an infinite number of) candidates that will
generate the same hash.
Sure, finding these takes a lot of computing power if you use something
brutal... but if you know the OWHF, isn't it considerably easy to reverse
engineer such a function so you get candidate passwords, ones that generate
the same hash? You can never know as the end user whether your password will
generate an unique hash...
> Now what? - We add "Salt":
> A Salt is a N bit random number that is concatenated to a plaintext
> BEFORE hashing to make dictionary attacks such as the above harder,
Oooh, I get it....sort of.
My question:
I am sitting at my machine, configuring my password for a remote login.
"password". It concatenates my random number to it as
"password+randomnumber" and hashes it.
Now I sit someplace overseas and try to {ssh or something} log into my
system. I only know my password!
I send that to my machine, where something listens for the password. It
receives "password". Now, how do I get from there to "password+randomnumber"
that will result in the correct final hash? I don't think storing the "Salt"
someplace would really help, since that would, of course, compromise
security back to the old level.
> You can read more in Applied Cryptografy and Handbook of Applied
> Cryptografy. (check with Amazon.com)
I'll check out the university libraries for that....
> Regards,
> Ichinin
Thanks a lot :) I know what I have to look into.
Regards,
Moritz
------------------------------
From: "Amaury Jacquot" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.nordic,soc.culture.russian
Subject: Re: Actually I monitored activities of this NSA�s P1363 Group for many years
..... actually was just around 5 % of my interest in this specific fields .... I have
always liked non-random random number ...I like to use ever changing environment for
randomne
Date: Tue, 06 Feb 2001 20:37:54 GMT
how do you expect us to read the message if everything is in the subject...
"Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote in message
news:95pa8e$c1a$[EMAIL PROTECTED]...
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 06 Feb 2001 20:42:36 GMT
Subject: Re: Questions about Diffie-Hellman
There are LOTS of subtle considerations, for example, small subgroup attacks.
See IEEE P1363 for more info.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Mod function
Date: Tue, 06 Feb 2001 20:48:48 GMT
Check out Handbook of Applied Cryptology at
http://www.cacr.math.uwaterloo.ca/hac
However, if speed is your main concern you should at least program the
mod function in assembler. My guess is that you get down below 10
seconds in VB even if you fix the value of the modulus and all derived
parameters in your code. If you are looking for an easy to learn, easy
to debug and relatively fast language, you should definitely use
(Object) Pascal over C/C++. Most C code I've seen is a lot messier and
harder to track than most Pascal code, but there is usually little
difference in the performance of the executable output of the
respective compilers.
In article <3Hof6.408$[EMAIL PROTECTED]>,
"Adam Smith" <[EMAIL PROTECTED]> wrote:
> Hello all. Since my last post a 512 bit RSA key was contributed to me
> (hehe) and now my app is working fine, except it takes about 13
seconds to
> verify a signature which is way too long. A lot of the time is taken
in the
> mod function. I'm looking for an efficient mod function that is good
for
> crypto. Either in VB (preferred) or C/C++ (with comments hopefully,
I'm not
> extremely skilled in VB so it might be a little hard to port to VB).
>
> Thanks!
> Adam Smith
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: On combining permutations and substitutions in encryption
Date: Tue, 06 Feb 2001 21:21:25 GMT
On Tue, 06 Feb 2001 13:09:13 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>>
>> >[...]
>> >It is interesting that you view whole file processing as
>> >variable-size block ciphers (in view of the fact that
>> >you have some patents on variable-size block ciphers,
>> >if I remember what you wrote previously correctly).
>>
>> The cipher design is what it is. The patent is what it is. This is
>> not really a viewpoint issue.
>
>The meaning of what you wrote above is not yet very clear
>to me. A 'consideration' that whole file processing is a
>block encryption is also what it is (as a view/fact). It
>is not a trivial issue at all, for there is the very
>serious question of possible infringement of your patents
>(hopefully only in US currently) when one does whole file
>processing in crypto.
It is not "whole file processing" which defines a Variable Size Block
Cipher, although of course one would expect that a VSBC could cover a
full file. In practice, it may be more reasonable to set some maximum
large-block size which will fit in memory, process that, then go on to
another chunk, so huge files might be processed in chunks anyway.
With respect to my VSBC patent, a particular structure is defined.
>Further, using e.g. CBC to chain blocks effectively makes
>the whole message a 'block'. When one looks the proper
>(small) block cipher as a component of a larger system,
>then one is doing 'block' encryption, the whole message
>being that (large) block, and one of 'variable' block size,
>because the size of messages is in general not constant.
>So block chaining in general would have possibly been in
>conflict with your patents. If that is indeed the case,
>it would be very important that all people concerned with
>crypto know it, in fact much more important than Hitachi's
>rotation.
As I recall, CBC was in fact patented by IBM. That is not some verbal
academic presentation in a small overseas meeting, but is instead
prime published material that examiners are expected to know. Just
getting an issued patent implies that it does not read on CBC. In
particular, CBC is a one-way diffusion, but is only applied once;
there is only one "layer."
As far as I know, I was the first person in the world to publish the
concept of a Variable Size Block Cipher, and my original sci.crypt
post and the academic responses to that post are archived on my pages.
My patent covers the technique for achieving VSBC's by the application
of (at least) two one-way diffusion layers. Dependent claims cover
confusion with diffusion, confusion in opposite directions, and so on.
I have actually measured diffusion in many different VSBC structures.
Normally, it is necessary to have at least 3 one-way diffusion layers
before the system attains diffusion characteristics which approach a
true block cipher. So when I design a VSBC, that is what I do. But
from the patent it appears that others who do less are also covered.
>Sorry for going a bit in-depth about this issue, for I
>myself often do whole file processing and employ chaining
>(and further once considered letting the user to have the
>comfort of choosing the block size within an appropriate
>range) and hence am particularly interested in it.
Well, yeah, but we've been over this and over this. The issued patent
is a legal document, and as such may have application beyond what the
inventor expected. My VSBC patent has been on my web site for years;
nowadays it is probably just as available from the US PTO site.
Obviously, US patents do not apply in Europe.
I understand that many academics feel that they don't need patents, so
they don't need to know how to read patents. It seems amusing to find
academics arguing from a position of ignorance about their intent to
maintain that ignorance, but maybe academics can get away with that.
You, however, obviously do need to learn how to read a patent.
For infringement purposes, go to the claims. Read each claim and see
if it will fit into ("read on") the proposed design. If the claims
contain unusual words, it may be necessary to read the patent body to
understand what those words meant to the inventor, and how they should
be interpreted in a claim. Basically, if any design includes all
parts of even one claim, it will infringe when manufactured, sold
(including free distribution), or used. Extra parts around the basic
design do not prevent infringement.
The reason for having dependent claims is to further specialize an
independent claim. So even if the independent claim is found in court
to be too broad, the further-specialized dependent claims may still
stand. But until things get to court, every issued claim has already
been argued and approved by the government which issued the patent;
all claims are thus assumed valid. If any claim reads on a design,
manufacture, sale, and use are restricted to that permitted by the
patent holder.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Scramdisk, CDR and Win-NT
Date: Mon, 5 Feb 2001 21:18:52 -0000
Michael Robbins <[EMAIL PROTECTED]> wrote in message
news:95p7ic$95b$[EMAIL PROTECTED]...
>
>
> > Do you mean 'create an image of <=650Mb on a hard drive, mount it and
> > fill it full of data then write it to a CD and have RO access', if so
> > then just buy a copy of Scramdisk for NT and this will work fine.
>
> Thank you.
A pleasure.
> I just bought it--I'm waiting for the password.
Excellent news.
> So you're saying I can
> access the CDR as if it were not encrypted without writing it back to
> the hard drive?
Yes, simply mount and then you can access the contents as per a normal (hard
drive based) container.
> Are there any tricks I should be aware of? Any
> specific vulnerabilities I should be immediately concerned with?
Don't use NTFS on the volume and you will be fine.
Regards,
--
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: DSA flaw - RNG biased
Date: Tue, 06 Feb 2001 21:57:36 +0000
full story:
http://www.cnn.com/2001/TECH/internet/02/06/DSA.flaw.idg/index.html
extracts:
"Daniel Bleichenbacher, a member of Bell Labs' Information Sciences
Research Center, discovered a glitch in the random number generation
technique used with the DSA, according to the company in a statement.
He learned that the DSA's random number generator was biased and was
twice as likely to pick a set of numbers from one range than from
another.
[..]
The vulnerability does not pose any immediate threat as it takes
massive computing power to launch an attack on the flaw, according
to Bell Labs."
--
+-------------------------------------------------------------------+
| David A Crick <[EMAIL PROTECTED]> PGP: (FEB-2001 KEY) 0x2EEFF1D3 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Tue, 06 Feb 2001 21:46:41 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> > Terry Ritter wrote:
[...]
> > > Generating new ciphering structures is *important* in
> > > the sense that everyone needs to understand just how
> > > little is known of this area,
> > > and the extent to which what we think we know, we don't.
> >
> > Only analysis of ciphers does that. Though we do need
> > ciphers in order to do analysis, we're already way, way
> > overstocked.
>
> This is certainly a very viable standpoint and applies
> also to some other fields. In fact a friend of mine once
> remarked there are much too many new books, pictures, songs
> etc. etc. constantly appearing. As I recently remarked, we
> have already very excellent cryptos to cover the needs for
> the coming several decades, if not centuries. So it could
> indeed be time to pause and relax and direct efforts to
> other scientific disciplines, if one so prefers.
Hard to believe you are looking at the same world as am I.
There's a huge need, and call, for crypto research. But a new
symmetric cipher not known to be secure or insecure just makes
a large pile bigger.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encrypting Predictable Files
Date: Tue, 06 Feb 2001 21:51:44 GMT
In article <OmUL9VHkAHA.269@cpmsnbbsa07>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> [still on the topic of encryption, but leaving Encrypting predictable
files]
> Well let's see if we can take a look at these claims in detail, shall
we.
> D/s<[EMAIL PROTECTED]> wrote in message
> news:95o26v$bbu$[EMAIL PROTECTED]...
> > changes the lenght of files.
> > uses Rijndeal in a way that can encrypt any file without adding
> information.
My encyption scott16u or scott19u operated in the modes
that don't add random padding do not change the length of the
file during encryption. The input file and output file have
the same lenght.
Matts code can have different lenghts out. Sometimes the
output file is longer and sometimes shorter. He is doing
bijective compression as he encrypts. But in both mine and
Matts "zero information is added to the file"
>
> Perhaps DS needs a review of reality once again. The above statements
are by
> themselves clearly in opposition. However there's an additional
matter that
> he apparently keeps forgetting. Encryption is itself an act of adding
> information to a file, with decryption being an act of removing the
same
> information, that's what the key does. In good encryption it is
impossible
> to remove the added information (the key and algorithm) without
knowing the
> information, in bad encryption it is possible or likely possible that
the
> information can be removed. If DS had bothered paying attention for
the
> years that he has been a pain in the side of sci.crypt he would have
known
If you had the ability to learn ( which it seems you can't)
You would realize that good encryption hids the data with a key
but that that key information should not be part of the encrypted file.
A concept that is over your head.
> that by now (it's at least the third time I've told him).
>
> Now to get back on topic, when you are encrypting predictable files
you
> _want_ information to be added, or rather you want entropy added to
obscure
> the information in the file. This information can be in the form of
padding,
> cryptographic keys, IVs, etc depending on the requirements of the
system.
Again Mr Ash.. seems incapable of under standing simple concepts.
Good encryption does not add information. Good compression such
as mine and Matts don't add information to the file either. Matts
product combines good compress with good encryption so the lenght
of most useful files gets smaller. But there is no added information
The encryption key is no way added to the file.
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
