Cryptography-Digest Digest #292, Volume #13       Fri, 8 Dec 00 10:13:01 EST

Contents:
  [globera announcement 1] "Efficient Descriptive Data Format" preliminary 
specification and SDK released (denis bider)
  Re: Idea for ciphering? (Jorgen Hedlund)
  [globera announcement 2] Professional support for Crypto++ available (denis bider)
  Re: Toy cipher question (Tom St Denis)
  Re: Modular arithmetic (Tom St Denis)
  Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary 
specification and SDK released (Tom St Denis)
  Re: RSA Coding Assistance (Tom St Denis)
  Re: Idea for ciphering? (Mok-Kong Shen)
  Re: Fips Pub 140-1 and RNG (Mok-Kong Shen)
  Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary 
specification and SDK released (denis bider)
  Re: RSA Coding Assistance ("M.S. Bob")
  Re: [Question] Generation of random keys (Eric Lee Green)
  Re: [globera announcement 1] "Efficient Descriptive Data Format"  (Mok-Kong Shen)
  Re: Toy cipher question ("M.S. Bob")
  Re: breaking rsa knowing the original text (Paul Schlyter)
  Re: [globera announcement 1] "Efficient Descriptive Data Format"  preliminary 
specification and SDK released (denis bider)
  Re: weten we die PIN? (Ralf van de Ven)
  Re: Fips Pub 140-1 and RNG (DJohn37050)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (denis bider)
Subject: [globera announcement 1] "Efficient Descriptive Data Format" preliminary 
specification and SDK released
Date: Fri, 08 Dec 2000 12:43:41 GMT

Efficient Descriptive Data Format preliminary specification and SDK
released

EDDF is an ASN.1-based binary data transfer and storage format that is
structurally similar to XML, but has several additional benefits that
make it much more suitable for use in cryptographic applications,
storage of binary data, and machine processing in general. 

In particular, EDDF is:
 (o) Implicitly canonical. Using EDDF, it is easy to ensure that a
single set of data can only be expressed with a single EDDF document.
This is important for electronic document signing and signature
verification.
 (o) Easier to parse and safer to use. EDDF uses a strongly defined
straightforward binary format, thus elegantly avoiding the
complexities and potential security vulnerabilities inherent to
text-based formats (such as XML).
  (o) Efficient. EDDF documents are, on average, 25% shorter than
corresponding XML documents. 

The EDDF specification is currently in First Draft stage, and the
author invites all interested individuals and organizations to submit
their comments.

The EDDF specification, ISO/ANSI C parser and ISO/ANSI C++ parser are
available freely from http://www.eddf.org. There are no strings
attached.

You are invited to visit http://www.eddf.org for more information.



------------------------------

From: [EMAIL PROTECTED] (Jorgen Hedlund)
Subject: Re: Idea for ciphering?
Date: Fri, 08 Dec 2000 13:00:00 GMT

On Thu, 07 Dec 2000 23:13:25 GMT, Bryan Olson <[EMAIL PROTECTED]>
wrote:
>So what exactly is the public key and how does one ecrypt with it?


Not sure if there's a public key. I believe the secret key to be the
STT + the alphabets.

I haven't come that far in cryptology yet, that I completely
understand the public/private key stuff...

BR/jh


------------------------------

From: [EMAIL PROTECTED] (denis bider)
Subject: [globera announcement 2] Professional support for Crypto++ available
Date: Fri, 08 Dec 2000 13:07:14 GMT

KEEP REAL CRYPTO - SAVE REAL MONEY

Professional support for Crypto++ available

globera, a Ljubljana, Slovenia-based consultancy and integration
company specializing in digital security, announces open availability
of professional support for the public domain Crypto++ library.

