Cryptography-Digest Digest #857, Volume #12       Fri, 6 Oct 00 14:13:00 EDT

Contents:
  Some thoretical questions... (Nikica Guscic)
  Re: Need help: considerations for IV and Keysetup (Marc)
  Re: It's Rijndael (Marc)
  Re: TC8 -- Yet Another Block Cipher (Marc)
  Re: TEA (Marc)
  Re: Need help: considerations for IV and Keysetup (John Myre)
  Re: are doubly encrypted files more secure than singly encrypted ones? (jtnews)
  Re: Choice of public exponent in RSA signatures (Francois Grieu)
  Re: The best way to pronounce AES (Scott Craver)
  Re: It's Rijndael (Jim Gillogly)
  Re: The best way to pronounce AES (Scott Craver)
  Re: Choice of public exponent in RSA signatures (DJohn37050)
  Re: Looking Closely at Rijndael, the new AES (John Myre)
  Re: are doubly encrypted files more secure than singly encrypted ones? (fvw)
  Re: are doubly encrypted files more secure than singly encrypted ones? (John Myre)
  Re: newbie pathetic question ("Joseph Ashwood")
  Re: Storing an Integer on a stream (Joke) (Ichinin)
  Re: Elliptic Curve / Blowfish combination as an alernative to PGP ? 
([EMAIL PROTECTED])
  Re: NSA quote on AES (Tim Tyler)
  Re: Suggestion for Digital Cash System (Mike Rosing)
  Re: ISAAC PRNG (Albert Yang)

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

From: Nikica Guscic <[EMAIL PROTECTED]>
Subject: Some thoretical questions...
Date: Fri, 6 Oct 2000 16:57:17 -0700

How good security do multiple processes applied on an cleartext give?
For example: DES, Steganography, DES.

And how good would an "steganoencryption" be.
Example:
        cleartext: "Attack at dawn!"
        Encoded:   "We shall win!"

Don't ask me for ideas about the code because I started it a week ago...
And no, I don't have better things to do but ask stupid theoretical 
questions. <--- For those who have nothing better to do than laugh at 
these questions.

TNX

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

From: [EMAIL PROTECTED] (Marc)
Subject: Re: Need help: considerations for IV and Keysetup
Date: 6 Oct 2000 15:11:25 GMT

>obvious IV to use for encrypting the data payload. Still debating
>whether we should do it though. Can you really call it a backup if you
>can't recover the data? 

Why don't you default to key-escrow where the password is PubKey encrypted
in each tapes' header?  The escrow secret key could be kept safe in your
company (to a certain degree) by splitting it with an m-of-n scheme.

A user should be able to disable the escrow scheme in an "expert mode"
and with triple warnings, and is (only) then left on his own.

Sure, escrow is a bad thing usually, but here it provides an advantage
over the existing scheme (write password + cleartext to tape). For
the legitimate user it stays the same: send the tape in, pay a fee, and
receive the decrypted tape.  For the thief it is unbreakable without
insider info (password guess or escrow secret key).

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

From: [EMAIL PROTECTED] (Marc)
Subject: Re: It's Rijndael
Date: 6 Oct 2000 15:11:31 GMT

>Agreed. The main benefit of the standard is the interoperability,
>and this is lost if you modify the algorithm.

I don't see where there has been broad interoperability in the past,
and where it will be in the future.  Every application that uses
crypto has its own specs.  Sure, often the specs refer to DES when
it comes to the cipher algorithm.  But nonetheless there is more
to a communication, like chaining mode, packetizing, headers, ECC/FEC,
and so on.

Two different harddrive encryptors don't interoperate just because they
use the same underlying crypto algorithm.

Interoperability is not inherent but has to be gained at expenses. There
is not much more/less of it when adding 2 lines to a 50 page description
of a harddrive encryptor tech-doc to explain that AES with 16 rounds
instead of 10 is to be used the underlying block cipher.

IMO the main benefit of the standard is that it is subject to analysis and
soon a known level of security will be associated with it.  Modifying
the algorithm will put in question whether all the trust still applies or
not.  That is why I wouldn't modify it, not the interoperability.


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

From: [EMAIL PROTECTED] (Marc)
Subject: Re: TC8 -- Yet Another Block Cipher
Date: 6 Oct 2000 15:11:41 GMT

