Cryptography-Digest Digest #561
Cryptography-Digest Digest #561, Volume #14 Fri, 8 Jun 01 03:13:01 EDT Contents: Re: Humor, I Must be a Threat to National Security (Miguel Cruz) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY) Re: DES not a group proof (JPeschel) Re: And the FBI, too (Re: National Security Nightmare?) (Paul Crowley) Re: Simple C crypto (Samuel Paik) Re: Simple C crypto (Samuel Paik) Re: DES not a group proof (John A. Malley) Re: And the FBI, too (Re: National Security Nightmare?) (Paul Rubin) Re: DES not a group proof (Paul Rubin) Re: Some questions on GSM and 3G (Gregory G Rose) Re: DES not a group proof (Paul Rubin) Re: What is a skeleton book? (John Savard) Re: DES not a group proof (Gregory G Rose) Crossposted-To: comp.security.misc Subject: Re: Humor, I Must be a Threat to National Security From: Miguel Cruz [EMAIL PROTECTED] Date: Fri, 08 Jun 2001 05:13:02 GMT David G. Boney [EMAIL PROTECTED] wrote: My frustrations with trying to find a job in government service are summarized in an essay I have posted that is titled, I Must be a Threat to National Security. I have also placed my rejection letters from the CIA and NSA on-line. http://www.seas.gwu.edu/~dboney/security.html Please forgive my bluntness: If those three innocuous rejection letters are enough to make you go off on a web/usenet rant about the government and the evil they do and conspiracies against you, then I can only assume you have at least a slight predisposition for this sort of behavior. Assuming, then, that your qualifications were a match with their requirements and they had someone go out and ask some questions, my guess is that this issue would come out early and they would decide dealing with you wasn't worth their trouble. For future reference, though, I will point out that the screening process for most government positions takes some time to master. Your application is generally reviewed by someone who has very little familiarity with the subject matter of the position. This person sits all day long reading through applications for a number of different jobs, scanning them for matches against lists of required and eliminating factors. If you don't have the required factors, you're in the bin. You have an eliminating factor, you're in the bin. So, if my earlier presumptuous guess about your having left a trail of paranoid rants through your prior academic and work careers is off the mark, here are a couple of tips should you choose to continue your quest for government work: 1) Go read all the books your library has about applying to government jobs. 2) Don't send out 7 or 8 applications and think you can sit back and watch the offers roll in. These places post positions constantly, and they receive bags full of applications. This is not the little furniture shop down the road. When you've sent out 100, then you're on your way. When you get the process down (completed OF-612 in Word/Acrobat, a full array of KSA snippets in store), the applications shouldn't take more than a few minutes each. Your biggest worry should be postage. 3) Call the contact person listed in the position announcement and ask for advice on why you were rejected. Be polite and friendly; just explain that you're trying to improve your chances in the future. 4) If anything in your application sounded even remotely like your web site, then get a friend to proofread for tone and overall intelligibility. The web site reads like you hired the Unabomber to ghostwrite, and paid him in vodka. miguel -- Hit The Road! Photos and tales from around the world: http://travel.u.nu -- From: Tim Tyler [EMAIL PROTECTED] Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) Reply-To: [EMAIL PROTECTED] Date: Fri, 8 Jun 2001 05:03:57 GMT Tom St Denis [EMAIL PROTECTED] wrote: : Tim Tyler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... : Tom St Denis [EMAIL PROTECTED] wrote: : : Tim Tyler [EMAIL PROTECTED] wrote in message : : Tom St Denis [EMAIL PROTECTED] wrote: : : : Tim Tyler [EMAIL PROTECTED] wrote in message : : : Tom St Denis [EMAIL PROTECTED] wrote: : : : : Tim Tyler [EMAIL PROTECTED] wrote in message : : Well, strictly speaking it seems likely that nothing can encrypt an : : infinite plaintext because the universe will burn out while it tries. : : : : That aside, memory does not stop stream cyphers from encrypting large : : messages, since the stream doe snot need to be stored all at once. : : Why would you think otherwise? : : : Because a finite state machine can only be in a finite number of states. : : Why do you need to have more than a million states to act as a stream : cypher on long messages? : If you reuse the PRNG output (replace PRNG with stream cipher if you
Cryptography-Digest Digest #561
Cryptography-Digest Digest #561, Volume #13 Fri, 26 Jan 01 17:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: Dynamic Transposition Revisited (long) ("Tony T. Warnock")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions (JimD)
Re: Echelon in Asia. (JimD)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Fitting Dynamic Transposition into a Binary World (Terry Ritter)
From: AllanW [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:49:45 GMT
AllanW [EMAIL PROTECTED] wrote:
As I understood the filler bits to work, the data would
look like this before the transposition begins: if the
data had more 0-bits than 1-bits, it would take the form
XXXX 00..00 11..11
where X bits represent the data, and then there are 1-8
0-bits followed by 1 or more 1-bits.
I see now that I should have said, 1-7 0-bits and then
1 or more 1-bits.
If the data has
more 1-bits than 0-bits, simply reverse the filler:
XXXX 11..11 00..00
this time using 1-8 1-bits and then 1 or more 0-bits.
And here I should have said: 1-7 1-bits and then 1 or
more 0-bits.
[EMAIL PROTECTED] (Terry Ritter) wrote:
That does not seem to be the way I did it.
That's what I got out of it. Not word-for-word, of course.
I don't understand having both 0's and 1's balancing bytes.
Surely you do...? It is so that we can always remove the balancing
bytes without removing any meaningful data.
What if the block has 16 more 0-bits than 1-bits, but the last byte
of plaintext is 0x0F? You could balance the block by adding 2 more
bytes of 0xFF, but then after decryption we could not identify the
first byte of filler (as you say below: the mixed byte must be
mixed to be a flag).
If we have an excess of 0's, we want any full balancing bytes to
be all 1's, with the mixed byte being what it needs to be. Since
the mixed byte must be mixed to be a flag, it cannot balance a
full 8 bits, but at most 6 (1000 is an excess of 6 0's).
Yes, exactly. And then following this, we have bytes with all
1-bits.
I suppose that what I wrote above (1-7 0-bits, followed by 1 or more
1-bits) was stronger than absolutely needed. The mixed byte could be
randomly mixed as well, so instead of using 1000- we could just
as easily have used 0001-. Is there any reason to do this
randomly? If not, then my description fits the same pattern but is
easier to describe.
Another way to say this is to show what the filler
would look like for various imbalances. Here I'll
assume that the data has more 0-bits than 1-bits; use
the complement if the opposite is true.
If there are B more 0-bits than 1-bits, then the
filler looks like (in hex):
B=0 0F
B=2 1F
B=4 3F
B=6 7F
B=8 0FFF
B=10. 1FFF
B=12. 3FFF
B=14. 7FFF
B=16. 0F
B=18. 1F
B=20. 3F
B=22. 7F
B=24. 0FFF
...and so on.
Looks right.
Good, because in every case the first balance byte starts
with 1-4 0-bits followed by 1-7 1-bits.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
--
From: "Tony T. Warnock" [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 14:08:19 -0700
Reply-To: [EMAIL PROTECTED]
The efficiency of the balanced pre-substitutions can be improved by
taking more bits. Of course a table-lookup gets too big rather quickly.
Output Input
Size Length Expansion
6 450.0%
8 6 33.3%
10 7 42.9%
12 9 33.3%
14 11 27.3%
16 13 23.1%
18 15 20.0%
20 17 17.6%
22 19 15.8%
24 21 14.3%
26 23 13.0%
28 25 12.0%
30 27 11.1%
32 29 10.3%
64 60 6.7%
128 124 3.2%
256 251 2.0%
512 507 1.0%
1024
Cryptography-Digest Digest #561
Cryptography-Digest Digest #561, Volume #12 Tue, 29 Aug 00 01:13:00 EDT
Contents:
Re: 4x4 s-boxes (Mack)
Re: 4x4 s-boxes ([EMAIL PROTECTED])
Re: blowfish problem ("Bruce G. Stewart")
Re: Future computing power (Anthony Stephen Szopa)
Re: Future computing power (Anthony Stephen Szopa)
Re: Future computing power ("CMan")
Re: Future computing power (Anthony Stephen Szopa)
Re: Future computing power ("CMan")
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 4x4 s-boxes
Date: 29 Aug 2000 04:10:27 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Mack) wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Mack) wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Mack) wrote:
Has anyone analyzed the number of s-boxes
that could be used for Serpent?
more specifically, serpent s-boxes don't appear
to have particularly good avalanche characteristics.
The criteria seem logic but is it possible that
the serpent s-boxes might have been chosen
using stricter criteria?
My "serpent_sboxes" on my website are good candidates for
replacement
sboxes if needed.
Tom
--
http://www.geocities.com/tomstdenis/
I have looked at your program to produce s-boxes.
My question is of a more general nature. ie. how many
s-boxes actually meet th Serpent criteria and could
we add additional criteria to the given ones that would
improve the characteristics without producing a null
set of s-boxes.
for example. 4x4 s-boxes having the forward and
inverse both maximum non-linearity and meeting
sac are rare at best and non-existent at worst.
Does anyone know if such s-boxes exist?
The sboxes I made have are completely non-linear i.e their "bent",
they
fullfil SAC and BIC to the order-3. Other then a DPmax of four they
are perfect sboxes.
Finding them is hard, it took about 8 hours of random searching with
sboxgen. I am in the middle of making another set right now
actually.
Overall about 1 in 100 million are ok. This is really rough since I
didn't keep track of the totals. This means about 1 in 2^27 are ok,
and since there are only 2^44 possible sboxes, about 2^17 should
exist.
Tom
It is relatively easy to find s-boxes that meet the SAC, BIC and non-
linearity
requirements in the forward direction. there are only 1368 boolean
functions
of four variables that meet the non-linearity requirement of 4 and
SAC. There
are even less that meet the requirement of 6.
I don't get the "requirement of 4". Generally you perform a WT or
FWT. In my case I chose th WT and I get -4/4 which is the best you can
get for a "bent" sbox.
You can also use the maximum hamming weight to a linear function
which is quicker to calculate. Extending this to an s-box is a bit
trickier but very useful.
bent is usually used to refer to functions which have non-linearity
which is maximum. They only occur on functions of 2n variables
and are not balanced. You appear to be refering to nearly bent
functions.
Note that for a permutation to be bent it is not bijective. I am
interested in
Bijective 4x4 s-boxes with equally good properties in both directions.
Actually any bijection function will have an inverse with the same
linearnity. (this is really simple to prove too).
{3,13,6,14,2,0,15,12,1,5,10,7,4,11,8,9};
This is taken from Construction of DES-like S-boxes based on
Boolean functions satisfying the SAC by Kwangjo Kim.
Which are the S^2 s-boxes. This is line 2 of the S3-box.
The definition of non-linearity is the hamming distance
from the closest affine function. (Ruepple's criterion)
This has non-linearity of 4 and satisfies the SAC for
each of the boolean functions that are used to construct
it.
Its inverse
5 8 4 0 12 9 2 11 14 15 10 13 7 1 3 6
has nonlinearity of the constituent boolean functions
2 4 2 4
and none of the constituent functions satisfy the SAC.
So no the inverse does NOT have the same non-linearity.
proof by counter example
Have you found any s-boxes that are bijective (invertible) and
satisfy the nonlinearity of 4 and SAC in both directions?
Yes, my serpent sboxes. They have a WT of -4/4 (doesn't matter which
direction), a differntial xor-pair max of 4, fulfill SAC and BIC to
order 3 (which means no set of 3 4x1 outputs can be linearly related
via xor)
"Good S-boxes are easy to find" by Adams and Tavares
says that there are 60 sboxes that meet SAC, non-linearity,
and BIC and are bijective with both the box and its inverse
meeting these properties. They list three S-boxes but they aren't
the ones that meet these criteria.
Does anyone actually have a list of the s-boxes?
Um this is all wrong. There are 16! ~ 2^44 possible 4x4 sboxes, of
which many are nonlinear and differentially secure. For example the
fol
Cryptography-Digest Digest #561
Cryptography-Digest Digest #561, Volume #10 Fri, 12 Nov 99 23:13:03 EST
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: Ultimate Crypto Protection?
Re: Ultimate Crypto Protection?
Re: Proposal: Inexpensive Method of "True Random Data" Generation (john baez)
Re: Proposal: Inexpensive Method of "True Random Data" Generation
Re: Ultimate Crypto Protection?
Re: Proposal: Inexpensive Method of "True Random Data" Generation
([EMAIL PROTECTED])
Some basic facts - internet and crypto ("Markku J. Saarelainen")
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 13 Nov 1999 01:30:02 GMT
On Fri, 12 Nov 1999 02:48:38 GMT, in 80fv65$rvt$[EMAIL PROTECTED], in
sci.crypt [EMAIL PROTECTED] wrote:
Terry Ritter wrote:
[EMAIL PROTECTED] wrote:
[...]
In my proposals, it is has been, and still is, unnecessary to
authenticate the cipher choice. No authentication mistake is possible
with respect to cipher choice. The ciphers themselves must be
authentic, but that is not a cipher-change protocol issue.
I'm not sure what you mean. The adversary may modify the
messages that influence the choice of cipher. It is the
authenticity of these messages that is at issue, and the
handling of these messages constitutes the cipher selection
protocol. I'll show below why authentication is necessary.
There is something seriously wrong with a cipher system which allows
messages to be substituted by anyone who happens to have a non-secret
public key. This is an issue in public-key cryptography which is not
normally present in secret-key cryptography.
In secret-key cryptography, if more than two users share a key, it is
quite clear that multiple source options exist for any message which
is sent. This is clear. The issue of deception, then, is due to
public-key cryptography, and so must be (and generally will be)
handled in any system which uses that technology.
Having a system where anyone can masquerade as anyone else is simply
insane. Or perhaps you are assuming that the issue *cannot* be
handled in public-key cryptography, which would be an interesting
result.
This is not an issue for the cipher-change protocol. It *is* an issue
which must be considered in every public-key design.
[...]
So you've described the protocol: "In my proposal, one
end sends a list; the other selects from that list".
You've been clear that when a side sends the list,
such communication is and under a cipher. Now I'll
describe the attack on a system entirely consistent
with your description.
Suppose all parties are given an authentic certificate
for Bob's public key. Alice sends her list of ciphers
to Bob, encrypted under Bob's public key. Fred blocks
the message from Alice and substitutes his own list
consisting of one cipher he knows to be on Bob's list.
Bob, as the description specifies, selects a cipher
from the list.
So just as you described, the negotiation is protected
by a cipher.
While you claim to have assumed that the negotiation is "protected,"
in reality you have not made any such assumption. Any cipher system
which allows anyone at all to pretend they are the other party to a
particular communication is inherently insecure. The cipher change
protocol is hardly the issue.
Just as you wrote "In my proposal, one
end sends a list; the other selects from that list".
Thus Fred has achieved the chosen cipher attack, within
the protocol you described. As you noted, we have to
assume the initial cipher is effective; ciphers provide
privacy and the example above grants that the cipher
is effective.
The initial ciphering system was, by your description, remarkably
ineffective. That seems to be an issue for the cipher system design,
rather than any particular cipher, or any plaintext protocol under the
cipher. Again, that issue does not come up when we have a single pair
of nodes operating under secret key. The issue for public-key
cryptography, then, is to provide a protocol which does provide
security. And when that is provided, the cipher-change protocol I
proposed will be fine, perhaps with some additional protection, which,
as you have previously noted, was suggested by "others."
You seem to have several big problems here, the first being the
possibility that I missed something, and so deserve your castigation.
More like: you missed something and so should recognize
it now and fix it.
No, you found something which is probably well-known in public-key
design, and have attempted to use it to fault a level at which it does
not apply.
W
Cryptography-Digest Digest #561
Cryptography-Digest Digest #561, Volume #9 Tue, 18 May 99 18:13:02 EDT
Contents:
Re: prime numbers and the multplicative inverse ([EMAIL PROTECTED])
Re: Can Somebody Verify My DES execution? (wtshaw)
Re: symmetric boolean functions (Medical Electronics Lab)
Re: breaking xor encryption? (Frank Gifford)
Re: Musing on and Factoring of a (special) 782-bit Modulus
([EMAIL PROTECTED])
ALF'S PRIVACY MAIL DROP (ALF)
Testing my encryption code (Cory C. Albrecht)
Re: ciphersaber-2 implementation help? ([EMAIL PROTECTED])
How to understand/program more advanced crypt. (Mika Stenberg)
Re: prime numbers and the multplicative inverse (John Savard)
Re: prime numbers and the multplicative inverse (John Savard)
Re: Can Somebody Verify My DES execution? (Thomas Pornin)
Re: prime numbers and the multplicative inverse (Chris Monico)
Re: prime numbers and the multplicative inverse (Chris Monico)
Re: where can i find a frequency list? (RREYNARD)
Re: How to understand/program more advanced crypt. ("Steven Alexander")
Re: Need to design basic authentication system ("Tim Mavers")
Re: True Randomness The Law Of Large Numbers ([EMAIL PROTECTED])
Quadibloc III errors corrected (John Savard)
From: [EMAIL PROTECTED]
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 1999 16:09:47 GMT
snip
It's ok the question was answered in private.
Tom
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Can Somebody Verify My DES execution?
Date: Tue, 18 May 1999 12:23:49 -0600
In article 7hrk7q$8do$[EMAIL PROTECTED], [EMAIL PROTECTED] (Thomas Pornin) wrote:
key: 01234567 89abcdef
plain : 01234567 89abcde7
cipher : c9574425 6a5ed31d
Having written dozens of different encryption programs, I know that more
comprehensive evaluation is needed.
Depending on the nature of a mistake, it can affect the results to
different degrees, even being obscure enough only to occur most
infrequently. Now, this can really drive you up the wall when it
occurs. Similiarly, finding a solution to such a bug is most rewarding.
Perhaps I've been lucky, many applications have straight forward mistakes
that you correct as you iron out the sourcecode. Sometimes their are
seemingly insolvable ones that you need to deal with. The best tactic is
to put the thing away until your brain clears of it so that you can take a
fresh start. In time, any acknowledged error can be conquered, but you
have to make it come up before you can fix it.
For DES or any other ready algorithm, the necessity is to exercise your
version and comparative with the results of another's implementation as
much as possible.
For a new algorithm, I like to compare intermediate results between
encryption and decryption processes.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
--
From: Medical Electronics Lab [EMAIL PROTECTED]
Crossposted-To:
sci.chem,sci.econ,sci.image.processing,sci.electronics.design,sci.physics,sci.physics.fluid-dynamics,sci.math
Subject: Re: symmetric boolean functions
Date: Tue, 18 May 1999 12:56:56 -0500
Hankel O'Fung wrote:
Does anybody know what are the applications of symmetric
boolean functions and shift-invariant boolean functions of
n (=3) boolean variables?
Here, a function f: {0,1}^n -- {0,1} or f: {0,1}^n -- (0,1)
is called symmetric if f(x1, ..., xn) = f(sigma(x1), ..., sigma(xn))
for any permutation sigma, and is called shift-invariant if
f(x1, x2, ..., xn) = f(x2, x3, ..., x1) = ... = f(xn, x1, x2, ...,
x_{n-1}).
I am particularly interested in any applications of these functions
with n=3. Thanks in advance.
The Trace() function maps {0,1}^n - (0,1) over GF(2^n). If you
use a normal basis, the output is shift-invariant. I don't understand
what sigma does. If you use a polynomial basis, the Trace() is
not shift invariant, but I can't say I understand "symmetric".
Patience, persistence, truth,
Dr. mike
--
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: breaking xor encryption?
Date: 18 May 1999 14:05:39 -0400
In article 7hqhuv$p08$[EMAIL PROTECTED],
Spiffy [EMAIL PROTECTED] wrote:
How does one break the simple xor encryption program?
...
What if the person compresses the plaintext and get a real random key?
Breaking such a system involves guessing some of the plaintext at a chosen
spot, determining what the key must be for that spot, applying that key
some distance away in the message (by the length of the key) and seeing
if decrypting at the new spot produces 'plaintext'.
This is much easier if the message is (say) English. The compression makes
the work tougher, but not impossible.