Crypto++ is a mature, comprehensive C++ library that implements a wide
range of cryptographic schemes, covering the majority of mainstream
cryptographic algorithms. See also the Crypto++ information page at
[http://www.globera.com/cryptopp] and the official Crypto++ website at
[http://www.cryptopp.com].

For several years, globera's experts have been providing consulting
and integration services, as well as technical support for Crypto++,
to selected clients. By virtue of an exceptional combination of
experience and geographic location, globera is now able to offer
professional services at attractive rates to a wide audience of
Crypto++ users.

For more information, you are invited to visit
[http://www.globera.com/services].


------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Toy cipher question
Date: Fri, 08 Dec 2000 13:02:45 GMT

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?

>                       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.

>                       // 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
>               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.

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.

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Modular arithmetic
Date: Fri, 08 Dec 2000 13:03:59 GMT

In article <90otoo$1js8$[EMAIL PROTECTED]>,
  "KENNETH H MARTIN" <[EMAIL PROTECTED]> wrote:
> Please forgive my ignorance, but to decrypt an IDEA cipher
> I need to find the multiplicative inverse of a 16-bit number,
> Mod 66537.  What if there are no inverses less than the
> modulus, say for a relatively prime number like 5?  Is there
> a trick to this?

5 has a modular inverse modulo "65537" (note the correct number).
Since "5" and "65537" are relatively prime there is an inverse....

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary 
specification and SDK released
Date: Fri, 08 Dec 2000 13:09:40 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (denis bider) wrote:
> Efficient Descriptive Data Format preliminary specification and SDK
> released

Perhaps my english is off a tad, but why did you post this msg to
sci.crypt?

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA Coding Assistance
Date: Fri, 08 Dec 2000 13:07:38 GMT

In article <90otho$21d$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> I'm looking for a "simple" RSA implimentation to work with.  By
simple,
> I mean that in the application, all I have to do is include 1 .h file
> to accomplish everything.  I'm confident that I can write it, but why
> reinvent the proverbial wheel?

So you can learn something yourself?  Coding RSA is not particularly
hard if you have a bignum library handy...  Try it out!

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Fri, 08 Dec 2000 14:18:56 +0100



Bryan Olson wrote:
> 
> [EMAIL PROTECTED] wrote:
> > Mok-Kong Shen wrote:
> > >
> > > Sorry, I erred. Since the F's are secret, the STT can be
> > > public.
> 
> >
> > Right =)
> 
> So what exactly is the public key and how does one ecrypt with it?

The original poster's use of the term 'public key' is 
inappropriate and confusing. He has secret substitutions 
in the scheme and so can leave the STT public. Later he 
apparently saw the advantage of having a secret STT and 
has switched to that in his later posts.

M. K. Shen

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Fips Pub 140-1 and RNG
Date: Fri, 08 Dec 2000 14:19:01 +0100



[EMAIL PROTECTED] wrote:
> 
> > Random numbers are often required for "Power On Self-Test"s (POSTs).
> > Could that have been what the document was talking about?
> 
> It was indeed. What difference does it make whether these tests are
> executed on power up as opposed to being executed at any other time ?

Presumably to provide better control of malfunction like
checks of airplanes before taking off.

M. K. Shen

------------------------------

From: [EMAIL PROTECTED] (denis bider)
Subject: Re: [globera announcement 1] "Efficient Descriptive Data Format" preliminary 
specification and SDK released
Date: Fri, 08 Dec 2000 13:31:41 GMT

On Fri, 08 Dec 2000 13:09:40 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:

>> Efficient Descriptive Data Format preliminary specification and SDK
>> released
>Perhaps my english is off a tad, but why did you post this msg to
>sci.crypt?

EDDF has been designed very much with cryptographic applications in
mind. One of the very motivations behind EDDF is to provide - or at
least make an attempt to provide - a universal document format to
facilitate electronic signing of documents.

It was therefore my perception that sci.crypt is the audience that
would be able to appreciate EDDF's qualities in this area the most.

Kind regards,

denis


------------------------------

From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: RSA Coding Assistance
Date: Fri, 08 Dec 2000 13:36:07 +0000

[EMAIL PROTECTED] wrote:
> 
> I'm looking for a "simple" RSA implimentation to work with.  By simple,
> I mean that in the application, all I have to do is include 1 .h file
> to accomplish everything.  I'm confident that I can write it, but why
> reinvent the proverbial wheel?

RSA itself can be implemented in less than 100 lines of easy to read C
using a large integer library such as GNU's MP library. Simply follow
any textbook description of RSA.

RSA in applications for real-world use is more complicated. From issues
of secure random large prime number generation, standard data/file
formats, to the simple fact that rarely is RSA used on its own for
encryption. Most applications also require secure message digests (e.g.
MD5, SHA-1) and a symmetric cipher.

I am not certain how much you know about cryptography, so forgive me if
you already realize, but typically application of RSA is only for
exchanging session keys of a much faster, symmetric encryption. For
digital signatures, message digests are used so you only use RSV to sign
the digest, not the entire message, which again is much faster.

You may be able to implement itself yourself, but I have grave
reservations about whether you can correctly and securely implement it
yourself. In a commercial application the cost of screwing up security
is always far more than the cost of a toolkit and training or hiring a
knowledgeable and experienced consultant.

------------------------------

From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: [Question] Generation of random keys
Reply-To: [EMAIL PROTECTED]
Date: Fri, 08 Dec 2000 13:44:23 GMT

On Fri, 08 Dec 2000 08:08:31 GMT, Benjamin Goldberg <> wrote:
>David Schwartz wrote:
>>         In fact, you would have to accept practically anything that
>> was to any extent unpredictable as "random". Because unpredictability
>> is the _only_ thing you can't create algorithmically.
>
>Why yes, you are exactly correct.

And of course unpredictability is what we're interested in, if we're
generating key strings. Randomness is just a happy coincidence. 

-- 
Eric Lee Green      There is No Conspiracy
[EMAIL PROTECTED]     http://www.badtux.org  

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: [globera announcement 1] "Efficient Descriptive Data Format" 
Date: Fri, 08 Dec 2000 14:52:12 +0100



denis bider wrote:
> 
> Efficient Descriptive Data Format preliminary specification and SDK
> released
> 
> EDDF is an ASN.1-based binary data transfer and storage format that is
> structurally similar to XML, but has several additional benefits that
> make it much more suitable for use in cryptographic applications,
> storage of binary data, and machine processing in general.
[snip]

I am afraid there is a 'practical' problem. XML is likely
to gain (increasingly) very wide acceptance. So I guess
one should be able to use your format to code some data
inside an XML document. Would that work? Thanks.

M. K. Shen

------------------------------

From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Toy cipher question
Date: Fri, 08 Dec 2000 13:55:44 +0000

Benjamin Goldberg wrote:
> 
> I'd like to know what kind of attacks would be used on a toy cipher with
> the following psuedocode:

That is pseudo C++, not a high level pseudocode. References to pointer
arithmetic make it hard to follow for a non-C/C++ programmer.

The fact that there is a lack of explanation and justification make it a
waste of time. I would have to spend my time trying to figure out not
only how the algorithm works, but try to decide why you choose to do in
such a manner. This obviously can lead to false assumptions, thereby I
can misunderstand your intent, and your motivations. 

You have to do a bit of "selling" of the algorithm, as to why it is
interesting enough for me to spend my time thinking about it. Is it just
because it was created by you, and you want people to look at it? Not a
compelling reason, to me anyhow. Is it likely because you use a variety
of aspects taken from other ciphers. So say it, explain what aspects the
the cipher exhibits, why you think they are important, and why you claim
that this combination may be secure.

You have mentioned pieces of this things in various follow-ups to
previous postings, now spend a hour or two and combine them into a
coherent document. It does not have to be perfect, but at least make an
attempt to express your why behind the how.

> 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

You will simply have to learn this methods yourself, well enough to
carry them out on your proposed cipher. You will gain far more that way
then with any comments someone else can make.

Good luck.

------------------------------

From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: breaking rsa knowing the original text
Date: 8 Dec 2000 14:27:55 +0100

In article <90p4r0$8d4$[EMAIL PROTECTED]>,
Bryan Olson  <[EMAIL PROTECTED]> wrote:
 
> [EMAIL PROTECTED] wrote:
> 
>> Hi, I'm trying to figure out if it is much simpler to
>> break RSA knowing the original text and the encrypted text.
>> I mean, if some knows the original and the encrypted data
>> how easy will be to get the key ??
> 
> Giving an attacker ciphertext with corresponding
> plaintext will not help him recover the RSA key.  It's
> a public key cipher so he can create all the plaintext/
> ciphertext pairs he wants.
 
Only if the encryption key is public.  In authentication
applications, the encryption key is private and the decryption key is
public.
 
-- 
================================================================
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

------------------------------

From: [EMAIL PROTECTED] (denis bider)
Subject: Re: [globera announcement 1] "Efficient Descriptive Data Format"  preliminary 
specification and SDK released
Date: Fri, 08 Dec 2000 14:29:48 GMT

On Fri, 08 Dec 2000 14:52:12 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:


>I am afraid there is a 'practical' problem. XML is likely
>to gain (increasingly) very wide acceptance.

Yes, that slight problem exists. :-) Particularly because Microsoft is
investing its corporate weight into the XML phenomenon. Perhaps a
letter to Bill Gates recommending EDDF instead would help. [Bill, are
you reading? :-) ]