>You can have a look about birthday attacks concerning CBC-mode and any
>64-bit block cipher:
>
>http://lasecwww.epfl.ch/birthday.shtml

If I understand correctly, the "birthday attack" looks for two identical
blocks of ciphertext, and then uses their predessor ciphertext blocks
(which are the IV) to recover (cleartext1 XOR cleartext2)?

A chaining mode like this (encryption)
    
        ciphertext = crypt( cleartext XOR chainregister );
        chainregister += cleartext;                     // 64bit addition
        chainregister += ciphertext;                            // 64bit addition

shouldn't be vulnerable to birthday attacks, should it?  The IV is
a) influenced by unknown information (the cleartext) and b) carried
on throughout the whole chain.

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

From: [EMAIL PROTECTED] (Marc)
Subject: Re: TEA
Date: 6 Oct 2000 15:11:47 GMT

>I want to use TEA in the microcontroller (PIC 16C8x), because it(he) is
>very simply realized.

There exist DES implementations that occupy 1/2 of the CODE space only.
Don't know if the shortest ones are published though.  The SAT TV hackers
are a good starting point for your search.

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Need help: considerations for IV and Keysetup
Date: Fri, 06 Oct 2000 09:08:57 -0600

Paul Rubin wrote:
<snip>
> The right way for encrypted backups to work is the tape should be
> encrypted with a public key stored on the system.  That way no
> password is needed to simply write a backup.  The private key should
> be kept in a vault where it can be recovered by management.  In some
> situations the sysadmin should also have access to the private key.
<snip>

Makes sense to me.  Then combine that symmetric cryptography in the
usual way: encrypt the data with a (random, new) symmetric key, then
encrypt the symmetric key with the public key (OAEP, whatever).

One might start with GPG (allowing access to the source code),
and send outputs to the tape drive instead of to (a) file(s).

JM

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

From: jtnews <[EMAIL PROTECTED]>
Subject: Re: are doubly encrypted files more secure than singly encrypted ones?
Date: Fri, 06 Oct 2000 15:21:45 GMT

why would armoring affect the security of the encrypted information?
Isn't armoring just an ascii representation of the encrypted binary?
Isn't the entropy of the information increased each time the
information is processed?

John Savard wrote:
> 
> On Fri, 06 Oct 2000 08:55:05 GMT, jtnews <[EMAIL PROTECTED]>
> wrote, in part:
> 
> >If I use gnupg on a file and then encrypt the encrypted file again
> >is it anymore secure?  Will it take longer for someone to crack it?
> 
> Not with a program like GNU Privacy Guard, perhaps. Even if you use
> conventional encryption, with a different key for each step, there is
> still the problem that it will treat an encrypted file as a general
> text file, instead of extracting the encrypted bits from it to only
> encrypt them.
> 
> So you are almost certain to wind up with it only taking N times as
> long to crack it, if you encipher N times. This would not, however, be
> true if you did repeated conventional encryption _without armoring_
> except for the final encryption. Then you would finally get the
> benefit of multiple encryption.
> 
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm

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

From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Fri, 06 Oct 2000 17:20:41 +0200

[EMAIL PROTECTED] wrote:

>> with a subliminal channel, a high-isolation prisonner could
>> conceivably leak information to the outside while paying bills.
> 
> Why is a high-isolation prisoner paying bills?

In France, I do not think a prisonner is prevented from doing so.
Why would no he or she pay the bills for things purchased before
beeing jailed ? Jailed, even in high-isolaton, does not mean guilty,
nor the end of all social life.


>> a signer could conceivably choose a value of random, like
>> "I_was_forced_into_signing_this", to attempt repudiating the
>> signature later.

> But that's useful, if the signer was in fact forced into
> signing it.

Since such a random value gives no clue on if the signer was forced
into signing, or was not forced but wanted to cheat later, it is
actually NOT usefull to resolve a dispute I'm afraid. A side channel
only makes it harder to define the right practice in repudiation.
It appears very sound that someone handed a digital signature that
verifies properly can be 100% sure it can not be repudiated based
on its content.

> In any case where someone attempts to repudiate a signature,
> the dispute can't be resolved purely by algorithmic means; the
> apparent signer may very well have a justifiable reason for
> repudiating it.

Agreed entirely. Digital signature should only be considered a
strong indication of legitimate message, just like fingerprint,
or DNA traces.


