Cryptography-Digest Digest #301, Volume #13 Sun, 10 Dec 00 03:13:00 EST
Contents:
Re: DES_BCE64 (Tom St Denis)
Re: Custom Encryption Algorithm ("Paul Pires")
Re: EDDF: the intended audience (Roger Schlafly)
Re: EDDF: the intended audience (John Savard)
Re: Custom Encryption Algorithm (John Savard)
Re: How to embed a key in executable code? ("Matt Timmermans")
Re: wrapper code (Benjamin Goldberg)
Re: Smart Card vs 1.44 Disk (Benjamin Goldberg)
Panama question (Benjamin Goldberg)
Re: Toy cipher question (Benjamin Goldberg)
Simpler toy cipher in better psuedocode (Benjamin Goldberg)
Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary
specification and SDK released (Benjamin Goldberg)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,list.cryptography
Subject: Re: DES_BCE64
Date: Sun, 10 Dec 2000 01:17:27 GMT
In article <90uirj$6m9$[EMAIL PROTECTED]>,
"TacTic" <[EMAIL PROTECTED]> wrote:
> I have been asked for information on DES_BCE64 by a friend in the Gov
so I
> only asume that is the righ way round??? Any info would be of help.
Sorry I don't know what BCE is. Perhaps Binary-Counter-Encryption?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Sat, 9 Dec 2000 17:53:47 -0800
Paul Schlyter <[EMAIL PROTECTED]> wrote in message
news:90tfkb$j7n$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> David Schwartz <[EMAIL PROTECTED]> wrote:
>
> > Phil Massimi wrote:
> >
> >> Ok, I'm no expert in cryptography... I'm a simple software developer.
> >> However, I'm beginning to take an interest in it. I put together my first
> >> encryption algorithm for a little custom made chat program of mine, and
> >> wondered if anybody would be interested in trying to crack it. There are
no
> >> keys... simply a formula to encrypt a text string, and another formula to
> >> convert it back to text again.
> >
> > If there's no key, there's nothing to crack. One cracks an encryption
> > algorithm by finding the key.
>
> Oh -- so if there's no key, the encryption becomes uncrackable? <g>
I made one like that. I called it WOM for write only memory. It's
so secure, you can't even crack it with the key!
Paul
>
> --
> ----------------------------------------------------------------
> Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
> e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
> WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
====== 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: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: EDDF: the intended audience
Date: Sat, 09 Dec 2000 18:50:13 -0800
denis bider wrote:
> In five years, we will either be standardised on canonical XML with
> its inherent disadvantage of being text-based, or something like EDDF
> will take over. I think there is a fair probability that canonical XML
> is what will actually happen. However, I am convinced that XML is not
> by far the optimal choice; so, what I am doing is trying to let people
> know that there is an alternative.
>
> The alternative is called EDDF, there is a free ANSI C parser, there
> is a nice C++ front-end, and it has potential to be everything that
> XML is, and much of what it is not. So there.
Well good luck, but I can't see huge numbers of people switching
from XML to EDDF because you have a free parser.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: EDDF: the intended audience
Date: Sun, 10 Dec 2000 04:43:03 GMT
On Sat, 09 Dec 2000 21:03:51 GMT,
[EMAIL PROTECTED] (denis bider) wrote, in
part:
>its inherent disadvantage of being text-based,
Being text-based is an enormous advantage.
Something that is text based can be manipulated and handled by human
beings. They can look at it with their own eyes, and see what is
there.
This is not to say that some means of converting an XML file to a
unique binary representation - that takes all equivalent XML files,
and converts them to a single result - if the XML format doesn't
prevent this from being done - wouldn't be useful for some purposes.
A special-purpose format to facilitate signatures, rather than a new
'standard' to replace what people have already decided works, might
have some chance of acceptance.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Custom Encryption Algorithm
Date: Sun, 10 Dec 2000 04:50:41 GMT
On Sat, 09 Dec 2000 17:27:14 GMT, Simon Johnson
<[EMAIL PROTECTED]> wrote, in part:
>Even though you have not given me an algorithm to work with, i can
>point out some flaws in this cipher just by looking at the cipher-text.
>e.g. You have a row of 9 ones in succession. If this were a good
>cipher, then you would have an even distribution of digits. However,
>the probability of a string of nine '1's occuring in a row is 1/10^9 or
>one in a billion.
>Based on this, I conclude your algorithm isn't very secure.
There's more to it than that:
The x's mark digits other than 0, 1, 2, and 3:
>>0010201313000711400110710511001009221021911110020
x x x x x
>>00171107061101111113113019010401111923230310110020
x x x x x x
>>18111130314712111601412711130171111121121007011011
x xx x x x x x
>>17700101012202012011001091300110353201040101019130
xx x x x x
but the digit 3 also seems to have a low frequency. Maybe this cipher
is based on logarithms or something?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: How to embed a key in executable code?
Date: Sun, 10 Dec 2000 07:00:37 GMT
"Sundial Services" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Okay, Matt, I hear what you are saying "as a technologist," but now let
> me show you the other side of the coin. I mean this, not to refute what
> you are saying, but to show the "hidden cost" of this approach.
Yeah, I buy all that. That's why most companies don't even try to do copy
protection anymore.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: wrapper code
Date: Sun, 10 Dec 2000 07:07:24 GMT
Rex Stewart wrote:
[snip]
> I don't think the issue was ever completely settled. The main
> issue seems to be static padding provides a known plaintext and
> random padding could provide a subliminal channel.
Another possibility, which is sort of a hybrid of the above two
suggestions, is to pad with bits of a hash of all previous blocks.
Follow the pad bits with (for a 64 bit/8 byte block cipher) 3 or 6 bits
stating how many bytes or bits of padding there is. If your message
lengths are always multiples of 8 bits (ie, are integral numbers of
bytes), then the last byte of your message should always be 5 bits of
padding, and a 3 bit integer, stating how many more bytes of padding
there were preceding this one to bring the total message length to a
multiple of the blocksize.
Although this, like static padding, does provide some amount of known
plaintext, you need to first decrypt all prior blocks to know what that
known plaintext is. Thus, there is no subliminal channel, and we avoid
some of the drawbacks of the mechanisms like that described in RFC 1423.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Sun, 10 Dec 2000 07:07:31 GMT
Daniel James wrote:
>
> In article <[EMAIL PROTECTED]>, John Myre wrote:
> > I'd like to hear more responses on this, too. Smart cards
> > are greatly popular in Europe, but not in the United States.
> > Why this is I do not know, unless it be inertia.
>
> I think it's partly inertia and partly parochialism - most smartcard
> products are not of US origin.
>
> > There is certainly one good reason for smart cards: the secrets
> > can stay there, and you don't have to worry about the problem
> > of insecure PC's.
>
> You *do* have to worry about insecure PCs - just not for the same
> reason. It's not possible for rogue software to steal your private key
> from a smartcard, but it's still possible for a Trojan Horse program
> in your PC to use your private key to sign transactions without your
> knowledge - it just has to wait until you insert your smartcard and
> enter your PIN.
True enough, but it still has to do it while the card is there, limiting
the window of exposure. If your card is set up to allow one and only
one transaction for each time you enter the PIN, and you only plug the
card into the PC when you want to make a transaction, you limit the
chance of exposure even further.
A hostile program would have to race the normal program to use the card,
and fake out the normal program into thinking that it's transaction was
properly signed to prevent the user from realizing something was wrong.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Panama question
Date: Sun, 10 Dec 2000 07:07:36 GMT
I suppose this is a bit of a silly question, but...
Suppose that in using the "Panama" stream cipher, you followed every
"pull" operation [retriving some bits of keystream], you followed it
with a "push" operation, feeding the plaintext that's just been
enciphered back into the state of the cipher? Would this form of
feedback be more or less secure than the normal mode of Panama
operation?
This should produce forward propogation of data changes that is as good
as block ciphering in PCBC mode, I think.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Toy cipher question
Date: Sun, 10 Dec 2000 07:22:13 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > I'd like to know what kind of attacks would be used on a toy cipher
> > with the following psuedocode:
> >
> > uint64 encrypt( uint64 data, uint64 * key ) {
> > data += *key++;
> > // prewhiten
> >
> > for( int i = 0; i < ROUNDS; ++i ) {
> > uint8 x[8] = (uint8[8])data;
> > uint8 y[8];
> > for( int j = 0; j < 8; ++j )
> > x[j] *= "x**16" in GF(2^8) with polynomial p[j];
> > // linear transform
>
> Is "x**16" a function w.r.t to your polynomial moduli? Is "*="
> assumed to be in Z256? Is "x" all of "x[0..7]" or just "x[j]". Is
> the resulting expression invertible?
Sorry about the ambiguity, but what I meant by x[j] * "x**16" was to use
GF math and double x[j] 16 times. The confusion here is from the fact
that doubling in GF is the same as multiplying by the polynomial "x",
and I also happen to have a variable named x.
Hopefully, flipping one bit of the data will result in this linear step
flipping [on average] 4 bits.
> > for( int k = 0; k < 8; ++k )
> > y[k] |= ((x[j]>>k)&1) << j;
>
> Correct me if I am wrong but the for (j;<8;++) loop is not active
> so "j" is constant in the above two lines. Also you are displacing
> single bits only... see below.
Yes. I take each of the 8 bits of x[j] and put one bit into each
element of y[].
A one bit difference going into the linear round will, hopefully, have a
~4 bit difference going out. This step will put each of those bit
differences into 4 different bytes.
> > // after doing a linear transformation on the
> > // rows of the 8x8 matrix of bits, transpose
> > // x and store it in y.
> > for( int j = 0; j < 8; ++j )
> > y[k] = AES_sbox[ y[k] ];
> > // do a nonlinear transform on the rows of 8x8 bit
> > // matrix y
A one bit difference in each of ~4 bytes should result in ~4 bits
flipped in each of ~4 bytes... Thus, one round of encryption should
cause a one bit input difference to have a 16 bit output difference.
Two rounds should result in fulfillment of SAC.
> > data = (uint64)y;
> > data += *key++;
> > // add in the round key.
>
> You add the roundkey after the substitution? That's just plain
> stupid. That means the first round is useless since I can attack it
> with a probability of one.
Except that the first round is preceded by a prewhitening step.
> Also by using single bit linear transform I could work on differential
> attacks that have input and output differences of single bits. That
> means the number of active sboxes can be minimized.
>
> > }
> > return data;
> > }
> >
> > I know noone is going to do, say, differential analysis for me,
> > but... I'd like to know, can it be done? How would I go about
> > finding impossible differentials? Also, can linear analysis work on
> > something like this? Some other attacks? Obviously not slide
> > attack unless there were repeated round keys, but surely there's
> > some attack better than impossible differentials?
>
> I would say a differential attack would be very feasible. It depends
> however on what the above "*=" is to mean.
>
> Your pseudocode is not clear enough to actually formulate a concrete
> attack but I would conjecture that it's not that strong at all.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Simpler toy cipher in better psuedocode
Date: Sun, 10 Dec 2000 07:22:17 GMT
Here's an even simpler toy cipher than the last one I wrote, and
hopefully, it's less ambiguous.
function encipher( text: 8x8 matrix of bits, key )
addkey( text, key, 0 );
for round in 1..ROUNDS:
for i in 0..7 :
text[i][0..7] = AES_sbox[ text[i][0..7] ];
end for
matrix_transpose( text );
addkey( text, key, round );
end for
end function
It encrypts a 64 bit block, and requires 3-4 rounds for complete
avalanche. One round does approximately 4 bits of diffusion, two rounds
approximately 16 bits of diffusion, and three rounds approximately 64
bits of diffusion. Because of the "approximately," I can't count on SAC
with just 3 rounds, and suggest 4 for surety. The matrix_transpose is
expensive in software, but cheap in hardware.
Here's a rewrite of the earlier toy cipher, in clearer psuedocode:
function encipher( text: 8x8 matrix of bits, key )
addkey( text, key, 0 );
for round in 1..ROUNDS:
for i in 0..7 :
text[i][0..7] = sbox[i][ text[i][0..7] ];
end for
matrix_transpose( text );
for i in 0..7 :
text[i][0..7] = AES_sbox[ text[i][0..7] ];
end for
addkey( text, key, round );
end for
end function
Each sbox[i] is a multiplication by 2**16 in GF(2**8), except that for
each i, the reduction polynomial is different.
This toy cipher should need only 2 rounds for complete avalanche.
Here's pseudocode for my most recent non-toy cipher:
function encipher( text: 16x8 matrix of bits, key )
addkey( text, key, 0 );
for round in 1..ROUNDS:
for i in 0..7 :
text[0..15][i] = sbox[i][ text[0..15][i] ];
end for
for i in 0..15 :
text[i][0..7] = AES_sbox[ text[i][0..7] ];
end for
addkey( text, key, round );
end for
end function
Each sbox[i] is a multiplication by 2**32 in GF(2**16), except that for
each i, the reduction polynomial is different.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary
specification and SDK released
Date: Sun, 10 Dec 2000 07:22:20 GMT
denis bider wrote:
>
> On Fri, 08 Dec 2000 22:29:46 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >> The preferred translation, however, is the other way around: XML to
> >> EDDF. EDDF is generally what you will prefer to use for a digital
> >> signature, and XML is what the original data format would be.
> >> Again,
> >
> >Elsewhere I saw the phrase 'XER, or XML Encoding Rules (for ASN)'.
> >I don't know what that is. Does that say something to you?
> >
>
> Well, let me put it this way. XER is a good way to convert data from a
> good format to a much worse format, and back.
>
> What XER does is that it takes an ASN.1 document and it bloats it into
> XML by literally copying all information that appeared in the original
> ASN.1 document. This XML can then be parsed to retrieve the same ASN.1
> document, which can then again be expressed with any of the other
> ASN.1 encoding rules, such as DER.
>
> Basically, XER is a kludge that makes it possible to transfer ASN.1
> documents through XML.
Hmm. If I have an arbitrary XML document, then use XER to change it to
ASN.1, and then back, will the new XML document be larger or smaller
than the original? Is an ASN.1 document larger or smaller than a
bzip2ed XML document?
Suppose that instead of converting documents to ASN.1, I convert to some
sort of "cannonical XML", and sign that?
Also, although I'll admit that you *usually* need a viewer for XML,
since computer generated stuff looks like shit, the same could also be
said of HTML, whose use is perhaps even more widespread. There are,
however, ways designed to make HTML legible, which should also work on
XML. A program that removes extraneous whitespace, then inserts
newlines and indentation, may be, in many cases, sufficient for making
computer genrated HTML and XML human readable.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
** 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
******************************