>So I guess one should be able to use your format to code
>some data inside an XML document. Would that work? Thanks.

At least two techniques could be used to embed EDDF data within XML:
  - Since EDDF and XML are very similar in structure, the EDDF
document can be translated to XML via a simple set of translation
rules. It would not be very difficult to develop and standardize a
universal set of translation rules for conversions like this.
  - On the other hand, if the ability to access EDDF-encoded
information from an XML program is not important, the EDDF document
can simply be converted to Base64 and dumped into the XML document as
text.

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,
this is a straightforward translation process. Using a proper set of
rules (a set that is significantly less complex than the set of rules
required for XML canonicalization), the XML document will be
implicitly converted to a canonical form that is suitable for digital
signing.

Regards,

denis


------------------------------

From: Ralf van de Ven <[EMAIL PROTECTED]>
Crossposted-To: 
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: 8 Dec 2000 14:39:19 GMT

In nl.juridisch David Dylan <[EMAIL PROTECTED]> wrote:
> On 7 Dec 2000 22:09:58 GMT, John <[EMAIL PROTECTED]> wrote:

> Hoi hoi,

>>Geen van beiden, het wordt namelijk op de kaart zelf bijgehouden.

> Dat is wel het meest logische vanuit een efficiency standpunt, maar is
> het ook veilig? Inbreken in een banksysteem lijkt mij een end lastiger
> dan op je gemak in een achterkamertje met een paar nerds de code op
> een kaart uitdokteren... Of zie ik dat nu helemaal verkeerd? 

> Je verzamelt een paar kaarten waar je de PIN van weet, en kijk &
> vergelijk... (simpel gezegd)...

Lees even dit stukje van de thread opnieuw...
Dit ging namelijk over het aantal mislukte pogingen.

mvg
Ralf

------------------------------

From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Dec 2000 14:56:45 GMT
Subject: Re: Fips Pub 140-1 and RNG

There is a continuous test for a repeat of an output.  The other tests can be
run at power up or at any time by deliberate sysadmin execution.
Don Johnson

------------------------------


** 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 (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

End of Cryptography-Digest Digest
******************************

Reply via email to