Cryptography-Digest Digest #547, Volume #13 Thu, 25 Jan 01 06:13:00 EST
Contents:
Re: Snake Oil (Anthony Stephen Szopa)
Re: Some Enigma Questions -- 150*10^18 settings? (Frode Weierud)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Creating a self extracting encrypted exe? ("Vladimir Katalov")
Re: Secure game highscore server (Niklas Frykholm)
Re: Barrett Modular Reduction with large x (Bryan Olson)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Re: Cryptographic Camouflage (Mok-Kong Shen)
Re: Echelon in Asia. (Arturo)
Re: Snake Oil (Richard Heathfield)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Snake Oil
Date: Wed, 24 Jan 2001 23:54:02 -0800
Paul Rubin wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> writes:
> > Take my encryption software. Give it a go. Prove to us you can
> > break it. Give us your most tenuous reasonable explanation on how you
> > would go about it.
> >
> > Or do you just talk about snake oil having never known what it really
> > is?
>
> That's another standard whine of the snake oil salesman, saying "how
> can you know it's bad unless you try it?". Of course, you have to
> expend your own resources / risk your own health in order to try it,
> with no compensation from the salesman if (as you suspected) the
> product is no good. In typical cases the salesman even wants you to
> pay for the product before you can test it, though that may not be
> going on here. In either case, the salesman is claiming you're remiss
> unless you're willing to work for him for free. It's not an
> impressive argument.
>
> Anthony: you are not offering to let people test your cipher under the
> same conditions that 3DES can be tested. Specifically, 3DES protects
> millions of dollars of live traffic every day, so it's worth that much
> for someone to be able to crack it.
>
> How many million dollars are you offering to anyone who cracks your
> cipher? That's the test that 3DES passes every day, that you have not
> offered to submit your cipher to.
>
> After all, some of us are professionals here. That means if we do
> cryptography for someone, we expect to get PAID for it.
Speaking of money( at least indirectly):
If you can believe that I did indeed invent the anti-piracy protocol
basis upon which MS is now touting as their latest "innovation"
while almost certainly having no legally defensible or legally
enforceable rights to it, what does this say about MS taking
advantage of probably most of the major software producers by
having them sign non disclosure agreements and possibly even
signing contracts to commit to exclusive usage of MSs anti-piracy
"innovation" all the while MS knew that their "partners" didn't have
a clue about me?
I bet they have been chuckling quite a bit about it.
I can already begin to hear the drone of masses of computer software
company stockholders gnashing their teeth.
"Tai Chi is just a path;
it is not the way." -- ASS 2001
------------------------------
From: [EMAIL PROTECTED] (Frode Weierud)
Subject: Re: Some Enigma Questions -- 150*10^18 settings?
Date: 25 Jan 2001 08:34:33 GMT
Reply-To: [EMAIL PROTECTED]
wint <[EMAIL PROTECTED]> writes:
>How is the "150 million trillion" (150 * 10^6 * 10^12 = 1.5*10^20)
>computed? My math gives a much lower number -- too low to be
>correct. Here goes.
>Three rotors, with 26 letters:
> 26*26*26 = 17,576 starting positions
>Three rotors selected from 5:
> 5*4*3 = 60 rotor choices
>Plugboard with 13 wire pairs (26/2, wild guess here):
> 13! = 6.2 billion ways to plug in the wires (wow!)
This is where the error is. First of all the "150 million trillion"
is calculated using 10 Steckers which gives a greater value for the
possible Stecker combinations than 13. Actually 11 Steckers give the
maximum number of combinations.
The way to compute this value is first to select the number of
Stecker plugs that 10 Stecker connections will use. One Stecker connection
will occupy 2 plugs, 10 Stecker will occupy 20 and s Stecker will occupy
2s. These 2s plugs can be selected from a total of 26 plugs which gives:
(26) 26!
( ) = ----------------
(2s) (2s)! * (26-2s)!
Within this selected group of plugs the first Stecker end can select
any of the 2s plugs the other end has a choice of (2s-1), the second
Stecker has a choice of (2s-3) plugs to complete the connection, third
Stecker (2s-5) etc.
The total expression will then be:
(26) 26!
( ) * (2s-1) * (2s-3) * (2s-5) * ... * 1 = ----------------
(2s) (2s)! * s! * 2^s
Using this formula the number of combinations for 10 Steckers will be
about 1.5 * 10^14 which, if you divide with your number of 6.2 * 10^9,
will give you the missing factor of about 24,190.
>Taking the product:
> 17576 * 60 * 6.2 * 10^9 = 6.5 * 10^15
Here I should like to add one small curiosity which concerns rotor
machines which are using Enigma stepping, odometer-like or cyclometric
stepping but with a middle wheel turnover anomaly. To understand this
part better you should read David Hamer's Cryptologia article:
"Enigma: Actions Involved in the `Double Stepping' of the Middle Rotor",
Cryptologia 21(1), January 1997. It is also available in PDF format from
David's Web site at:
http://www.eclipse.net/~dhamer/download.htm
When you want to encipher with the Enigma you will set the machine to
a given position which is usually called the prestart, because the rotors
step before the enciphering takes place. Hence the real start for
enciphering a message is on the rotor postion following the prestart. Due
to the stepping anomaly there are some prestarts which will result in
identical start positions. For the German Army/Air Force machines which
only used single notch rotors there are 26 * 25 = 650 such prestart
positions that result in identical start positions. Therefore the are
only 17576 - 650 = 16926 essentially different Enigma starting positions.
On the other hand the period of the machine is 26 * 25 * 26 = 16900.
Frode
--
Frode Weierud Phone : +41 22 7674794
CERN, SL, CH-1211 Geneva 23, Fax : +41 22 7679185
Switzerland E-mail : [EMAIL PROTECTED]
WWW : home.cern.ch/frode/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Thu, 25 Jan 2001 09:05:10 GMT
On Wed, 24 Jan 2001 23:47:34 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt "John A. Malley"
<[EMAIL PROTECTED]> wrote:
>[...]
>I appreciate the difference between "goal" and actual achievement as you
>explained in your response. I thought you were asserting DTC achieved
>permutation selection for each and every block independent from other
>blocks, and with equal probabilities, due to your previous post in this
>thread, where it's stated
>
>> There are (N!)**S possible sequences of permutations, of sequence
>> length S.
>
>I understood this statement to mean that each N-bit block gets one of N!
>possible permutations applied to it, independent of any preceding or
>following block, for S blocks that make up the message.
Basically, that response was trying to present a correct count for
permutation strings, instead of (as I recall) the (N!)! thing, since
there is no such permutation of permutations. It is an expectation
and a goal. In practice, I do think we would have a very difficult
time distinguishing reality from that ideal.
>Thank you for replying to my posts, thanks for the dialogue. I do hope
>we will continue to correspond.
Great. 'nuff said.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Vladimir Katalov" <[EMAIL PROTECTED]>
Subject: Re: Creating a self extracting encrypted exe?
Date: Thu, 25 Jan 2001 12:27:18 +0300
Paul Pires wrote in message <[EMAIL PROTECTED]>...
>And the all time favorite. WinZip.
NEVER use it to encrypt sensitive data. ZIP (and especially WinZip)
encryption is really weak. Very fast brute-force and dictionary attacks
can be implemented; and I think you know about known-plaintext
attack which allows to decrypt the file in a few minutes even if the
password is very long.
Have a look at WinRAR (http://www.rarsoft.com). Brute-force attack
allows to try only a few hundred passwords per second; and
known-plaintext attack is not applicable at all. Besides, it uses much
better compression algorithm (and can create SFX archives, too).
--
Sincerely yours,
Vladimir
Vladimir Katalov
Managing Director
Elcom Ltd.
Member of Association of Shareware Professionals (ASP)
Member of Russian Cryptology Association
mailto:[EMAIL PROTECTED]
http://www.elcomsoft.com/adc.html (Advanced Disk Catalog)
http://www.elcomsoft.com/ems.html (Email Management Software)
http://www.elcomsoft.com/prs.html (Password Recovery Software)
------------------------------
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: Secure game highscore server
Date: Thu, 25 Jan 2001 09:25:29 +0000 (UTC)
In article <94n4it$fmd$[EMAIL PROTECTED]>, Splaat23 wrote:
>Now that I think about it, in the age of the Internet, we should be able to
>invisibly auto-update the software at a given rate that exceeds the
>capabilities of most hackers. The key is to maximize a (hacker work) /
>(programmer work) ratio, then estimate the amount of time, given the degree of
>protection, it would take a hacker to break it.
I'm not sure auto-updates would buy you that much. If you want the updates
to be automatic, you cannot make any major changes to the program logic.
You will only be able to shift things around a bit, locally swap the order of
instructions where it doesn't matter etc. If your changes are automatic the
attacker will probably be able to write an automatic program for analyzing
them.
I've also heard that this idea has already been patented.
// Niklas
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Barrett Modular Reduction with large x
Date: Thu, 25 Jan 2001 09:29:22 GMT
[EMAIL PROTECTED] wrote:
> Hi. I'm messing with RSA in JavaScript and found that Barrett's
> modular reduction (from the Handbook of Applied Cryptography,
> CRC Press) is an excellent shortcut, speeding my modular
> exponentiation by about a factor of 10.
>
> The trouble is, the algorithm is only specified for x < b ^ 2k
>
> How can I change the algorithm to use a larger mu, something
> around b ^> 4k?
Hmmm, I think it's straightforward, but can you tell why
you need this? Working modulo n shouldn't require repeated
calculations with anything more than twice the length of n.
But since you asked...
You can repeatedly use Barrett reduction to reduce the size
of the residue by k words. That is, if x < b^(ik), you can
find x' such that:
x' is congruent to x mod n,
x' < b^((i-1)k)
For example, if x < b^7k. The top 2k words are
floor(x/b^5k), and the bottom five are x mod b^5k. Trivially:
x = floor(x/b^5k) * b^5k + (x mod b^5k)
We can use Barret reduction (as described in HAC) to reduce
the top 2k words modulo n. Say,
z = floor(x/b^5k) mod n.
Since,
floor(x/b^5k) * b^5k + (x mod b^5k) = x
we know that,
z * b^5k + (x mod b^5k) is congruent to x mod n.
Also note that z * b^5k + (x mod b^5k) is at most one bit longer
than b^6k. Thus we can subtract n*b^5k zero to two times to
find an x' such that x' < b^6k and x' is congruent to x mod n.
So a single Barrett-reduction, plus some shifts, adds and
subtracts, has moved us from an x that was seven times the
length of n, to an x' that is six times the length of n, and
it's the same modulo n. Another round gives us an x'' at
most five times the length of n, and so on.
Alternately, you could work with a longer u to find a longer
and more accurate q3. Think of u as a scaled inverse of n,
and q3 as an approximation of x/n.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Thu, 25 Jan 2001 10:57:56 +0100
Terry Ritter wrote:
>
> In a sense, I guess the question is asking: "Is bit-balancing worth
> doing?" As I recall, the bit-balancing part is not a major overhead.
> The major cost is the shuffling -- for each bit-element we have to
> step the RNG, do nonlinear processing, fold and mask for the shuffling
> routine, which itself has to handle range reduction, and finally do a
> bit-exchange. So there would seem to be little advantage in leaving
> the bit-balancing out.
>
> The only reason for using this cipher is if we can believe that it is
> effectively unbreakable. We don't want to scrimp on strength.
As I also mentioned previously, cost of permutation at
the bit level (as against using larger units) could be
a (practical) issue but that doesn't in my view preclude
its usefulness, for there are (many) situations where one
is not heavily restricted by processing cost, I believe.
If one permutes bits, then balancing shields the
information about the proportion of 0/1 bits and, since
the expansion is small as you have argued, should be
advantageous. I like to repeat my point, though, about
the 'connection' between balancing and predictability of
PRNG. Note, for example, that one need even not apply an
integral number of the process of Durstenfeld. One could
do e.g. one and one half permutation, i.e. stopping the
second permutation in its middle. (One could, for example,
use a parameter to determine that, such that the length of
the PRNG sequence used is also unknown to the opponent.)
So from the result of permutation to deduce the sequence
of the output of the PRNG can be fairly difficult, quite
independent of the pattern bit string being permuted.
Finally, I would like to say that part of the discussions
on your DT is not about its 'practical' security (i.e.
whether it is effectively unbreakable) but about whether
it could offer 'perfect' security (this is one of the
points that John Savard raised and doubted, if I understand
correctly).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Thu, 25 Jan 2001 10:57:50 +0100
Darren New wrote:
>
> Mok-Kong Shen wrote:
> > I haven't looked at the detailed document. But the formulation
> > of the short description appears indeed to be puzzling. It
> > seems to claim that, since entering something (whether right
> > or wrong) into the device and there always comes out something,
> > an outsider can't know from this fact (alone) whether what was
> > entered is correct or not. But that's a trivial, isn't it?
>
> From my reading, the idea was to protect a private key that's encrypted with
> a passphrase. There would be a checksum on the decrypted key that says you
> decrypted it properly. A minor typo would lead to a broken checksum, so you
> know it's a typo, and you don't try to use it. But there might be zillions
> of invalid passphrases, thousands of "pseudo-valid" passphrases, and only
> one valid passphrase. If you did an offline brute-force search for a
> passphrase, you'd be much more likely to find a pseudo-valid passphrase than
> the single valid one. Then you try to use it online. *That* gets you
> immediately locked out.
>
> I.e., it looks like it's protecting against offline searches of passwords
> you can only truely verify online.
>
> Of course, that's just my interpretation. Read the actual patent for what
> they're actually covering.
Thank you very much. For, trusting that you are right, I don't
think I would spend time to study the detailed document.
So it seems that it is virtually the 'employment' of a checksum
that gets patented. When I was in school, solving some systems
of linear equations by hand, my teacher told me it is a good
idea to use checksums. I wonder whether in the mean time that
idea has also been patented by somebody. BTW, does anyone
know if CRC, which has important applications in practice,
is patented?
It is indeed sad that plenty of trivialities, like rotation
(of Hitachi), get patented. (Fortunately Rijndael is not in
conflict with any such patents, otherwise the majority of
crypto users of the future would have a 'little' problem.)
That perhaps explains the patent statistics of last year,
where IBM got 2922 new patents, NEC 2034, Canon 1897, Samsung
1442 and Lucent 1415. For it seems unlikely that they could
have employed a very large number of people of the calibre of
an Edison.
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Arturo <[EMAIL PROTECTED]=NOSPAM>
Subject: Re: Echelon in Asia.
Date: Thu, 25 Jan 2001 10:09:00 +0100
On Wed, 24 Jan 2001 19:52:39 GMT, [EMAIL PROTECTED] (Abe Lin) wrote:
>Hi, forum,
>We've been seeing a bit about echlon, but I haven't heard anything
>in Asia yet. Given Chinese Government's nature, they'd really surprise
>me if they don't have one.
>
>Anyone?
>
It read it somewhere there�s an Echelon station in Japan, someplace
called Misawa or similar. If you mean signal surveillance, I doubt there�s a
single government that does not do, or try, it one way or another.
------------------------------
Date: Thu, 25 Jan 2001 11:45:25 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Snake Oil
Anthony Stephen Szopa wrote:
>
> Paul Rubin wrote:
> >
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> writes:
> > > Take my encryption software. Give it a go. Prove to us you can
> > > break it. Give us your most tenuous reasonable explanation on how you
> > > would go about it.
That's a request for cryptanalysis.
<snip>
> >
> > Anthony: you are not offering to let people test your cipher under the
> > same conditions that 3DES can be tested. Specifically, 3DES protects
> > millions of dollars of live traffic every day, so it's worth that much
> > for someone to be able to crack it.
> >
> > How many million dollars are you offering to anyone who cracks your
> > cipher? That's the test that 3DES passes every day, that you have not
> > offered to submit your cipher to.
> >
> > After all, some of us are professionals here. That means if we do
> > cryptography for someone, we expect to get PAID for it.
>
> Speaking of money( at least indirectly):
>
> If you can believe that I did indeed invent the anti-piracy protocol
> basis upon which MS is now touting as their latest "innovation"
> while almost certainly having no legally defensible or legally
> enforceable rights to it, what does this say about MS taking
> advantage of probably most of the major software producers by
> having them sign non disclosure agreements and possibly even
> signing contracts to commit to exclusive usage of MSs anti-piracy
> "innovation" all the while MS knew that their "partners" didn't have
> a clue about me?
>
> I bet they have been chuckling quite a bit about it.
>
> I can already begin to hear the drone of masses of computer software
> company stockholders gnashing their teeth.
You haven't answered the question. In fact, you have gone out of your
way to avoid answering the question.
Here are the specific questions that people want answered:
1) will you produce source code for your encryption algorithm, to enable
cryptanalysis to be performed conveniently? (Rest assured that there are
plenty of people with the skill to reverse engineer algorithms from
disassembled binaries, but it's an annoyance with which one should not
trouble cryptanalysts.)
2) are you offering any compensation for cryptanalysts' time and effort?
I expect the answer to 2) is "no", but I don't suppose that will matter
very much. If you do post your source code, I suspect a few crippies
here will have a go at cracking it, just for the laughs.
If the answer to 1) is "no", however, then your request for
cryptanalysis is bogus, and we must conclude that your product is bogus
too.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
** 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
******************************