>> With a traditional signature scheme, I tell a digital signature
>> is "a number computed from secret key and message", and the
>> verification process "checks the signature is the right number,
>> using only the message and public information". More people will
>> grasp this, and gain some insight on what digital signature can
>> do for them, than if I must introduce anything extra in the
>> picture, like "one of the right number".

> I very much doubt that whether a signature algorithm is
> deterministic or nondeterministic will be of any concern to
> most users.

Agreed. Still I would feel unethic to use vocabulary implying
the signature is deterministic, and a problem lies in explaining
what happens in simple but accurate terms.


> PSS has better security bounds than Full Domain Hashing, for example,
> so to get the same security you would need to compensate by increasing
> the modulus size and slowing down the algorithm.

I whish the difference could be quantified !  I'd buy a 40% extra
verify time (20% extra modulus size) for a deterministic signature.


   Francois Grieu

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

From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: The best way to pronounce AES
Date: 6 Oct 2000 15:19:08 GMT

Manuel Pancorbo <[EMAIL PROTECTED]> wrote:
>Tom St Denis <[EMAIL PROTECTED]>
>>
>> Ok... pronouce the word "aesthetic".... hehehe
>>
>
>Ooops... you (anglos) are impossible...
>Ok, get the fonetic alfabet and look for the symbols [a], [e], [s]. Simply
>pronounce them in this order [a]-[e]-[s]. Isn't it yet enough easy for you?

        Aah?  Eh?  Eh?!!  Say....what?

>Manuel Pancorbo

                                                        -S



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

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Fri, 06 Oct 2000 15:28:06 +0000

Marc wrote:
> 
> >Agreed. The main benefit of the standard is the interoperability,
> >and this is lost if you modify the algorithm.
> 
> I don't see where there has been broad interoperability in the past,
> and where it will be in the future.  Every application that uses
> crypto has its own specs.  Sure, often the specs refer to DES when

SSL, IPsec, OpenPGP, to name three.  I imagine there will be widely
available interoperating encrypted chat apps before long, if there
aren't already.

-- 
        Jim Gillogly
        Sterday, 15 Winterfilth S.R. 2000, 15:25
        12.19.7.10.19, 2 Cauac 2 Yax, Third Lord of Night

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

From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: The best way to pronounce AES
Date: 6 Oct 2000 15:24:14 GMT

John Savard <[EMAIL PROTECTED]> wrote:
>
>RIJNDAEL: 
>Really, I just now defined acronyms (in the) English language.
>Really, I just now disclosed all (the) evil logic.
>Really, I just now devised an equivalent logogram.

        "Really, I jest not;  dad's an evil lawyer."

        [For any of you who remember the Right Reverend C-lin J-mes I-I]

>John Savard
                                                -S



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

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Choice of public exponent in RSA signatures
Date: 06 Oct 2000 15:38:04 GMT

I agree that one wants to be able to have both deterministic and
nondeterministric signatures.  For example to somewhat allay fears of a covert
channel.  But realize that ANY signature is a low bandwidth covert channel as
ANY message is a low bandwidth covert channel.  Just vary the message slightly
in 20 ways so that is has the same overt meaning.  This gives 20 covert bits to
a partner that knows how to interpret it.
Don Johnson

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Fri, 06 Oct 2000 09:42:41 -0600

Thomas Pornin wrote:
<snip>
> Not quite. OTP is ultimately secure against passive attacks
> (eavesdropping) but not at all against active attacks (the bad guy
> intercepts and modifies the message).
<snip>

This observation leads to one that is also commonly made,
but not as well appreciated: the word "secure" is not well
defined.  The best way to view the situation is not by the
kind of attack, but with the kind of security OTP offers.

It has perfect secrecy, with no authentication.

In the common case where you want authentication as well
as secrecy, then you have to choose an authentication
method.  This is true for most encryption methods.  For
example, none of the common modes for block ciphers (ECB
and so on) provide really great authentication, and some
are really bad.

There's no reason why one couldn't use OTP in real life,
with authentication: add a MAC.  (Granted, there are
details, like the relative security of the MAC vs OTP,
and getting the protocol and the implementation right,
but all that work is needed, regardless.)

JM

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

From: [EMAIL PROTECTED] (fvw)
Subject: Re: are doubly encrypted files more secure than singly encrypted ones?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 06 Oct 2000 16:04:58 GMT

