Cryptography-Digest Digest #700, Volume #13 Sat, 17 Feb 01 03:13:00 EST
Contents:
Re: Super strong crypto (Steve Portly)
Re: My encryption system..... (Nemo psj)
Re: Super strong crypto (David Wagner)
Re: Ciphile Software: Why .EXE files so large ("Michael Brown")
Re: Ciphile Software: Why .EXE files so large ("Michael Brown")
Re: Digital signature w/o original document ("David Sowinski")
[release] OutGuess 0.2 - steganographic tool (Niels Provos)
Re: Digital signature w/o original document ("David Sowinski")
Re: Big Numbers in C/C++ ("David Sowinski")
Re: Super strong crypto ("John A. Malley")
Re: DES-Question... ("Scott Fluhrer")
Re: Super strong crypto (SCOTT19U.ZIP_GUY)
Re: Hardware RNG - Where can I order one? (those who know me have no need of my name)
Re: What is kerebos? (Robert Stonehouse)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: My encryption system..... (wtshaw)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: National Security Nightmare? (Eugene Morozov)
----------------------------------------------------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 16 Feb 2001 20:15:02 -0500
"Douglas A. Gwyn" wrote:
> Steve Portly wrote:
> > Your system can only be as strong as the first key you use. An attacker
> > with an infinite amount of time could try all combinations of starting
> > keys until a coherent message appears.
>
> No, the specification ensured that there would be multiple
> possibilities for coherent messages.
>
> There *is* a theoretical weakness in that each key span
> could be independently reduced to keys sorted in order of
> likelihood (based on source statistics), which would
> enable one to chain the likelihoods backwards to improve
> the estimates for likelihoods in earlier blocks. If this
> scheme were put into practice, one would have to change
> the key quite a ways short of the unicity distance.
Thanks for clearing that point up. I was thinking you might have to create
your plain text in a rather unorthodox manner, perhaps without spaces or
punctuation to improve your chances of success.
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Date: 17 Feb 2001 01:25:02 GMT
Subject: Re: My encryption system.....
Wow that kid is scary..
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 17 Feb 2001 02:33:26 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>Here is a "straw man" block cipher design for you all to analyze:
>The last PT block before the unicity distance is reached contains
>a newly generated random key to replace the one currently in use.
>It's a new form of "chaining" mode, if you wish.
What is the purpose? What is the threat you're trying to defend
against with this construction?
Also, what is the relevance of unicity distance? Clearly the
construction isn't information-theoretically secure, so I don't
yet see how unicity distance comes into the discussion...but I'd
love to be enlightened.
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software: Why .EXE files so large
Date: Sat, 17 Feb 2001 16:00:21 +1300
> Check it out and stop using all those expensive IDE's. Learn to write code
> using the raw Windows API. Use LCC-Win32
> http://www.geocities.com/SiliconValley/Heights/9069/index.html ...Thank
you
> Jacob!!
Actually, for pure speed I use assembler (it's vicious for doing anything
big in though) combined with the Win32 API when I have to (would you believe
that they're _still_ optimised for a 486 in many places!). For small
executables I mainly use FreePas combined with FPIDE (both free). For big
projects, such as the recent port simulator I wrote (200000 odd lines of
source code), I use an IDE such as Delphi or CPP Builder. It's slightly
slower, but you can develop stuff a lot more quickly.
Cheers,
Michael
PS: You've probably already been told this, but you probably want to remove
the x-post to alt.hacker as they all hate this guy, have just about all
killfiled him, and don't want to see replies to his messages. I found this
out the hard way :)
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software: Why .EXE files so large
Date: Sat, 17 Feb 2001 16:02:35 +1300
> Have you considered using Python?
>
> It's designed for RAD programming like VB, but it is also platform
> independent. It has very extensive documentation, both books and
> online.
Isn't it effectively interpreted? I've never used Python, but after seeing
the shocking performance of VB when you try to do anything fast I have a
great suspicion of interpreted languages.
Cheers,
Michael
------------------------------
From: "David Sowinski" <[EMAIL PROTECTED]>
Subject: Re: Digital signature w/o original document
Date: Fri, 16 Feb 2001 21:33:35 -0600
> > I am interested in generating a digital signature that can later be
verified
> > without the original document. I recall coming across a homomorphic
> > encryption/signature scheme awhile back, but cannot find much
information on
> > it now. Does anybody know if this is possible?
>
> I must be missing something. If you don't have the original document, how
> do you know what you are checking the signature of?
Maybe I am completely whacked! It certainly doesn't make any sense... For
some reason, though, I recall a scheme that validated information, as well
as hid the information -- maybe it was actually using the information
without knowing it. Right now I cannot recall the details and cannot find
the papers. From what I do recall, there were a few examples how the scheme
could be used: One was related to using a formula to solve problems without
actually knowing the formula and the other was related to software
protection. At any rate, and like I said before, maybe I am completely
whacked.
Thanks
-dave
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Niels Provos)
Subject: [release] OutGuess 0.2 - steganographic tool
Date: 17 Feb 2001 03:45:25 GMT
Release announcement of OutGuess 0.2
====================================
OutGuess is a universal steganographic tool that allows the insertion
of hidden information into the redundant bits of data sources. It
is undetectable by known statistical tests and provides for plausible
deniability.
You can download OutGuess from http://www.outguess.org/
Version 0.2 includes the following new features:
- Undetectable by any statistical test based on frequency counts.
- Determines maximum message size that can be hidden safely.
- Increases message space for JPEG format.
What does OutGuess do differently?
OutGuess modifies the least-significant bits of the quantized DCT
coefficients in case of the JPEG format. While some people view this
as simple and primitive, it allows OutGuess to preserve statistics
based on frequency counts. As a result, no known statistical test is
able to detect the presence of steganographic content. Before
embedding data into an image, OutGuess can determine the maximum
message size that can be hidden while still being able to maintain
statistics based on frequency counts.
Regards,
Niels Provos.
--
Niels Provos <[EMAIL PROTECTED]> finger [EMAIL PROTECTED] for pgp info
"Gravity is the soul of weight." - Anonymous.
------------------------------
From: "David Sowinski" <[EMAIL PROTECTED]>
Subject: Re: Digital signature w/o original document
Date: Fri, 16 Feb 2001 21:33:35 -0600
> > I am interested in generating a digital signature that can later be
verified
> > without the original document. I recall coming across a homomorphic
> > encryption/signature scheme awhile back, but cannot find much
information on
> > it now. Does anybody know if this is possible?
>
> I must be missing something. If you don't have the original document, how
> do you know what you are checking the signature of?
Maybe I am completely whacked! It certainly doesn't make any sense... For
some reason, though, I recall a scheme that validated information, as well
as hid the information -- maybe it was actually using the information
without knowing it. Right now I cannot recall the details and cannot find
the papers. From what I do recall, there were a few examples how the scheme
could be used: One was related to using a formula to solve problems without
actually knowing the formula and the other was related to software
protection. At any rate, and like I said before, maybe I am completely
whacked.
Thanks
-dave
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "David Sowinski" <[EMAIL PROTECTED]>
Subject: Re: Big Numbers in C/C++
Date: Fri, 16 Feb 2001 21:56:29 -0600
> Did you use just the C low-level routines in MIRACL when evaulating
> the speed? MIRACL also has assembly language replacements for these
> for the most popular processors, and using these instead will
> significantly improve the runtime efficiency. In the more recent
> versions of MIRACL, there's even an implementation of mudular
> exponents which uses Montgomery multiplication to gain even more
> speed.
Nope... I compared GMP v3.1.1 (with assembler optimization and built with
gcc under Cygwin) and MIRACL v4.42 (with assembler optimization and built
with VC++ 6 SP4). It should also be noted that I did not benchmark either
package entirely -- I was only interested in primality testing at the time.
> I also believe MIRACL is somewhat more accurate - why? Because it
> implements reals not as the usual floating-point numbers but as
> rational numbers: A/B where A and B both are integers. Which means
> you can divide a MIRACL real with 3, 7, 10, 11, 13, etc and then
> multiply the quotient with the same number and you're almost always
> guaranteed to get your exact original number back. This works as
> long as neither of A and B overflows (and since both A and B are "big
> integers", they won't overflow very soon). If A, or B; or both
> should overflow, MIRACL transforms A and B into smaller numbers such
> that the new A/B is an approximation as close as possible to the
> actual A and B - the final result is then no longer exact, of course,
> but it's still as accurate as a regular floating-point implementation
> of the same number of bits.
Hmmm... "almost always guaranteed" So, what's the advantage?
> MIRACL includes a full set of transcendental functions
> (logs/trigs/etc) for MIRACL hi-precision real numbers.
I will agree that out of the box MIRACL provides a lot of "already
implemented" functions. In my case, though, I really wasn't interested in
most of them. Again, this is only my opinion -- after looking at several
packages, I have settled on GMP.
Regards,
-dave
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 16 Feb 2001 20:01:35 -0800
"Douglas A. Gwyn" wrote:
>
> Here is a "straw man" block cipher design for you all to analyze:
> The last PT block before the unicity distance is reached contains
> a newly generated random key to replace the one currently in use.
> It's a new form of "chaining" mode, if you wish.
>
Should the key size take into account the possibility of a key collision
in the future?
Suppose a past key reoccurs. Just one more block of PT encrypted with
this key, in combination with the previous CT with the key, reaches the
unicity distance for that key. And there is all the new CT in that key,
so Eve ends up with almost twice the unicity distance worth of CT to
work with.
The birthday paradox springs to mind. As more random keys are selected
and the sum of CT grows, the probability that at least one of those
generated keys repeats tends to 1, and for at least one (unknown, but
used) key Eve gets more than enough CT to uniquely determine that
particular key (in theory).
Another thread branch here mentions using a special header to signify
the key change inclusion in the CT. Assume Eve knows that, too. So Eve
can partition the CT up into different quantities of CT enciphered with
a given key.
I pause, trying to think of an efficient way to pair up all possible (CT
with key i) "segments" with one another to form CT of length greater
than the unicity distance for that particular key. The number of
possible pairings increases so fast due to combinatorics.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: DES-Question...
Date: Fri, 16 Feb 2001 20:59:34 -0800
Carsten Alexander <[EMAIL PROTECTED]> wrote in message
news:96ju4f$di3$[EMAIL PROTECTED]...
> Hi there,
>
> i'm quite new in cryptography, but i think i got the "big picture" of DES.
> My problem: i have almost no idea of the scientific and
numeric-theoretical
> background, 'cause it's a hard one. But i'm working on this ;-)
>
> My question:
>
> First: assume we'd know the plaintext, didn't know the encryption key
used,
> and only 16 bits of the ciphertext. When we'd do a brute force attack we'd
> get 2**(56-8) = 2**48 matching keys. Am i right so fare?
Well, that's not the usual assumption. With DES, we usually assume that we
have (at least) an entire plaintext and entire ciphertext block. In
addition, if there's anything that's uncertain, it's usually the
plaintext -- we're given the cipertext.
However, if we make your assumption, and we assume that DES acts like an
ideal keyed random permutation, then we'd expect about 2**(56-16) = 2**40
matching keys. You can derive this by the observation that there are 2**56
keys and each key has a 2**-16 probability that, given the known plaintext,
those specific 16 output bits would have the specified values.
>
> Second: assume we'd know a second, completely different plaintext , still
> didn't know the identical encryption key used, and 16 bits of the
different
> ciphertext. When we'd do a brute force, we'd get an another subset of
2**48
> matching keys. Let's take a look on the two subsets. Which amount of keys
> would be the same? Every second key, or every eights one (because, we know
> eight bits of both ciphertextes)
Well, generalizing my above analysis, with two full plaintext blocks and two
16-bit ciphertexts, we'd expect about 2**(56-32) = 2**24 keys. We get this
by observing that you specify a total of 32 independent output bits -- that
those output bits correspond to two separate ciphertext blocks is basically
irrelevent[1].
[1] If you examine it extremely closely, the fact that DES is a permutation,
and hence two distinct plaintexts always encrypt to two distinct
ciphertexts, bias things a bit. However, in this case, the bias is so small
it can be ignored.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Super strong crypto
Date: 17 Feb 2001 05:04:18 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in
<[EMAIL PROTECTED]>:
>wtshaw wrote:
>> Considering what was in the public eye at the time, it was the best
>> thing going, but I was after bigger game long before that, and I was
>> on the right track. Too many people forget Shannon, that the amount
>> of ciphertext necessary for breaking a cipher is a critical part of
>> strength.
>
>I think it's not forgotten, just the designers don't know how to use it.
>
>Here is a "straw man" block cipher design for you all to analyze:
>The last PT block before the unicity distance is reached contains
>a newly generated random key to replace the one currently in use.
>It's a new form of "chaining" mode, if you wish.
>
I am not sure this is reasonable. All currently "blessed" ciphers
have to short of a unicity distance when encrypting text that this
would be wasteful if it could be implimented at all. Far better
to design a large varible block cipher with a hudge key.
So called modern experts don't want to consider unicity distance
at all since it shows that modern block ciphers have the built
in information theoritically weakness. They would rather try to
pull the wool over the eyes of the public by pretending short keyed
ciphers are safe since they would take the life of the sun to do
a dumb blind search. They don't want to be honest and admit that they
lack the robustness of a Shannon information consideration.
INstead they call large keyed ciphers SNAKE OIL and claim they
are not needed for security at all.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Hardware RNG - Where can I order one?
Date: Sat, 17 Feb 2001 05:22:22 -0000
<[EMAIL PROTECTED]> divulged:
>Is there a simple way to tell if my mb supports this? It's a Thinkpad
>a20p laptop, PIII processor. Thanks.
install linux 2.2.18 or 2.4.0, or later, and inspect /proc/pci. also if
you can cat /dev/intel_rng (c 10 183) or if /proc/sys/dev/i810_rng_*
"files" are present then you've got one.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (Robert Stonehouse)
Subject: Re: What is kerebos?
Date: Sat, 17 Feb 2001 07:06:02 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
...
>The dog's name is more open to argument. The name was almost
>undoubtedly originally Greek, so the first letter was almost
>certainly Chi. This is pronounced a bit like a hard "C" or a "K",
>but with more breath to it, like the sound had a bit of "H" mixed in.
No, it was kappa: e.g. Hesiod, Theogony 311. So the pronunciation is
like our 'k'.
[EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 17 Feb 2001 07:39:18 GMT
David Wagner wrote:
> Douglas A. Gwyn wrote:
> >Here is a "straw man" block cipher design for you all to analyze:
> >The last PT block before the unicity distance is reached contains
> >a newly generated random key to replace the one currently in use.
> >It's a new form of "chaining" mode, if you wish.
> What is the purpose? What is the threat you're trying to defend
> against with this construction?
The point isn't the threat; it's just a message encryption scheme.
The point is piggy-backing key distribution before one has
lost the security assurance.
> Also, what is the relevance of unicity distance?
This thread was apparently about provably strong encryption,
which forces an information-theoretic approach. If the new
key is transmitted (encrypted under the old one) before there
has been enough ciphertext to enable an attack with success
rate above some specified threshold, it might seem that one
could keep the channel secure forever. In another follow-up
posting I did note that you'd have to retire each key not too
near the unicity point, or else feed-through of partial
information from other blocks could push past the security
threshold. But that would be a second-order effect and so
it can be defeated by leaving a sufficient margin.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 17 Feb 2001 07:42:31 GMT
"John A. Malley" wrote:
> Suppose a past key reoccurs. ... The birthday paradox springs to mind.
For realistic key sizes it would be a minor risk, compared to the
presumed target security threshold.
> Another thread branch here mentions using a special header to signify
> the key change inclusion in the CT.
I'd think any such flag would be in the PT.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: My encryption system.....
Date: Sat, 17 Feb 2001 01:20:36 -0600
In article <[EMAIL PROTECTED]>, Quisquater
<[EMAIL PROTECTED]> wrote:
> First, try to correctly write "piece" then "snake oil".
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Nemo psj) wrote:
> Wow that kid is scary..
In article <[EMAIL PROTECTED]>, Keill_Randor
<[EMAIL PROTECTED]> wrote:
> The encryption system I have, (in a response to other posts on this board),
> IS different and a generation ahead of any other encryption system in
the world
> that I know of....
Hey, that's my bag, and you cannot have it unless you earn it! ;)
> This seems to be the number one problem with everyone at the minute:
> No-one understands the problem, so no wonder nobody, (apart from myself),
> has actually solved it.
As a chemist, I thought I had all the solutions.
Seriously now, RRR(Randy Rant'en Randor), I'm glad to see that you are
excited about crypto, but let's dwell on some specifics: Considering some
basic aspects of all crypto, describe your stuff and let's see if it a
turkey, a stuffed turkey, or a tasty possum of a cipher.
Every now and then, the vinegar gets to flowing in me, and I speak truths
are wasted sounds on the crypto tone deaf, as monotones are better
respected. So, get on down to the boring nitty gritty, and tell me
something about your keys for starters, whether they are put under the
mouse pad, reside in computer memory, or amongst the figments that might
populate your little hot head. Hey, this is serious: An intro to build
on...
> The by-product of this, is being able to turn ANY peice of information
into ANY
> peice of information, which again, makes it uncrackable. (And
completely screws
> up a lot of laws I know about).
>
It's been done, and I did it..so,there. (The problem with lots of
established ideas is that they are already screwed up.)
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 17 Feb 2001 07:56:42 GMT
"SCOTT19U.ZIP_GUY" wrote:
> I am not sure this ["straw man" cipher] is reasonable. All
> currently "blessed" ciphers have too short of a unicity distance ...
> So called modern experts don't want to consider unicity distance
> at all since it shows that modern block ciphers have the built
> in information theoretical weakness.
Um, yes, that's why I raised the issue. If we really want to
investigate what it would take for "super strong crypto" we need
to avoid assuming anything about a measure of "strength" that we
assign to a system based solely on our own ignorance of appropriate
cryptanalytic methods. All measures based solely on the infeasibility
of searching the key space fall into that category, as do most other
"combinatorial" arguments. That means we need to go back to basics
and investigate the proper assessment of likelihoods based on
information statistics. One sees little of that in the open
literature (at least for cryptology; however, it is not so rare in
other information-related fields such as communication theory).
If such an investigation shows that the usual block-cipher systems
cannot provide "super strong crypto", even with frequent key updates,
as well it might, then getting people to appreciate that might help
sell them on systems like scott19u. I think in many practical
applications, a channel is going to have to start off with a
relatively short secret key (say, 512 bits) and use some provably
good way to "stretch" its secrecy. Thus my straw-man proposal.
------------------------------
From: Eugene Morozov <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: 17 Feb 2001 11:00:32 +0300
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> "Douglas A. Gwyn" wrote:
> >
> > Mok-Kong Shen wrote:
>
> > > The problem is that, if one doesn't have any information
> > > to start, then it is really like finding needles in
> > > haystack.
> >
> > At least for domestic communication within the US, without
> > probable cause, governmental agencies aren't supposed to be
> > examining the information at all.
>
> There are rumours (no proof, understandably) that in
> a few democratic countries (not US) there are misuses of
> wiretaping, possibly by corrupted personals. That's
> I believe the main cause of people's negative opinions
> towards that. It's clearly a difficult issue like hundreds
> of others in society, e.g. whether a country should have
> nuclear power plants.
If Russia is a democratic country (if you don't live here you might think it
is), then these rumours are correct. All russian providers should send copies
of all email messages going through their mail servers to organization that was
called "KGB" in soviet era. So, KGB employees may read almost any email
without permission of the court and I'm sure they're already doing that.
Combined with russian law forbidding any use and/or development of encryption
for any purposes this creates a great possibility for misusing wiretaping in
Russia.
Eugene
--
Email: <jmv @ yandex.ru>
------------------------------
** 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
******************************
