Cryptography-Digest Digest #421, Volume #11 Sat, 25 Mar 00 23:13:00 EST
Contents:
Basic info on cryptography (Slip Gun)
Re: OAP-L3: Answer me these? ("Trevor L. Jackson, III")
Re: OFB, CFB, ECB and CBC ("Scott Fluhrer")
Re: new Echelon article ([EMAIL PROTECTED])
Re: Basic info on cryptography (Steve K)
Is netcity.com SmartCard Secure? ("KidMo")
Re: OAP-L3: Answer me these? (Mok-Kong Shen)
Re: Quantum crypto flawed agains Mallory? ([EMAIL PROTECTED])
Re: OAP-L3: Answer me these? (Mok-Kong Shen)
Re: Gray Code like (Tim Tyler)
one-way hash functions with 256-bit output (stanislav shalunov)
Re: Concerning UK publishes "impossible" decryption law (pgp651)
Re: OAP-L3: Who cares? No one's interested? (lordcow77)
Checking for a correct key (Thomas Luzat)
Re: OFB, CFB, ECB and CBC ([EMAIL PROTECTED])
Re: one-way hash functions with 256-bit output (David A Molnar)
Re: Method for time-altering keys ("Adam Durana")
Re: rc-5 plaintext guess. ("Richard Lee King Jr.")
----------------------------------------------------------------------------
From: Slip Gun <[EMAIL PROTECTED]>
Subject: Basic info on cryptography
Date: Sat, 25 Mar 2000 22:53:31 +0000
Reply-To: [EMAIL PROTECTED]
Where can a newbie to cryptography find info on the subject? Eg how to
write asymetrical (sorry about spelling) code, what they mean when they
say 128-bit encryption, etc. A website would be useful.
Thanks,
Ed
--
Those who trade privacy in favour of security will soon find that they
have neither.
------------------------------
Date: Sat, 25 Mar 2000 18:05:58 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Anthony Stephen Szopa wrote:
> "Trevor L. Jackson, III" wrote:
> >
> > Volker Hetzer wrote:
> >
> > > "Trevor L. Jackson, III" wrote:
> > > > If no one finds any flaws in your product within 60
> > > > days you keep my money, and you get to advertise the fact that you software is
> > > > flawless. Otherwise I'll split your money with the people who find the flaws
> > > > in your software.
> > > Of course, this only works if he posts the source code that he actually uses.
> >
> > I don't see the problem. If he posts flawed code he forfeits. If he posts
>flawless
> > code (har), he can reasonably claim the code he did not post was equally flawless.
>
> If I knew we were all going to have such a great time, I'd have
> brought out the barbecue and some ice cold beer.
My offer stands. You have not responsded. Should I interpret your lack of response to
mean that you decline the offer?
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Sat, 25 Mar 2000 14:53:10 -0800
<[EMAIL PROTECTED]> wrote in message
news:8bicov$44s$[EMAIL PROTECTED]...
> In a previous article, "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> >(BTW: do you really think that (say) Twofish in ECB mode would "probably
> >often" be more secure than DES in CBC mode? Certainly not for highly
> >redundant plaintext, or plaintexts where block-swapping attacks could
> >apply...)
>
> You're right about the last part. My statement only applies to attacks on
the
> key. And I am not entirely convinced that Twofish and DES are applicable
to
> my argument, but let us assume it is. A crucial premise for my argument to
be
> valid is that the ciphers in question is that secure against meet in the
> middle attacks and such, that security against attacks on the key more or
> less _only_ depends on key size and block size.
However, if you are worried about security in general, and not only against
attacks that try to retrieve the key, your premise is false -- there are
other attacks against any block cipher that can be used against ECB that CBC
is not vulnerable to (or at least, is much less vulnerable to). These
attacks do not give the attacker the key -- however, they do allow him to
deduce information about the plaintext, or manipulate it in predictable
ways. It is because of the existance of these attacks that CBC is generally
prefered over ECB.
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: new Echelon article
Date: Sat, 25 Mar 2000 11:09:53 +0000
Is there anyway to insert crypto hardware into cellphones?
I have 4 Nokia phones and 1 Nortel - as far as I'm aware none of the
manufacturers publish details on how to stick extra hardware into the
phones.
Can someone point me to info. where I can learn about the hardware layouts
inside these phones.
I've got a Nokia 3210, 6150, 7110 (a very nice one) -=- but nowhere can I
find into on the damn phones!! :-(
-Jared
Paul Koning wrote:
> John Savard wrote:
> >
> > Paul Koning <[EMAIL PROTECTED]> wrote, in part:
> >
> > >As for "laws that forbid ... encryption" -- what laws are those?
> > >There are of course regulations that disallow encryption of ham
> > >radio signals, but that doesn't carry over to other radio services.
> >
> > They do also embrace CB radio and marine band, I'm quite sure, and
> > those are a more applicable comparison to cellular telephones...
>
> Well, there's CALEA, which requires carriers to cooperate with
> wiretappers. But that doesn't prevent *users* of cellphone service
> from applying their own crypto. Quite apart from CALEA, the feeble
> crypto skills of that part of the comms industry suggests that using
> your own crypto would be wise indeed...
>
> paul
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Basic info on cryptography
Date: Sat, 25 Mar 2000 23:06:12 GMT
On Sat, 25 Mar 2000 22:53:31 +0000, Slip Gun
<[EMAIL PROTECTED]> wrote:
>Where can a newbie to cryptography find info on the subject? Eg how to
>write asymetrical (sorry about spelling) code, what they mean when they
>say 128-bit encryption, etc. A website would be useful.
>Thanks,
>Ed
>--
>Those who trade privacy in favour of security will soon find that they
>have neither.
check out:
http://fn2.freenet.edmonton.ab.ca/~jsavard/index.html
http://www.rsasecurity.com/rsalabs/faq/
http://cacr.math.uwaterloo.ca/hac/
:o)
Steve
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: "KidMo" <[EMAIL PROTECTED]>
Subject: Is netcity.com SmartCard Secure?
Date: Sat, 25 Mar 2000 17:45:16 -0600
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I was wondering if this www.netcity.com smartsecure is secure and
what is up with it. Could one of you crypto analysis people take a
look at this site and give us the 411?
Signed,
KidMo
If you have any good info email me at [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
iQA/AwUBON1PfZDtgzTwxWM9EQK5twCfZGeY7rNl1nfsh+ckjv4rCe6fURkAoIuO
wKFGzm762YBMneLIzQ99dyHQ
=nzDs
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Sun, 26 Mar 2000 01:02:19 +0100
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote:
> :
> :> There _is_ such thing as a bit flipping attack against Vernam ciphers, and
> :> OTPs are usually implemented as Vernam ciphers. The subject of bit flipping
> :> attacks has in fact been heavily discussed [...]
>
> : To my humble knowledge, the Vernam OTP, if it is an ideal one
> : (i.e. satisfying all the theoretical assumptions, though
> : unfortunately not practically obtainable), is perfectly
> : secure according to a theorem of Shannon. Thus it can't be the
> : case that there is any viable attack. [...]
>
> It's true that you can't extract any information from the message body.
>
> It doesn't mean that you can't use a known plaintext attack to completely
> recover the key, or that you can't send faked messages, or that you
> can't profitably modify modify existing ones.
>
> With a straight OTP (with no signature scheme) you can do all these things.
Sorry, I don't understand. What are you going to do in case you
have the known plaintext and recover the key used to encrypt that
plaintext? Since OTP never repeats keys, it doesn't help you to
crack anything. (The said known plaintext has certainly been
obtained by other means and that you have already. But you get
nothing helping you for the future.) I am very interested to learn
how you send faked messages in an OTP system. Could you please
give some details. Further, the meaning of the last phrase is not
clear for me. Would you please explain a little bit? Many thanks
in advance.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Sun, 26 Mar 2000 00:04:20 GMT
In article <8b813k$a91$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> I don't have time to underst throughly the math involved, but I
> understand partially. In the text you sent me, there is the need for
> secret sharing, isn't it? This is nice for some applications, but
> doesn't have the reach of regular public-key crypto. It would not be
> too useful for secure military communications. Besides this, the work
> was focused in a algorithm for information storage, not data transfer.
> Maybe you understood it better than me, could I use regular
> cryptoanalysis to derive the original quantum states? For what I got,
> it's a regular encryption algorithm applied to the quantum states...
>
I referred you to this method because it
represents the optimum in qubit encryption
and, though especially suited for data
security, it could be used for secure military
communications. However, as it requires
classical secret sharing and depending on
circumstances, it might not be as practical as
some public key- based quantum crypto
schemes. Some q. crypto proposals are not
theoretically secure but are practically
secure- the technology needed for an even
partially successful attack does not exist
(yet).
This method is proven to be
informationally secure and I don't see how it
could be broken- a classical secret sharing
scheme which is also informationally secure
could be used, the cipherstate is independent
of the input, and it's impossible for the
attacker (usually called "Eve") to create an n-
bit totally mixed state that could output
different density matrices than those of the
cipherstate.
The algorithm is a generalization of the
classical one- time- pad (OTP) concept,
applied in the quantum case. The term
"quantum algorithm" refers to algorithms
(such as Shor's) that can exploit quantum
superposition that can contain an exponential
number of different terms. These algorithms
are meant to be implemented over quantum
computation not q. crypto.
(q. computers, though, can be used to enhance
the security of q. crypto)
If you want to see a historical not- too-
technical intro to q. crypto you might start
with Singh's "The Code Book". It also
disscusses q. computers but I don't know how
much it tries to explain q. mechanics. To learn
more about q. mechanics you might start with
a focus on the concept of wave-particle
duality (which Richard Feynman believed to be
the most essential aspect of q. mechanics-
incidentally, he invented the idea of quantum
computation).
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Sun, 26 Mar 2000 01:51:26 +0100
Mok-Kong Shen wrote:
>
[snip]
> I am very interested to learn
> how you send faked messages in an OTP system.
[snip]
Sorry, I was wrong. Manipulation is possible.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Gray Code like
Reply-To: [EMAIL PROTECTED]
Date: Sun, 26 Mar 2000 00:29:20 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Note that (apart from the leading zeros), this pattern mirrors the
:> internal state of a maximal-period LFSR.
:> Consequently you could build such sequences of any given length by
:> using the tap sequence for a maximal-period LFSR [...]
: I think you're assuming that *any* maximal-length sequence can be
: generated by a suitably-tapped LFSR. Is that actually a theorem?
To be honest, I don't have the faintest idea. I /suspect/ it's true.
At any rate, the method would generate such sequences for all lengths up
to 110 - and for a large number of higher values for which maximal-length
LFSR tap sequences are known.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Brain: organ with a mind of its own.
------------------------------
Subject: one-way hash functions with 256-bit output
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sun, 26 Mar 2000 01:32:50 GMT
Modern ciphers are using key sizes of 128 bits. The NSA seems to
favor 80 bits more (Skipjack), but the price to pay for 128 isn't that
might higher.
That means (if ciphers are good) that about 2^128 operations are
required to subvert their security.
For the same to be true about one-way hash functions (and finding
collisions definitely is subversion of security, even if it cannot
produce immediate results) the output size has to be 256 bits.
Why do we use MD5 (128 bits, designed when 64-bit keys were prevalent)
and SHA1 (160 bits, designed by NSA, who want us to use 80-bit
symmetric keys) then?
Do we have secure 256-bit alternatives?
Shouldn't one be devepoled and selected just like AES?
------------------------------
Date: 26 Mar 2000 01:40:11 -0000
From: pgp651 <Use-Author-Address-Header@[127.1]>
Subject: Re: Concerning UK publishes "impossible" decryption law
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
You know many thinks, therefore where is the problem ?
In Aust you can use strong encryption. From US you can get strong encryptio=
n.
The export restriction in US is "export restriction" NOT import restriction=
=20
in Aust.
When you need strong encryption, just download it, end of the story.
In US, software designers do not have any desire to restrict YOU from getti=
ng
software, fed's has.=20
What they are doing, is to comply with fed's prohibition.
The decision is in your hands.=20
On the other hand, only stupid person will conform to such non binding=20
restrictions created in US by fed.
On Fri, 24 Mar 2000, "=D0R=EB=D0=D0" <[EMAIL PROTECTED]> wrote:
>oh, i know there is no law in australia saying we cant use any kind of
>encryption, we can have whatever we like, but most countries that have the=
>unbreakable encryption, (read 128 bit from america) cant export it to us. =
if
>we can get it, we can use it.
------------------------------
Subject: Re: OAP-L3: Who cares? No one's interested?
From: lordcow77 <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Date: Sat, 25 Mar 2000 17:46:20 -0800
<sarcasm>
Where can I download your wonderful new encryption software with
a breakthrough algorithm that cannot ever be broken? I would
love to use that same software that such competent and well-
regarded companies as Microsoft use for their security purposes.
I am truly glad that you have a coherent and detailed
description of the methodology that your encryption algorithm on
your web page that any software developer could create an
interoperable implementation without the need for additional
guidance.
</sarcasm>
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Thomas Luzat <[EMAIL PROTECTED]>
Subject: Checking for a correct key
Date: Sun, 26 Mar 2000 04:38:10 +0200
Reply-To: [EMAIL PROTECTED]
Hi,
I'd like to encrypt certain files with a user supplied key. When
decrypting them, I'd like to check whether they entered the correct
one. I see multiple possibilites:
1. Store a checksum (encrypted?)
2. Store a string like "VALID" to test for
3. Store the hashed key (encrypted?)
2 seems to be not a good solution, but what about 1 and 3; Are they
secure? Should I store those values encrypted together with the rest
of the file, too? Are there better methods?
Thomas
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OFB, CFB, ECB and CBC
Date: 26 Mar 2000 02:47:27 GMT
In a previous article, "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
[---cut---]
>there are
>other attacks against any block cipher that can be used against ECB that CBC
>is not vulnerable to (or at least, is much less vulnerable to). These
>attacks do not give the attacker the key -- however, they do allow him to
>deduce information about the plaintext, or manipulate it in predictable
>ways. It is because of the existance of these attacks that CBC is generally
>prefered over ECB.
"not vulnerable" is false and "much less vulnerable" is often true.
If the attacker knows that E_k(X) = Y and the format of a specific ECB
encrypted data transfer, then he might insert Y at a chosen position, knowing
that the recipient will interpret the block at that position as X.
However, the same attack might, under one of two conditions, work against a
CBC cipher too. The conditions are:
(a) that the attacker has gathered a sufficiently large database of
triplets <C(n-1), Pn, Cn> such that E_k(Pn xor C(n-1)) = Cn,
or
(b) that it is not essential to the attacker how the recipient
will interpret the block that preceeds the target block.
If (a), then the attacker has to wait for a message with a n-1:th cipher block
that matches a value in the database, and then insert the corresponding
manipulated cipher block at position n. (The same attack will of course work
if a sequence of m blocks are the target. It will still only be the single
block that preceeds the target that has to be matched.)
If (b), then the attacker only has to know one pair of C(n-1) and Cn that
matches the desired value of Pn, and then insert C(n-1) and Cn at their
approriate positions. The recipient will get an unpredicted value of P(n-1),
but that is assumed to be of no importance.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: one-way hash functions with 256-bit output
Date: 26 Mar 2000 02:48:57 GMT
stanislav shalunov <[EMAIL PROTECTED]> wrote:
> Do we have secure 256-bit alternatives?
There is a 320-bit version of RIPEMD obtained by modifying RIPEMD-160.
I do not know if it is really "320 bits" in this sense, though.
> Shouldn't one be devepoled and selected just like AES?
Check http://www.cryptonessie.org/ for a start..
Thanks,
-David
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Method for time-altering keys
Date: Sat, 25 Mar 2000 22:23:06 -0500
I think I follow even though your explanation could be better. But what is
the point of doing this? Letting the time affect the key just seems like a
weakness, i.e. if someone knows what time the key was made they know some of
the key bits, or the ordering of the bits depending on what your method
does. I still can't think of a case where you would want a key to be
affected by the time it was created, unless you can derive that time from
the key without giving away the key. Keys that expire are interesting but
this method does not do that. Also why even bother reordering the bits?
Just attach the output of time(0) to the end of the passphrase the user
provided.
And I do suggest you read "the statistical report analysis for time
sensitive PF417 gJq10 data proccessing routine".
- Adam
------------------------------
From: "Richard Lee King Jr." <[EMAIL PROTECTED]>
Subject: Re: rc-5 plaintext guess.
Date: Sun, 26 Mar 2000 03:36:44 GMT
another guess is:
1 "The "
2 "unkn"
3 "own "
4 "mess"
5 "age "
6 "is: "
7 "64 b"
8 "it k"
9 "eys "
10 "just"
11 " are"
12 " not"
13 " goo"
14 "d en"
15 "ough"
16 " now"
i am more certain about this one.
by putting it in cyberspace i time stamp it.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:LnWC4.69439$[EMAIL PROTECTED]...
>
> lordcow77 <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Regardless of how stupid the original poster's statement was, it
> > is not very pleasant to tell him to "go back to school junior"
> > You imply without evidence certain characteristics that he may
> > or may not possess. People on this newsgroup have been very
> > tolerant of the mistakes and inaccurate statements that you have
> > made in the past and sometimes still make as you are learning
> > about cryptography. Please do other the same courtesy that was
> > provided to you.
> >
> > By the way, in standard English syntax, sentences begin with
> > capital letters.
>
> Typically we don't control people either. Or tell them they are stupid
and
> they should find something else todo.
>
> Tom
>
>
------------------------------
** 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
******************************