<[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>why would armoring affect the security of the encrypted information?
>Isn't armoring just an ascii representation of the encrypted binary?
>Isn't the entropy of the information increased each time the
>information is processed?

I think john means either 'armoring against transmission faults', as in 
adding a crc (or whatever takes your fancy), or the adding of headers. 
Both screw the security of your multiple pass encryption. With these, you 
can bruteforce the first layer of the encryption easily, and you know 
you've got the right one (or at least quite probably) because the checksum 
is correct or you've found the original header. If you don't add checksums
/header info till after the last round of encryption, you'll never know if
you've decrypted the first layer till you've decrypted em all.

-- 

                        Frank v Waveren
                        [EMAIL PROTECTED]
                        ICQ# 10074100

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: are doubly encrypted files more secure than singly encrypted ones?
Date: Fri, 06 Oct 2000 10:08:15 -0600

jtnews wrote:
> 
> why would armoring affect the security of the encrypted information?
> Isn't armoring just an ascii representation of the encrypted binary?
<snip>

Let us suppose that there really is a point to encrypting
more than once.  That means, in other words, that if you
only encrypt once, the bad guys can figure out what key
you used and decrypt it.  Whatever the reason is, we are
assuming this is the case.

So now, suppose that you armor each time in between
encrypting.  Then the last encryption is encrypting
ASCII data.  By our starting supposition, that means
the bad guys can break this: they can tell when they
succeeded because they get ASCII.

Now they un-armor the result and proceed to break the
next-to-last round of encryption.  And so on, until they
get your original data.  If you encrypt 10 times, it takes
the bad guys no more than 10 times longer to break it.

This is not a good bargain.

Now suppose on the other hand that you don't armor
until after the last encryption.  The bad guys have a
much harder task, because they can't easily tell if
they have broken the last round of decryption.  If the
encryption is fairly good, so that there are no useful
statistics in the output, then the bad guys have to
break all the rounds at once.

This is much better.

JM

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: newbie pathetic question
Date: Thu, 5 Oct 2000 15:18:32 -0700

I think we understood the original poster differently. I understood the
original as being somewhat equivalent to instead of using biases for
English, generate completely random biases for each symbol. However it would
only slow the analysis slightly as it would be a monoalphabetic
substitution, using dynamically sized symbols. So the general attack would
remain the same. However if you were to create one where the tree itself
changed in some pseudo-random fashion, then it becomes a stream cipher and
that can be secure.
                    Joe

"Albert Yang" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Compression is based on frequency, and frequency = bias, and bias = bad
because
> bias = more likely to be cracked.
>
> Your tree structure for English would be very predictable.  Take a look at
> Playfair as an example.  So your secret tree would not be too much of a
> secret..  Or at least a predictable one.
>
> A great example of this is watching "Wheel of Fortune", you can tell right
away
> that basically it's common knowledge what the frequency of the english
language
> is...
>
> Albert
>
> Danilo wrote:
>
> > I wonder why is arithmetic coding not used to scramble messages ?
> >
> > If I arithmetic compress a message, but using a frequency table which
> > is actually my key (both in the frequencies and in the order of the
bytes),
> > wouldn't it be very hard to decrypt ?
> >
> > Excuse in advance for my pathetic ignorance of the matter.
> >
> > Danilo
>



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

From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Storing an Integer on a stream (Joke)
Date: Fri, 06 Oct 2000 07:02:13 +0200

"If one store an Int on a Stream, won't it _Float_ away?"

Now - i'd like to apollagise for my joke, but i could not
resist - besides, some people needs to be cheered up once
in a while :o)

-Ichinin

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

From: [EMAIL PROTECTED]
Subject: Re: Elliptic Curve / Blowfish combination as an alernative to PGP ?
Date: Fri, 6 Oct 2000 17:11:00 GMT

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1

