Cryptography-Digest Digest #504, Volume #13 Sat, 20 Jan 01 01:13:01 EST
Contents:
Re: 32768-bit cryptography ("Scott Fluhrer")
Re: 32768-bit cryptography (Splaat23)
Re: Kooks (was: NSA and Linux Security) ("Douglas A. Gwyn")
Re: A Small Challenge (David Hopwood)
Re: Kooks (was: NSA and Linux Security) ("Douglas A. Gwyn")
Re: Light Computers ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: A Small Challnge ("rosi")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Fri, 19 Jan 2001 20:14:32 -0800
lemaymd <[EMAIL PROTECTED]> wrote in message
news:94aqn0$qrs$[EMAIL PROTECTED]...
> To all interested:
> Bermuda Triangle 2001 is an extremely fast, easy-to-use and secure
> cryptography engine. It is based on a new, 32768-bit algorithm of the
same
> name. Algorithm details can be found at my site as well as a software
> product that uses the algorithm, Bermuda Triangle 2001 Golden Edition. I
> also have a free cryptography engine that uses a similar (but
incompatible)
> algorithm available for download. Visit the site at:
> http://www.bermudatriangle.f2s.com/
> These software packages are written entirely in 32-bit, win32 assembly
> language and I can encrypt or decrypt an 8.4MB file on my Pentium(R) 166
in
> 8 seconds. Please give me your feedback!
This should be pretty easy to break given several encrypted blocks with
known plaintext (either several short messages encrypted with the same key
or one long one). As I understand it, your encryption algorithm is
essentially:
C[i] = ((P[i] ^ x[i]) <<< y[i]) + z[i]
where:
P[i] is a byte of plaintext
C[i] is a byte of ciphertext
x[i], y[i], z[i] are key dependent values, and which are repeated every
4096 bytes (and are interrelated)
^ is xor, <<< is bitwise rotate, and + is addition mod 256
Because x[i], y[i], z[i] repeat every 4096 bytes, this repetition length is
called a block.
Here's how to rederive a good portion of the keying data: for each byte
within a block, locate two plaintexts that differ in that byte by one bit.
If you have at least 16 plaintexts, and the plaintexts are random, you have
a good chance of having such a pair. Then, examine the corresponding
ciphertexts, and see the lsbit where they differ. The rotate that moves the
plaintext bit that differs to that lsbit ciphertext bit that differs must be
correct, thus giving you the 3 lsbits of y[i]. A similar trick can work if
you don't have a single pair that differs by precisely one bit, but you have
several pairs with low-hamming weight difference.
Once you have most of the y[i] values, you can use the interrelationships to
derive the 3 lsbits of x[i] and z[i]. Once you have that, reconstruction
the rest of the x[i], z[i] values should be straight-forward.
--
poncho
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Sat, 20 Jan 2001 04:33:15 GMT
Unfortunately, every word of criticism you receive, including this, is
probably merited. I'm afraid to even download the software from your
site for fear it is a trojan horse and I am going to have to deal with
it. 32768-bit encryption? Your description of the method is highly
suspect and mentions 8-bit blocks rather than 32768. As it is, it is
not fast (as mentioned before). Any the straw that breaks the camel's
back is that you want to accept payment via PayPal. Plus the
screenshots look doctored, but maybe that's just because they are so
graphical.
Feedback:
- The cipher looks completely insecure. What's your basis for claiming
it is any good whatsoever.
- 32,768 block size is silly. What do you really mean, or is this just
a marketing ploy?
- Site looks very unprofessional, and that doesn't help when your
software must be _trusted_
- Why am I even taking this as seriously as I am..... wait, I'm bored
and it's late and I probably should go now..... ;) As far as I am
concerned, this is a waste of bandwidth and the thread should stop
here. This is the definition of snake oil.
In article <[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
>
> lemaymd <[EMAIL PROTECTED]> wrote in message
> news:94aqn0$qrs$[EMAIL PROTECTED]...
> > To all interested:
> > Bermuda Triangle 2001 is an extremely fast, easy-to-use and
secure
> > cryptography engine. It is based on a new, 32768-bit algorithm of
the same
> > name. Algorithm details can be found at my site as well as a
software
> > product that uses the algorithm, Bermuda Triangle 2001 Golden
Edition. I
> > also have a free cryptography engine that uses a similar (but
incompatible)
> > algorithm available for download. Visit the site at:
> > http://www.bermudatriangle.f2s.com/
> > These software packages are written entirely in 32-bit, win32
assembly
> > language and I can encrypt or decrypt an 8.4MB file on my Pentium
(R) 166 in
> > 8 seconds. Please give me your feedback!
>
> Be prepared, you're going to see some weird replies. Perhaps a few
> rude ones. The problem is that your post is target rich for snake oil
> de-bunkers regardless of any merit it might have.
>
> Have you read the Snake Oil FAQ written by C Matt Curtin often
> posted here? The 10 part Sci-crypt FAQ? Applied Cryptography?
> It is inconceivable that you would read those and then compose your
> post as you did.
>
> Now comments. In assembler, 8.4 Megs per 8 seconds on a 166 Pentium
> is slow, real slow.
> That's like 150 clocks per byte where Twofish does ~18. There are
> even faster algorithms.
>
> 32768 bit cryptography? Do you realize how unrealistic that is?
>
> 1024 bit cryptography (If you are talking symmetric) will never be
broken
> by any little green man that any offspring of yours might meet, no
matter
> how far into the future you speculate.
>
> 32768 is like saying it uses "Dylithium Crystals".
>
> Hope you take this right.
>
> Paul
>
> -----= 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! =-----
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Sat, 20 Jan 2001 05:06:22 GMT
Greggy wrote:
> - I rely on God for help.
Perhaps you missed the sci. part of sci.crypt.
God help you.
------------------------------
Date: Sat, 20 Jan 2001 05:11:15 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: A Small Challenge
=====BEGIN PGP SIGNED MESSAGE=====
rosi wrote:
[snip]
The original post in this thread didn't reach my server. Since I assume it
also hasn't reached a fair proportion of Usenet, could you please repost
it (just to sci.crypt)?
I have done some research on the subject of public keys that are kept
secret, and schemes in which one private key corresponds to several public
keys or vice-versa, but I haven't been able to reconstruct from the replies
exactly what question was originally asked.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOmkDtjkCAxeYt5gVAQEnOQf/UHwEqcSimPC5ZO4YTye4T0LNawJPXGlb
f32x1vbdXc9KUGsorEgdGWmyAqtBCnsZj8XxE344V0PPpv//Aks22O5R77uLmC5F
pQ5vo2HB4paCDx5F3GwXCN52Lx8n21PyY79wVPFOifbjttsGq5onItZHgEsY0rcb
BMgqbpFJxV4P+HzfX8JXWuv0F7FBhUsOYDov+t0m+jgezc8su88ZYHgLU5b31CfW
pyoPqk3lwrYM8wgVJSBgiV2tokUk9WNrgowIGMkl3yJoEFMyP5dFbUTcSm2/mO0r
ImlwR9i2VGtnCr2OvpJZBQ1QPV8fphsMrx357gnv2s25VFe5eaMRug==
=FeUr
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Sat, 20 Jan 2001 05:39:59 GMT
Greggy wrote:
> Their actions show absolutely conclusively that they knew it was
> properly ratified.
The primary available evidence of a "ratification"
action by the Virginia legislature is the publication
of their civil code booklet in 1819. As has been
explained by others, in those days of poor
communication (before the invention of the telegraph)
there was often confusion about the status of
amendments. There is nothing in the historical
record showing a previous ratification action in
Virginia. And I already explained why even if one
wanted to interpret the publication of the booklet
as the act of ratification, (12+1)/21 < 3/4 so it
still wouldn't result in adoption of the amendment.
Persistence of belief, in the absence of supporting
evidence or in the face of evidence to the contrary,
using arguments that fall apart when examined, is the
hallmark of a kook. Indeed, kooks typically feed on
opposition to their irrational ideas, so one should
not expect to change a kook's beliefs -- the best
that one can do is to expose the kookery so that
other people don't fall into the trap. It's a pity
that the energy spent promoting lost causes isn't
directed instead in a more productive direction.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Light Computers
Date: Sat, 20 Jan 2001 05:42:10 GMT
Benjamin Goldberg wrote:
> Very interesting. I wonder, if the light was split first, and both
> resulting photons were stored in this manner, would they retain their
> polarization properties, and be usable in the same way as entangled
> atoms?
Obviously, they are not "freezing photons".
Apparently what is slowed is the propagation of
a packet of excitation, which while potentially
useful is not what the headlines would indicate.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 20 Jan 2001 05:43:52 GMT
On Sat, 20 Jan 2001 01:41:33 GMT, in
<h16a6.124700$[EMAIL PROTECTED]>, in sci.crypt "Matt
Timmermans" <[EMAIL PROTECTED]> wrote:
>I do think that this makes for an interesting cipher. It is "perfect" in
>exactly the same way as OTP is perfect. The benefit over OTP is that it's
>somewhat resistant to bit-flipping, though not as resistant as block ciphers
>are.
You need to be more explicit. In Dynamic Transposition, each block is
ciphered independently under a running keystream starting from a
random message key. The keystream does not re-originate so that one
can run various attempts at identifying which bits to flip. One can
change bits in transit if one wishes, but since one does not know what
effect that will have, it is unclear what one could do with it.
>If you have an unbreakable keyed RNG, though, then there are lots of easy
>ways to make secure ciphers.
Dynamic Transposition is not about having an unbreakable keyed RNG.
If we had that, nobody would need anything more than a standard OTP
additive combiner. But we *don't* have an unbreakable keyed RNG, and
that is the problem.
Dynamic Transposition is about building an unbreakable cipher
*without* needing an unbreakable RNG. This is done by hiding the
breakable sequence behind multiple levels of haystack, each so massive
that they cannot be searched. So the sequence in question cannot be
revealed, which makes it somewhat difficult to attack.
>It would take a lot of work to show that the
>system is secure with a real RNG, though. In particular, this bit doesn't
>work:
>
>> Known-plaintext attacks would be a first step in an attempt
>> to attack the RNG as in a stream cipher. But with Dynamic
>> Transposition, known-plaintext does not disclose the
>> enciphering permutation, because a plethora of different
>> bit-permutations will produce exactly the same ciphertext
>> from exactly the same plaintext. A successful attack
>> would thus require some way to distinguish more probable
>> permutations from less probable ones. Such an attack would
>> seem to be avoided by proper shuffling.
>
>If you don't know anything about the RNG, then there's no such thing as a
>known-plaintext attack.
Allow me to teach what a known-plaintext attack is:
Known-plaintext is nothing more than the situation of the opponent
having one or more ciphertext blocks with the associated plaintext
blocks. It is quite possible to have that situation without knowing
anything of the RNG. A known-plaintext attack is any attack which
capitalizes on this information situation (as opposed, say, to
ciphertext-only).
Known-plaintext is a danger to many cipher systems, because to some
extent it reveals the ciphering transformation. In an additive stream
cipher or conventional OTP, known-plaintext reveals the enciphering
sequence immediately and completely. In a block cipher, it shows what
happens when plaintext is enciphered; it exposes the transformation,
which can be very useful.
Dynamic Transposition is unusual in that knowing the plaintext and the
associated ciphertext does not reveal the enciphering permutation.
The reason for this is that many different bit-permutations will
produce the bit-for-bit exact same transformation between plaintext
and ciphertext. Therefore, having known plaintext does not reveal the
enciphering permutation, and thus cannot be exploited to begin to
expose the RNG sequence.
Note that even if the correct permutation were found, the RNG sequence
which created it would not be exposed to any extent, if
double-shuffling was used to create the permutation. The reason for
this is that double-shuffling would use twice the amount of RNG
sequence as needed for a selection among all possible permutations.
Double-shuffling is literally an arbitrary permutation from a known
state, and then another arbitrary permutation from that to any
possible permutation. Any particular result permutation could be the
result of any possible first permutation, with the appropriate second
permutation, or vise versa. Accordingly, one knows no more about what
sequence was involved than before one knew the correct permutation.
>That works for XOR stream ciphers too. When you do
>know something about the RNG, then a known-plaintext attack against a
>dynamic transposition cipher does not necessarily start by guessing the
>permutation for a single block.
Known plaintext means having one or more blocks for which one knows
both the ciphertext and the associated plaintext, only that. This is
an informational constraint, not an algorithmic direction for attack.
Normally, though, the attack direction is obvious given this
information.
The structure of the RNG is of course known. The content of the RNG
state is expanded from a large random message key. The sequence
produced by the RNG is not known, nor does the cipher allow it to be
exposed.
>With 4096-bit blocks, one block of known plaintext gives you over 4000 bits
>of information about the state of the generator
Not true, as far as I know. Certainly, as a completely unsupported
assertion, it is not believable on faith alone.
Known plaintext simply does not identify the correct permutation
produced by the confusion sequence. It certainly does not identify
the sequence which produced that permutation.
>-- there may be 2^39000
>permutations that give you the same output, but there are 2^43000 possible
>permutations, so you get 4000 bits or so about the state of the generator
>itself,
We need many different permutations, and of course, we get them. We
use a mathematically-proven permutation system, with an RNG which has
sufficient internal state to produce any possible permutation.
Each one of every possible permutation is equally probable. This
exposes no information at all.
The number of different permutations that will produce the exact same
ciphertext block from the same plaintext block is (N/2)! * (N/2)!
The number of possible permutations is N! The ratio between these two
values is the average number of different permutations which produce a
different ciphertext block from the same plaintext block.
This effect does divide the permutation space into "clumps: of
permutations which all produce the same ciphertext block from a
particular plaintext block. But the next block will have a completely
different permutation, a different plaintext, and thus a completely
different clump structure. That is an innocuous effect.
>nd this is only marginally less that you would get with an XOR
>stream cipher and a block of the same size. In this case, though, the
>actual number of plaintext bits you need to make the block might be less
>that 4096.
>
>How useful is this information? As with an XOR combiner, it depends on the
>RNG.
No. That is simply wrong.
With any additive combiner, having known-plaintext reveals the
confusion sequence sent to the combiner exactly, completely and
immediately. If the confusion sequence comes straight from the RNG,
we thus have the exact sequence needed to attack the RNG.
In contrast, with Dynamic Transposition, having known-plaintext
reveals nothing about the RNG sequence, so there is no information
available to attack the RNG.
>he real question is whether or not I can extract a reasonably concise
>statement about the generator given this information, and whether I can
>combine such statements from multiple blocks until I know the generator
>state.
>
>In theory, your combiner is like using the plaintext to select some
>generator bits that you throw away.
No.
>It's probably a good idea for
>amplifying the security of a stream cipher,
No. Dynamic Transposition is a block cipher.
>but it's not provably secure in
>any strong way,
I suspect it is provably secure, and furthermore does not depend upon
unproven mathematical assumptions.
>and there are easier/faster ways to do it that also let you
>choose how many bits to toss (90% is a lot).
I believe there are other unbreakable ciphers.
Still, people do keep talking about the OTP.
Dynamic Transposition gives us a way to achieve believable practical
security beyond that available from a classic OTP, while using keys of
reasonable size.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: A Small Challnge
Date: Sat, 20 Jan 2001 01:28:53 -0500
Benjamin Goldberg wrote in part in message
<[EMAIL PROTECTED]>...
>Mok-Kong Shen wrote:
>[snip]
>> (2) Are you sure that some practically useful D and E[i] and
>> E[j] with E[i]!=E[j] could satisfy your following requirement
>> for arbitrary m in a sufficiently large set?
>>
>> D(E[i](m)) = D(E[j](m)) = m
>
>Hmm, unless I'm mistaken, NTRU keys can fit this definition perfectly.
Ben,
First, part of this message may be addressing your post, part may be
addressing
another message. Sorry for the mixing.
I am sorry that the formal QP (flavour 2) can not guarantee everything
satisfying
it to be 'much' better than a simply public-keying entity. I gave the
impression, I
correct myself here. It in this simple form does not prevent one from
tweaking
something that is 'essentially' nothing more than the untweaked public-key
scheme.
I probably read complexity theory too much. Anything satisfying the
definition of NP
gives interesting basis for a secure system. :) Just kidding.
Is the formal definition too simple? Maybe. If I, for instance, set n to
infinity. But
that may exclude too much. If one thinks this notion is totally useless, he
may be right.
But I think that conclusion is too early. The logic may be sound that if you
find one
bad guy in the world, you will not find one on all seven continents who is
not a thug. :)
I repeat. I take yours with NTRU. But I do NOT take NTRU. I also may
take
something modified similarly with McEliece. Forget about the formal
definition
for a brief moment, and forget about QP being public-keying. Take the
informal,
re-versed version: 1 dekey with two corresponding enkeys that produce
different ciphertext from a same plaintext. Yours fits perfectly. So I take
yours but
not NTRU (for NTRU's spec differs from yours). I DO take yours, serious. No
need for further modification.
You can skip extending yours to the INFINITE case (for reasons obvious)
and
think about its security and its complexity. Some may say that this notion
adds
nothing. I seem to see that NTRU is already roaring along faster. Any
redundancy
that you can remove can be something, can it? Maybe, that is still nothing.
Finally, I am a bit embarrassed. What is public? What is public key?
What is
a public parameter? Anything you make public is part of a public key? If you
publish some thing totally irrelavent to pq, you call that part of the
public key?
Did not know that.
Now with a successful QP scheme, readers may have more to think
about. People from sci.math and comp.theory may get a chance, too, now.
I enjoyed discussing this with you all. Thank you very much.
--- (My Signature)
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 20 Jan 2001 05:45:57 GMT
On Sat, 20 Jan 2001 00:07:26 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Fri, 19 Jan 2001 22:18:40 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>The main lesson is not about double-transposition, but balance. If
>>all we do is double-shuffle, the ciphertext still contains only the
>>symbols present in the plaintext, and that leaks information. By
>>balancing the block, we eliminate that leak.
>
>I missed that too on my first reading; a reply to my initial post by
>Emmanual Goldberg got me to look more carefully and see that.
>
>You are indeed correct: if one processes plaintexts which have equal
>numbers of 0 and 1 bits because of processing, and one produces all
>possible transpositions with, in a sense, 'equal probability', one can
>do as well with transposition as the one-time-pad does with
>substitution.
>
>This is important to note theoretically. I've noted, though, that I
>don't think people will see it as terribly attractive or convenient in
>practice. The ICE block cipher is already a cipher which makes a more
>limited use of transposition in a way that more readily 'fits in' with
>conventional practice, so transposition isn't totally neglected.
Based on long experience, I do not try to predict what people will or
will not see. I just present the material. But if the material does
turn out to gain some acceptance, well, the crypto text authors and
others who have ignored this published work for more than a decade
just may have some 'splainin' to do.
Dynamic Transposition is not just another block cipher, and also not
just an example of a serious transposition cipher.
In practice, Dynamic Transposition is stronger than an OTP, yet uses
keys of reasonable size. That may be of fundamental real interest.
And Dynamic Transposition strength arguments are not based on unproven
assumptions.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
