Cryptography-Digest Digest #682, Volume #13 Mon, 12 Feb 01 18:13:00 EST
Contents:
Re: Should I store a copy of gpg source code with my archive? (Paul Rubin)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Scramdisk, CDR and Win-NT (jungle)
Re: Multiple-Key RSA cryptosystem (Philip MacKenzie)
Re: Password authentication with symmetric key exchange ("Henrick Hellstr�m")
Re: Super strong crypto (Jim)
Re: RSA is not secure in many instances... ("Henrick Hellstr�m")
Re: Password authentication with symmetric key exchange (Mok-Kong Shen)
Re: Rnadom Numbers ("Joseph Ashwood")
Re: Password authentication with symmetric key exchange ("Sam Simpson")
Re: Password authentication with symmetric key exchange ("Henrick Hellstr�m")
----------------------------------------------------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Should I store a copy of gpg source code with my archive?
Date: 12 Feb 2001 11:11:06 -0800
jtnews <[EMAIL PROTECTED]> writes:
> I'm storing away some CD-RW disks with encrypted data
> from gpg.
>
> Do I also need to store a copy of the source code
> to gpg with the CD-RW disk? Or is the encrypted
> data format stable enough that I don't have to
> worry about problems retrieving my data afterwards.
GPG follows the OpenPGP spec which is described in an internet RFC
so the format should be pretty stable. But who knows if the software
itself might become illegal? I'd say save a copy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Mon, 12 Feb 2001 18:18:09 GMT
"S. Welsh" wrote:
> If fractal codes are usuless, then what is the best available
> algorithm currently available? ...
This question gets asked frequently, and the answer always is
that there is no universally "best" encryption algorithm. For
many purposes, 3DES (112-bit key) or AES (128-bit key) are fine;
nobody admits to knowing how to break them purely through
analysis of the cipher messages, with or without partial
knowledge of the corresponding plain messages. AES tends to be
faster than 3DES, so you may prefer it. However, whoever is
intended to decrypt the message must have access to an identical
copy of the key used to encrypt the message; if that poses an
insurmountable logistic problem, then you need a "public key"
algorithm, of which RSA is the best known and oldest still
viable example. It is usually said that to ensure reasonable
security of RSA encryption you should use a 1024-bit key.
The simple fact is that nobody admits to knowing for sure that
these algorithms are impervious to analytical attacks, although
these seems to be general agreement that an analytical RSA crack
that scales efficiently would be equivalent to a long-awaited
breakthrough in computational complexity theory, which means not
only that it would be hard to keep secret but also that nearly
everybody would be in the same (sinking) boat.
> P.S. As my previous posting may have revealed I am new to the
> subject of encryption, ...
No matter how theoretically secure the algorithm, when it is
embedded in a complete protection system there can be other
avenues of attack, too numerous to list here.
Your best bet is probably to purchase a professionally produced
product using the aforementioned algorithms from an established
vendor such as RSA or Counterpane (to pick two whose employees
are frequent participants in this newsgroup).
------------------------------
Date: 12 Feb 2001 19:26:10 -0000
From: jungle <Use-Author-Address-Header@[127.1]>
Subject: Re: Scramdisk, CDR and Win-NT
Crossposted-To: alt.security.scramdisk
=====BEGIN PGP SIGNED MESSAGE=====
12 Feb 2001 in <[EMAIL PROTECTED]> Keith Wilkinson
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>, Jungle wrote:
> > thanks for warnings ...
> > are you relying others stories or mostly your own horror ?
> >
> > normally past stories are from "past", where all just started to emerge,
> > IMO almost all are the result of inappropriate use / abuse + low quality of media
> > [ it's generalization but people are paying top money for hardware & save on
>media,
> > you can see this when people are describing they HI-FI equipment,
> > ask them what percentage of overall cost, the speakers weight, you will be
>suprice ]
> >
> > the new technology which I'm calling "don't run on empty stomach"
> > is eliminating all these stories, as long as people don't have it,
> > it's would pay to understand how & why these "flaky, ... not very robust"
> > situations are present
> >
>
> I've used the packet writing software "PacketCD" from CeQuadrat - it came with my
>Sony
> CDW/R drive. In theory it looks very good, although the capacity of a 650MB CD is
>reduced
> to 500+MB, but I have found it to be definitely flaky to the extent I no longer use
>it.
> I use either Kodak or Sony CDRs/CRWRs and have no problems with burning and reading
> ISO/Joliet file systems but I have had lots of failures with packet writing/UDF.
I'm not & never will use CD-R/W UDF as H/D substitution, the is no reliability & more
important,
the is no SPEED of access that could be comparable to my H/D speed,
I did use & I'm using it as R/W off site storage,
something in the middle between CD-R & useful semi back-up / depository
[ in doing this, I DID NOT have any disastrous writes ]
by saying this, I'm using it for writes of normal, average size files,
I did not write file of SD container size, ~525 MB
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Mon Feb 12 19:26:08 2001 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOog40U5NDhYLYPHNAQE17Af+JPL7fljfP1MUrUJR80FcjpxaSYOazUwR
TzKvpkyu68wXRvE4g5JHHZlDlWx7nRbTBQPTF1cHq0Y5Upp5TrTH11Kg750+7WF4
ZZ2IRedRvqJVc9l+1ybXSDE+cc4dZHNImezzr/Qyfzi+CLk33rqsNrL9Ew3ZiPC8
66rhaW8umtM0S+ag1w72YDVm70CousZBicqQxTZMN0tCTAv0Ncs/yzi5qy3BZ1bi
m/dxI4XhjtDkczcHIR+ZxmFfh50BweydYUnDivc7WhhtWxYUDVbXeTd6Qb7nefNl
mNyHpX7jcnTdXzWuXVn842n5lTBHS4oB8xadvD8hUQikcmWkuvI3dQ==
=gAMo
=====END PGP SIGNATURE=====
------------------------------
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: Multiple-Key RSA cryptosystem
Date: Mon, 12 Feb 2001 14:25:21 -0500
Or just look up "threshold RSA" or "proactive RSA" on any search engine
and you'll find scads of research. I think the first work in the field
was Boyd-1986 (the full reference is in almost all the more recent
papers
on the subject).
-Phil
DJohn37050 wrote:
>
> IBM has some stuff on what they call proactive security. Other papars are also
> aor
> Don Johnson
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Password authentication with symmetric key exchange
Date: Mon, 12 Feb 2001 20:43:57 +0100
"Paul Crowley" <[EMAIL PROTECTED]> wrote:
> > Steak is a proposed encryption algorithm we didn't come up with over
> > night. It's more like the result of a couple of years of research. We
> > actually published it to get review from others (cf a previos thread
> > here on sci.crypt).
>
> I'd argue that getting it published in the academic literature is a
> key component of claiming academic review.
Point taken.
> You've updated the webpages to correct some of the problems, which is
> a good thing. But it still appears that you see your proprietary
> algorithms as your key Unique Selling Point, whereas in fact they are
> a deterrent to using your products.
Steak is not properietary. We have not filed any patent (because you can't
do that in Europe), it is no secret and we won't be upset if someone else
uses it.
> Basically, you display very little familiarity with other attempts to
> achieve the same job; these are the attempts to which yours will be
> compared.
>
> Your PCFB mode is one of *many* attempts to combine encryption and MAC
> in a single chaining mode. However, since it appears to require at
> least two block encryptions per block of plaintext, it offers no
> advantages over CTR-mode + CBC-MAC or similar. (That's assuming
> n/m >= 2; you don't make it clear on the PCFB page what n/m ratio is
> considered acceptible.)
The acceptable n/m ratio depends on the properties of the underlying cipher,
and on the length of the message. n/m = 2 should do if the underlying cipher
is Rijndael or some other AES proposal.
> As it happens, there are many proposals that require only a little
> over one block encryption per block of plaintext. However, Until the
> recent proposals to the NIST "modes of operation" workshop, there was
> not one such construction that hadn't been shown to have serious flaws
> under cryptanalytic scrutiny; the interest in these new proposals is
> because they are accompanied with proofs that lend confidence in their
> security. It's clear that you haven't been following the AES process
> since you had no familiarity with the work done at this workshop.
We constructed PCFB mode, as well as the homepage, prior to that.
> You describe a new block cipher, Steak, but your discussion of
> security makes no mention of differential or linear cryptanalysis.
Wrong. Steak is not a block cipher. It is a stream cipher. You cannot (at
least not successfully) apply the same kind of differential or linear
cryptoanalysis as you could if it was a block cipher. You can, however
successfully apply such cryptoanalysis on the main
function of Steak (i.e. the part of the algorithm that "encrypts" the
vector), but such analysis would not be enitely relevent since both the
input to and output from this function is unknown to the attacker, except
the
most significiant and least significant respectively of the vector.
> You try to design a password protocol, but you seem unfamiliar with
> the basics of what protocols such as SRP try to achieve, such as
> resistance to dictionary attack.
Well, I am not unfamiliar with those things. I know that the protocol I have
proposed in this thread is vulnerable to dictionary attacks. But there are
also lots of software using basic authentication (clear text password
authentication), and I don't pretend that my protocol is more secure than
much except that. I will however not use it. It was probably just a bad
idea, since noone seems to think differently.
> You assert that your system is fast, but you give no figures that
> allow us to compare it to comparable systems.
No, because the figures would be too dependant on the implementations.
Comparing an assembler implementation of Steak with e.g. pascal
implementations of other ciphers would result in figures clearly biased in
our favour. We are working on such a comparison, but it is not our top
priority. Feel free to do your own comparison.
> I've demonstrated, I think, that you're designing in a field that you
> don't know very well, but I don't actually think that's a sin.
> Designing your own cipher may not be educational (since you can't tell
> if you've done well) but it can be fun. However, you've gone from
> there to *employing a webmaster* to set up a company, spurred by what
> you think are successes in cryptography!
You obviously know little about Swedish taxation. ;-) We don't have any
employees. We are all co-owners of the company, and it is actually run on a
very low budget basis.
> Yes, what you've done is much closer to the Right Thing than the
> common behaviour you describe. But ultimately, snake oil is any
> medicine that looks just like the real thing but doesn't work. I sigh
> because you probably will get buyers, simply because so few buyers
> have the faintest idea how to distinguish good cryptography from bad.
You could say that about a lot things. There is a lot of unsecure "security"
software using proprietary or badly implemented algorithms without any
mention about it. We, on the other hand, clearly state the status of our
products.
--
Henrick Hellstr�m
StreamSec HB
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Super strong crypto
Reply-To: Jim
Date: Mon, 12 Feb 2001 20:56:05 GMT
On 12 Feb 2001 18:49:39 GMT, Stephen Early <[EMAIL PROTECTED]> wrote:
>In article <ypVh6.769$[EMAIL PROTECTED]>,
>S. Welsh <[EMAIL PROTECTED]> wrote:
>
>>If fractal codes are usuless, then what is the best available
>>algorithm currently available? And is there a site which compares
>>algorithms on the basis of their difficulty to break or key length?
>>As before, any responses are appreciated!
>
>"Best" for what? There is no single algorithm or key length that is
>good for every task.
>
>>I'm a British army infantry second lieutennant, straight out of
>>Sandhurst, and was pointed to this newsgroup by my CO and advised to
>>read up on the subject of encryption.
>
>You'll be better off with a book. Bruce Schneier's book "Applied
>Cryptography", second edition (ISBN 0-471-11709-9) is highly thought
>of[1]. You should be able to find it in a bookshop quite easily. For a
>more classical look at cryptography and the role it has played in
>history, try "The Code Book" by Simon Singh (ISBN 1-85702-879-1).
>
>After reading a book, try the newsgroup again for more information. It
>will be much more understandable, and you'll be able to decide for
>yourself which posts are believable.
Don't neglect 'The Codebreakers' by David Kahn for an historical
perspective. Out of print, but you ought to be able to turn up
a copy somewhere.
--
___________________________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
'We have to control the number of people
travelling' -- GNER spokesman.
__________________________________________
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: RSA is not secure in many instances...
Date: Mon, 12 Feb 2001 22:14:30 +0100
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:968mv5$tgs$[EMAIL PROTECTED]...
> What do you think you're attack is? Find a key (e, n) and guess
inversions
> by doing m^g mod n = 1? (g = guess) That's nuts!
>
> Tom
Is it?
r := m;
for i := 2 to MaxLowOrder do begin
r := (m * r) mod n.
if r = 1 then begin
Success := True;
Exit;
end;
end;
Success := False;
The chances of success might be low, but the attack is feasible as such
(provided that MaxLowOrder is set to a managable value, such as 65536).
--
Henrick Hellstr�m
StreamSec HB
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Password authentication with symmetric key exchange
Date: Mon, 12 Feb 2001 22:31:07 +0100
"Henrick Hellstr�m" wrote:
>
[snip]
> Steak is not properietary. We have not filed any patent (because you can't
> do that in Europe), it is no secret and we won't be upset if someone else
> uses it.
[snip]
It is not true that crypto stuffs can't be patented in
Europe. See e.g. IDEA. (See Menezes et. al, Handbook of
Applied Cryptography, p.640.) I conjecture that patenting
may be in general somewhat more difficult than in US, since
European patents have to go through public reviews so
that competitors have opportunities to timely file their
arguments against the submitted patents.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Rnadom Numbers
Date: Mon, 12 Feb 2001 13:21:16 -0800
That depends entirely on what you mean by algorithm. There are various
levels of algorithm. If you mean something that can be expressed using an
x86 based computer the answer is unfortunately no. However a human can
estimate the entropy of a system (and will often need to be aided by a
computer to do large quantities of computation). A very useful observation
on this is that the data stream itself does not have entropy defined for it,
it merely expresses the entropy within the generator. The analysis for
hardware is very complex so I will stick with software and build fair bounds
on ARC4 as an example (http://burtleburtle.net/bob/rand/isaac.html). Looking
at the algorithm we can place very rough upper and lower bounds on the total
entropy of the system, and we can observe thatthe entropy never increases
after the initial keying, so the bounds remain fixed to inifinite. These
bounds are [0, 2048] bits, we can examine the common usage of RC4 and see
that it is typically keyed using a 128-bit number, so our bound is now
[0,128] bits, we look at the known literature for an examination (because I
don't want to derive everything again for a trivial example), and we find
that the first byte has a substantial bias towards 0, and that on average
there is a bias of 2^-24 towards repeats, this reduces the entropy of the
system by a very small amount, lets estimate our new numbers to be [0,127.9]
bits. Now we begin work on the lower bound, we observe that changing any 1
bit changes half the bits rather quickly, so because the difference is so
small (and because I'm not compensating for unknown attacks) we'll just put
the bounds at [127,127] bits.
>From here we have to examine what we are doing with this stream. A close
examination of RC4 reveals that it becomes semi-predictable around the
gigabyte mark, let's be pessimistic and set it's terminal distance to
1000000000 bit (1Gigabit), from for the sake of simplicity we assume smooth
diffusion of entropy across those bits. From this we can state that each bit
contains (on average) 127/1000000000 bits of entropy at a minimum, but much
higher amounts of unpredictability. For the upper bound simply assume smooth
diffusion across the length of the data being used, this becomes minimum(1,
127/length) bits of entropy per bit, it is very important to note the use of
minimum here because a bit cannot contain more than 1 bit of entropy.
So there you have it, a very coarse, very rough estimate of the entropy (aka
randomness) of a stream that comes from the ARC4 generator. If you want more
dependable numbers it takes much longer than the 15 minutes I spent on this.
Joe
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Password authentication with symmetric key exchange
Date: Mon, 12 Feb 2001 21:07:40 -0000
Henrick Hellstr�m <[EMAIL PROTECTED]> wrote in message
news:969ec7$99r$[EMAIL PROTECTED]...
<SNIP>
> Steak is not properietary. We have not filed any patent (because you can't
> do that in Europe),
Not true. Look at IDEA, for example.............
> it is no secret and we won't be upset if someone else
> uses it.
<SNIP>
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Password authentication with symmetric key exchange
Date: Mon, 12 Feb 2001 23:13:32 +0100
More precisely: Algorithms can't be patented in Sweden, unless they have
some kind "physical impact", e.g. systems used to guide robots or chemical
processes. Mathematical methods are explicitly non-patentable. EPO has a
similar policy:
Quoted from http://www.european-patent-office.org/ap_gd/index.htm
"The first of these is programs for computers which are not regarded as
inventions insofar as they are claimed as such. However, if the
subject-matter claimed adds a contribution of a technical character to the
known art, a patent should not be refused simply because a computer program
is involved. This means that, for example, machines, processes of
manufacture or control processes controlled by a computer program may be
patented. "
--
Henrick Hellstr�m
StreamSec HB
"Mok-Kong Shen" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
>
>
> "Henrick Hellstr�m" wrote:
> >
> [snip]
> > Steak is not properietary. We have not filed any patent (because you
can't
> > do that in Europe), it is no secret and we won't be upset if someone
else
> > uses it.
> [snip]
>
> It is not true that crypto stuffs can't be patented in
> Europe. See e.g. IDEA. (See Menezes et. al, Handbook of
> Applied Cryptography, p.640.) I conjecture that patenting
> may be in general somewhat more difficult than in US, since
> European patents have to go through public reviews so
> that competitors have opportunities to timely file their
> arguments against the submitted patents.
>
> M. K. Shen
------------------------------
** 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
******************************