[EMAIL PROTECTED] wrote:
> Just wondering if anyone could give me an opinion on using a
> combination of an Elliptic Curve / Blowfish set to produce a type of
> Public key encryption solution for securing files, in contrast to using
> the PGP DLL solution? (client wants PGP type public/private security
> setup but wants to stear clear of actual PGP because of import
> regulations in one of their branch offices)
> 
> Specifically I am looking at the Delphi components offered by TSM Inc
> (http://www.crypto-central.com). Their solution involves using their
> Elliptic Curve object to create a public/private key pair, then use an
> exchanged value from the Elliptic Curve object to act as an
> initalization key for the Blowfish object. Their documentation states:
> 
> "TEllipticCurve is an implementation of an elliptic curve (ECC) based
> asymmetrical cryptosystem, based loosely on the work of Paulo Barreto
> and George Barwood, but extensively reworked to offer greater
> performance and stability."

Paulo Barreto's and George Barwood's code used in Pegwit uses GF(2^255)
and is not considered secure anymore because of Attack found by Nigel Smart
against elliptic curves over GF(2^m) for composite m
(255 is composite = 3*5*17)
see at: http://www.hpl.hp.com/news/ecc.html
and: and http://www.hpl.hp.com./techreports/2000/HPL-2000-10.html.

hopefully they (TSM Inc) have reworked it to different curve...
(I can not test it..)



thats why I made I have made a new Pegwit version whick uses
Mike Rosing's ECC code (http://www.manning.com/Rosing/ 
http://mendota.terracom.net/~eresrch/ )
and one of curves recommended by NIST: GF(2^233)  (233 is prime)
and replaced Square replaced with Blowfish
(but its now wery slow :( )


If you are interested in pegwit I can send you new version for testing
(I don't want to put it now in the web, because I am not sure that I made
everything properly and there are no obvious flaws)

== <EOF> ==
Disastry  http://i.am/disastry/
http://disastry.dhs.org/pgp <-- PGP plugins for Netscape and MDaemon
remove .NOSPAM.NET for email reply
Carbon Copy by email if important - I may miss newsgroup

=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.8

iQA/AwUBOd3rQzBaTVEuJQxkEQIuwgCgvKgUACefVSY6ISQ7nauUmdCN7JkAnRyY
1udjlcrfiNFH1hwfN+iDF0+g
=wQX7
=====END PGP SIGNATURE=====

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Reply-To: [EMAIL PROTECTED]
Date: Fri, 6 Oct 2000 17:21:34 GMT

Brian Gladman <[EMAIL PROTECTED]> wrote:
: "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote:
:> [EMAIL PROTECTED] (David Crick) wrote in <[EMAIL PROTECTED]>:

:> >"The National Security Agency (NSA) wishes to congratulate the National
:> >Institute of Standards and Technology on the successful selection of an
:> >Advanced Encryption Standard (AES). It should serve the nation well. In
:> >particular, NSA intends to use the AES where appropriate in meeting the
:> >national security information protection needs of the United States
:> >government."
:>
:>    These are weseal words if nothing else. To say they will use it
:> where its appropraite does not mean anything at all. They may
:> only use it in the sense of decoding messages. And they don't say
:> where its appropriate for them to use. But I guess it is to much
:> to expect an honest anwser from them.

: Once again we can see that accuracy and objective analysis are not among
: your stronger abilities.

: You see 'where appropriate' as a 'let out' clause but you fail to notice
: that the statement also says that NSA intends to use the AES in meeting the
: national security ***information protection*** needs of the United States
: government".

: There are none so blind as those who will not see.

The get-out clause reduces the positive statement about intended use
to meaninglessness.

As always, information flows into the NSA, but not much is seen to
emerge from it.
-- 
__________                  http://alife.co.uk/  http://mandala.co.uk/
 |im |yler  [EMAIL PROTECTED]  http://hex.org.uk/   http://atoms.org.uk/

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

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Suggestion for Digital Cash System
Date: Fri, 06 Oct 2000 12:42:43 -0500

"P.C. Teo" wrote:
> 
> I am going to implement a Digital Cash System. Any suggestion of current
> existing Digital Cash System?
> 
> I need a cost effective system. Any popular system?

http://www.xs4all.nl/~brands/ will help you some.  Have you done a
web search on "digital cash"?

Patience, persistence, truth,
Dr. mike

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

From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: ISAAC PRNG
Date: Fri, 06 Oct 2000 18:07:20 GMT

I have taken a look at it, and it cranks out statistically very homogenious
numbers, and so it seem strong...  Haven't had too much time to analyse it
yet...

Albert

[EMAIL PROTECTED] wrote:

> Hi all,
>
> Is anyone aware of any effort to cryptoanalyse the Robert Jenkin's PRNG
> ISAAC?
>
> The web site for this algorithm is at:
>
> http://burtleburtle.net/bob/rand/isaacafa.html
>
> Regards,
>
> Unseenrising
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


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


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