Cryptography-Digest Digest #931, Volume #12 Sun, 15 Oct 00 12:13:01 EDT
Contents:
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: Credit (redux) - is this the right place ("Lyalc")
Re: Why trust root CAs ? ("Lyalc")
Re: Is it trivial for NSA to crack these ciphers? (CiPHER)
Re: SHA-256 implementation in pure C (free) (Tom St Denis)
Re: Is it trivial for NSA to crack these ciphers? (CiPHER)
Re: byte != octet [was: Re: Rijndael implementations ] (Bernie Cosell)
Re: FTL Computation (ca314159)
Re: block-cipher silly question? (SCOTT19U.ZIP_GUY)
Re: Optimisation of SHA-256 (Daniel =?iso-8859-1?Q?L=E9onard?=)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Sun, 15 Oct 2000 12:44:12 +0200
Bryan Olson wrote:
...........
[snip]
Thank you very much for writing a very long follow-up with
a new attack. However (excuse me for my un-intelligence
and poor knowledge) I have the impression that there is a
fundamental misunderstanding (presumably 'entirely' on my
side) that needs to be cleared up, before I could really
digest your stuff and attempt a sensible reply (or ask
sensible questions on your material). You employ in the
attack a single unique block (u,v). Does it matter much if
you use (u,u) instead (or once (u,u) and a second time
(v,v))? If yes, why? If you do the same to the original
block cipher as such (i.e. forgetting my scheme), do you
have a better chance or worse chance of success? Could
you please kindly say something about the 'basic' reasons
(i.e. the 'causes') underlying the answer to that question?
>From my intuition alone, attacking the 'original' cipher
with the same technique (or any other techniques) should
be easier, since one need not try so much material that
is rendered necessary owing to the 'confusion' (in the
common sense) caused by the unknown permutations. In other
words, I unfortunately fail yet to see the 'fundamental
trick' underlying your attack in its depth that renders
the same technique of attack simpler (having higher quote
of success) in the presence of permutations. I am aware
that intuition could very well lead one astray. But that
seems to be blocking my delving into your material in
depth at the current moment.
I am posting parallelly an addendum to my original post
for the general reader, explaning in a bit more formal
manner. Please have a look of that to see whether I have
explained the idea of mine clear enough.
Thanks in advance.
M. K. Shen
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Credit (redux) - is this the right place
Date: Sun, 15 Oct 2000 22:06:20 +1000
For simple protection during transmission, use SSL.
To store the card details, use DES,3DES or one of the 128 bit alg (AES,
Blowfish, RC4, Rc5, rc6 et al)
To authenticate who is using the card, use the ISO 8583, ANSI X9 series of
standards and hardware crypto at both ends.
Lyal
Steve Sobol wrote in message ...
>So, since no one answered my question about encrypting credit card info..
>is this the proper newsgroup? is there another forum that might be more
>appropriate?
>
>Are people just afraid that I'm going to sue them if I use their
suggestions
>and my data is compromised anyhow?
>
>HELP! (I know barely enough about crypotgraphy to be dangerous, and I know
>how to use OpenSSL and some of the functions of libcrypto, but that's about
>it :)
>
>Thanks.
>
>
>--
>A beautiful Chow puppy was rescued a couple months ago from the Geauga
County,
>Ohio animal shelter and has been fostered in a home in Montville, OH. After
>receiving medical care and much love, he's ready for a permanent home.
>
>http://www.WrinkleDogs.com/rescue/fall2000/
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sun, 15 Oct 2000 22:14:02 +1000
Comment inline
[EMAIL PROTECTED] wrote in message
<[EMAIL PROTECTED]>...
>On Sat, 14 Oct 2000 19:43:28 +1000, "Lyalc" <[EMAIL PROTECTED]>
>wrote:
>
>>If you replace Public Key with Password, this models works just as well,
and
>>works today, at zero incremental cost.
>
>Scheme outlined has advantages over passwords which may justify the
>incremental costs. EG:
>- a password is inherently less secure since it relies on keeping the
>password secret, and yet password is known to all entities/devices for
>which you use that password. A public key can be put on a bill board
>without lessening security.
Yet private keys, that public keys depend upon are protected by the same
password you claim are insecure. Weakest link rules apply here!
>- using a public key approach allows enables encryption of data unique
>to the user, increasing security.
So does SSL - except encryption is unique to the user and the session.
>- the use of a device to handle the registration and authentication
>simplifies the process from the point of view of the end user and
>obviates the need to handle, remember and keep secure multiple
>passwords.
But we (the vendor driven security community) are building solutions that
require 1 cert/public key for every user environment. We either implement
unique passwords for private keys among these solutions, or let everyone
choose the same password.
The outcome is the same: password = PKI (at least until unbreakable
biometrics platforms comes along, if it ever does)
Lyal
>
>
>PB
>>Lyal
>>
>>
>>[EMAIL PROTECTED] wrote in message
>><[EMAIL PROTECTED]>...
>>>On Sun, 08 Oct 2000 05:10:53 +0100, David Hopwood
>>><[EMAIL PROTECTED]> wrote:
>>[snip]
>>
>>>This model can be further generalised.
>>>
>>>Let's suppose you generate your own public key and register it with
>>>your bank at time of opening your account. Then whenever you sign a
>>>transaction with your private key, your bank knows it is you.
>>>
>>>But this could also apply to any other situation where a signature (or
>>>any other verification of identity) is currently required - simply
>>>register your public key and then use your private key to authenticate
>>>your identity in all transactions with that party from then on.
>>>
>>>This could extend to verifying your identity to hardware. Your car,
>>>your house locks, all these could be built to enable you to initially
>>>register a public key and only open/operate from that point on when a
>>>random session id is returned signed by the private key corresponding
>>>to your public key.
>>>
>>>It could also apply to software - replacing the need for all the
>>>myriad passwords one accumulates for different systems, as you could
>>>associate your public key with your various computer userids on each
>>>system and then return a signed random session ID to verify yourself
>>>at logon.
>>>
>>>Furthermore, for those concerned with privacy and the fact that the
>>>public key is a unique id across all applications, enabling traffic
>>>analysis of your movements, habits and usage, one could simply allow
>>>that any person can have as many public keys as they want. This could
>>>present problems for the user in remembering which key they'd
>>>registered with which entity/device, but then we manage to handle a
>>>number of different house keys, car keys passwords etc etc.
>>>
>>>But lets suppose that:
>>>. the method of carrying and issuing the public key and storing and
>>>using the private key is a PIN protected or bio-recognition smart card
>>>. they cost $9 apiece at your local newsagent;
>>>. come in a security sealed package from reputable suppliers;
>>>. there is common software/hardware to enable you to generate or
>>>load your own key;
>>>. they have a roughened front surface on which you can write Car,
>>>House, Third National Bank, HomePC, WorkID etc etc, and
>>>. a hole drilled in the top right to enable them to be kept on a key
>>>ring...
>>>
>>>I have neglected issues of card loss, key revocation etc etc, but I
>>>dont think these are insurmountable.
>>>
>>>As I understand it the major barrier to this approach is that there is
>>>no universal, simple, secure, portable thingy that can carry the keys,
>>>and do the processing required. The obvious candidate is a smart
>>>card, but I understand they simply do not (yet) have the processing
>>>power to handle digital signing using an assymetric key (eg RSA).
>>>Offloading the processing presumably creates security problems.
>>>
>>>PB
>>>
>>>
>>>>- --
>>>>David Hopwood <[EMAIL PROTECTED]>
>>>>
>>>>Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
>>>>RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15
01
>>>>Nothing in this message is intended to be legally binding. If I revoke a
>>>>public key but refuse to specify why, it is because the private key has
>>been
>>>>seized under the Regulation of Investigatory Powers Act; see
>>www.fipr.org/rip
>>>>
>>>>
>>>>-----BEGIN PGP SIGNATURE-----
>>>>Version: 2.6.3i
>>>>Charset: noconv
>>>>
>>>>iQEVAwUBOd+BhzkCAxeYt5gVAQEqEAf/RCjAXabrazj+oceIj+d8/WC/I+91mHwc
>>>>P5URHoux22bLAN8XOWBe0TK04UVwtR1d0Pt/mA1S1svTbrJ+JAFH3hR1hrr/88eU
>>>>Z1MwH+lbK96oYZbN6sSI3gmvyg/zPS4zXkgW6L9WJfP4Na6wrcjvAH1E9kpGlWcD
>>>>UtzO+ida9CsKo63FW9KZ+nCBvztt1iqZSZI7v/XSfXL35VuzvJq30JPKeyiSA7Lr
>>>>2TqH6v4mma6Scph641KnLWH1BNBavyq2jTvbix5aWkiFnTFvrsAQvpAeGPlsYB0W
>>>>+fOuDdEbmOIowjR/oMR0A+kZ7lDDhhgkwYvQ4mLvEKsCXr2Obq2DEw==
>>>>=+OuX
>>>>-----END PGP SIGNATURE-----
>>>>
>>>
>>
>>
>
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sun, 15 Oct 2000 12:02:53 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> That's another notion, in the opposite direction, without supporting
> evidence.
Ahhh, but the jist of my arguement (and history) is that we wouldn't
know one way or the other anyway if intelligence agencies have the
power to break powerful ciphers. Therefore, of course, I'm not going to
have supporting evidence.
When it takes 30/40 years or so for, say, the GCHQ to announce that,
yes, they did indeed break war-time ciphers and were involved in
creating some that were later commercially 'discovered' (without prior
knowledge) then I think it's fair to say such practice would still take
place.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Sun, 15 Oct 2000 12:16:43 GMT
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> > At http://www.geocities.com/tomstdenis/files/sha256.c you can find a
> > free copy of the SHA-256 hash function in C. It's rather easy to
drop
> > in and use. I hope SHA-256 is in fact secure though... heheheh
>
> Okay, hotshot, now let's see you do SHA-512. No fair peeking at
> http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=681517214.
Well first off, I would change "unsigned long" to "unsigned long long"
then I would change the constants and some other trivial stuff.
Personally I think both algorithms are stupid but SHA-256 has more use
then SHA-512. Like who would put 2^256 effort to forge a msg anyways?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sun, 15 Oct 2000 12:16:50 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> But we don't have to venture into alternate history to determine if
> the NSA would have "done something" sufficient to prevent the
> development of ciphers it cannot break. Because we know that such
> ciphers exist, that how to construct them is public knowledge, and the
> NSA has not suppressed it!
Yes, but to assume that the NSA cannot break them is what I'm getting
at. My belief is that the only ciphers the 'general public' gets to
freely utilise are those that the NSA already has a system for.
Therefore they _wouldn't_ attempt to suppress it, because that would be
detrimental to their own operations.
> Maybe the NSA can break Triple-DES and Rijndael like nobody's
> business. But the major cipher designs in use are *scalable*.
Assuming that they don't have more powerful computers than those doing
the scaling.
> Unless one is willing to claim that the NSA is capable of breaking a
> block cipher with an infinite block size, an infinite number of
> rounds, and an infinitely long key...their abilities must stop
> somewhere.
Yes, but this is all very well if you aren't wanting to read the data
sometime this century, but rather just store it... but getting at what
I've just mentioned, if you're planning on deciphering it sometime soon
then certainly it's just a computer power race.
I believe that, at best, you should only assume a cipher will provide a
stumbling block towards anyone that would want the information. Much
like dead-bolt locking your front door of your house... or putting a
steering lock on your car. It's likely to stop those who don't have the
means to get around it... but those that have the means, the will, and
the knowledge could probably break in at a much faster pace than you
could imagine.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bernie Cosell <[EMAIL PROTECTED]>
Subject: Re: byte != octet [was: Re: Rijndael implementations ]
Date: Sun, 15 Oct 2000 09:09:20 -0400
[EMAIL PROTECTED] (Rob Warnock) wrote:
} John Savard <[EMAIL PROTECTED]> wrote:
} +---------------
} | But I have seen it claimed that DEC used the term "byte" to refer to
} | the variable-size characters of the PDP-10.
} +---------------
}
} Indeed, and the instructions which manipulated bytes & byte pointers were:
}
} LDB LoaD Byte
} ILDB Increment [byte pointer and then] LoaD Byte
} DPB DePosit Byte
} IDPB Increment [byte pointer and then] DePosit Byte
} IBP Increment Byte Pointer
} ADJBP ADJust Byte Pointer
And indeed, what became pretty much the standard for us was the 7/5 byte
pointer: 5 7-bit ascii characters per word, with the hardware smoothly
skipping the one leftover bit at the end of the word. ==> 7 bit bytes. On
other DEC machines, 9-bit-bytes were the standard [half-words, or
quarter-words on the 6/10s]
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Sun, 15 Oct 2000 13:23:25 GMT
I suppose one could navigate an interstellar ship, or science,
by dead-reckoning, and, that tends to limit one to luminal speeds.
Still, there's alot to be said for the scenic route.
Have a nice long trip.
In article <jn%F5.45398$[EMAIL PROTECTED]>,
"Paul Lutus" <[EMAIL PROTECTED]> wrote:
> ca314159 <[EMAIL PROTECTED]> wrote in message
> news:8s9i0g$etp$[EMAIL PROTECTED]...
>
> > Having fun, usually means, going alittle nuts;
> > is there no fun left in science ? And whether
> > one thinks the twin paradox, particle-wave duality,
> > Schrodinger's dead and alive cat (they really knew
> > how to have fun with science back then) are nutty
> > ideas or valid conjectures, depends on your
> > subjective attitude often more than the measurements.
>
> I had previously suggested that you were discussing New Age Physics
instead
> of the kind one can verify or defend with reasonable argument. This
only
> proves it.
>
> Each of the topics you used as examples are backed up by both theory
and
> observation. None of them depend on one's "attitude."
>
> This says it all:
>
> " ...depends on your subjective attitude often more than the
measurements."
>
> In physics, the measurements are more important than your attitude. In
> superstition, the reverse.
>
> Your post contains not one word of physics. It uncritically mixes
concepts
> having nothing on common (quantum and FTL, as just one example), it
argues
> about how things "ought to be" rather than how science describes them.
It is
> sci-fi, not sci. There is a reason "sci" is part of the three
newsgroup
> names you have arbitrarily chosen -- that is our topic.
>
> On reading your argument about how real science isn't any fun, one
can't
> help wondering why you are posting to a science newsgroup.
>
> Now that you have abandoned the original topic entirely, now that you
are no
> longer even pretending to be discussing physics, please move your
fluffy
> discussion to an appropriate New Age newsgroup.
>
> --
>
> Paul Lutus
> www.arachnoid.com
>
>
--
--
http://www.bestweb.net/~ca314159/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: block-cipher silly question?
Date: 15 Oct 2000 13:30:02 GMT
[EMAIL PROTECTED] (N. Weicher) wrote in
<[EMAIL PROTECTED]>:
><< If the user can prevent certain attacks such as chosen plain text
>attacks. And if the files are prewhittened and compressed with 1-1
>compressors. IN a secret way. Like using my compressor with a secret
>condition file. He could then encrypt the resultant file with a normal
>8 bit block cipher and it would not be trival to break. >>
>
>Thanks for the reply. Can you elaborate? Are you referring to your
>scott16u?
I wish I could elaberate but not very good at that, But you
can check my site out for better compression such as referenced
above and NO i was not refering to scott16u. Scott16u treast the
whole file as a single block.
>
>Thanks.
>
>Neil
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Daniel =?iso-8859-1?Q?L=E9onard?= <[EMAIL PROTECTED]>
Subject: Re: Optimisation of SHA-256
Date: Sun, 15 Oct 2000 11:18:11 -0400
Stephan Eisvogel wrote:
>
> Daniel L�onard wrote:
> > If I keep the loops, it goes faster (long live compiler technology ? :).
> > If the main loop is kept, it goes faster than if I unroll it.
> > Also, if the loop to build the W vector is kept (I unrolled it too), my
> > implementation is faster still.
>
> What CPU do you have? Pentium II class? What you see is the effect of
> L1/L2 cache code/data trashing when you unroll your loops. If you keep
> the loop, the code will stay in L1 cache and execute much faster than
> code that does the same, does away with the conditional branches but
> needs to be reloaded from L2 cache or even RAM because it is too large
> to be kept in L1 completely. Loop unrolling was nice for 8086...
My CPU is a Pentium MMX 200 Mhz. And my code was not C nor C++, but in
Java, running on:
$ java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
I suspect, after reading your informative post, that since hashing is at
the bit level (and also at the integer - 32 bits - level), HotSpot did a
nice job JIT'ing it.
With your last sentence "Loop unrolling was nice for 8086...", do you
mean that we should stop unrolling loops and just let the compiler do it
for us ?
> --
> hawo bofh
And no I won't give you my user name :)
=================
Daniel L�onard (aka fork)
Computer Science Student
Universit� de Montr�al
"The nuclear warhead is one of the Humans' most efficient weapons. They
first tested it on themselves, obliterating several entire cities. The
intervening centuries since the weapon's first use had not dimmed its
effectiveness, as the Black Star proved when it blew apart. It was, from
all accounts, a most impressive display and took - by the standart of
such thing - quite some time as one section after another after another
of the ship erupted."
- Emperor Londo Mollari, Babylon 5 : In the Beginning
------------------------------
** 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
******************************
