Cryptography-Digest Digest #284, Volume #14 Wed, 2 May 01 19:13:01 EDT
Contents:
Re: Re: What Is the Quality of Randomness? ("Frog2000")
Re: Intacta.Code ... ("Thomas Christensen")
Re: Intacta.Code ... ("Paul Pires")
Re: Poor NSS (Dan Bailey)
Re: A Question Regarding Backdoors ("Tom St Denis")
Re: bogus speed claims (just wondering) ("Tom St Denis")
Re: Message mapping in EC. ("Cristiano")
Re: LFSR Security (Tim Tyler)
Re: LFSR Security (Tim Tyler)
Redundancy Function and Guillou-Quisquater ("Brice Canvel")
Re: Random and not random (Tim Tyler)
Re: Random and not random (Tim Tyler)
information theoretic stream cipher ("Tom St Denis")
Blum-Micali generator ("Dobs")
cryptographicaly secure prng ("Dobs")
Re: ok newbie here ya go (Anton Stiglic)
Re: MS OSs "swap" file: total breach of computer security. ("Rickey Braddam")
Re: Censorship Threat at Information Hiding Workshop (Darren New)
Re: LFSR Security (David Wagner)
Re: LFSR Security (David Wagner)
Re: Hash function (Anton Stiglic)
Re: DES sample vector (Paul Schlyter)
----------------------------------------------------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: Re: What Is the Quality of Randomness?
Date: Wed, 2 May 2001 14:15:20 -0400
I've been kicking this stuff around for a long time. Even different
implementations of the same algorithm can drasticly affect the output.
--
http://welcome.to/speechsystemsfortheblind
"those who know me have no need of my name" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]...
> <[EMAIL PROTECTED]> divulged:
>
> >Is it sufficient to just find a "pattern" in a cyphertext?
>
> when generated by an otp? no, at least not so far as anyone has been
> able to discover. it may mean quite a lot for other ciphers.
>
> >If I were to tell you that the following highly patterned data was a
> >cyphertext, what could you tel me about the plaintext or OTP?
>
> firstly, that a miracle had occurred. second, nothing else, provided
> an otp really was used. (which the former makes highly unlikely.)
>
> --
> okay, have a sig then
------------------------------
Reply-To: "Thomas Christensen" <[EMAIL PROTECTED]>
From: "Thomas Christensen" <[EMAIL PROTECTED]>
Subject: Re: Intacta.Code ...
Date: Wed, 2 May 2001 20:19:10 +0200
Do you have a homepage to support your information about the Xerox code ..?
- TDC
"Tom St Denis" <[EMAIL PROTECTED]> skrev i en meddelelse
news:fJIH6.109931$[EMAIL PROTECTED]...
>
> "Thomas Christensen" <[EMAIL PROTECTED]> wrote in message
> news:80HH6.926$[EMAIL PROTECTED]...
> > > Sadly this is nothing more then Reed-Solomon codes and a B&W bitmap.
> >
> > Do you have some more information about the "Reed-Solomon codes" and how
> it
> > is converted into a "B&W bitmap" ..?
>
> Nope, but from what I gather from the lack of knowledge on their site
that's
> all they are doing.
>
> It's not special, it's not even remotely interesting.
>
> Interesting is Xerox's vector code stuff. It's a similar idea if I am not
> mistake except they use slashes (either / or \) to encode a message that
> looks like anything the person wants (i.e a photo or just a random
jumble).
> The decoder can turn that back into the data required.
>
> It's not more useful, just more keen.
>
> Tom
>
>
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Intacta.Code ...
Date: Wed, 2 May 2001 11:27:43 -0700
John Luebs <[EMAIL PROTECTED]> wrote in message
news:WIoH6.394236$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, "newbie"
> <[EMAIL PROTECTED]> wrote:
>
>
> > That is polite answer.
> > Thank you.
> > Tom St Denis wrote:
> >> "newbie" <[EMAIL PROTECTED]> wrote in message
> >> news:[EMAIL PROTECTED]...
> >> > A big problem with you is that you have to scan your brain before too
> >> > late.
> >> ok.
> >>
> >> >
> >> > Tom St Denis wrote:
> >> > >
> >> > > "newbie" <[EMAIL PROTECTED]> wrote in message
> >> > > news:[EMAIL PROTECTED]...
> >> > > > http://www.intacta.com/
> >> > > >
> >> > > > You may find out what you are asking for
> >> > >
> >> > > Sadly this is nothing more then Reed-Solomon codes and a B&W
> >> > > bitmap.
> >> > >
> >> > > A big problem with the intacta system is that you must scan and
> >> > > print at
> >> the
> >> > > same resolution or it won't work.
> >> > >
> >> > > Tom
>
> If Tom is lucky, newbie is a lass, and they will make a great married
> couple.
Offspring?
International treaty forbids that level of genetic manipulation.
This seems to be a clear case where someones kharma ran over their dogma.
Paul
>
>
------------------------------
From: Dan Bailey <[EMAIL PROTECTED]>
Subject: Re: Poor NSS
Date: Wed, 2 May 2001 14:44:42 -0400
Jacques Stern has confirmed that his attack doesn't apply to the current
version of NSS. We applaud his efforts in analyzing our system and
encourage the continuing public review of our technology.
Cheers
Dan
PS Yes, I work for NTRU.
On 29 Apr 2001, Dr. Yongge Wang wrote:
>
> Poor NTRU Signature Scheme is broken again.....
>
> It might still be the case that NTRU encryption scheme
> is secure. But this also illustrate that it is quite hard
> to desing a signature scheme...
> FOr more information, see:
> http://www.di.ens.fr/~stern/nss.html
>
>
> --
> ------------------------
> Yongge Wang
> http://cs.uwm.edu/~wang/
> ------------------------
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: A Question Regarding Backdoors
Date: Wed, 02 May 2001 19:00:00 GMT
"nugatory" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St denis wrote:
> > Oh gotcha. What form of a backdoor would he *want* to put in there? The
> > whole point of AES was to make a new more secure cipher that is std.
> > Why would they want to compromise it?
>
> Ohmigod... some troll has hijacked our Tom.... Maybe if I
> feed it, it'll relent and give him back to us
> unharmed.... I hope so.....
>
> OK. Original poster stated that he lived in the United States.
> Therefore he is subject to United States export regulations.
> You may not like these regulations. In fact, you may even share
> my belief that they are aggressively stupid, but based on your
> postings so far, it's more likely that you've never had to
> deal with them. If so, count your blessings.
>
> For a very long time as these things go, the US government
> prohibited the export of any strong cryptography, and many
> US software vendors were forced into the (idiotic, IMNHSO)
> position of providing weak (40-bit keys, for example)
> crypto in exported products, while still being allowed to ship
> domestic versions with much stronger encryption. In other words,
> the US government has a track record of *requiring* that exported
> software be compromised. The original origin of the technology
> is irrelevant - it's the export from the United States that's
> at issue.
>
> Of course, there was always an element of unclarity about
> just exactly what forms of cryptography would be considered
> weak enough to be granted an export license. So there have
> been recurrent rumors that some companies have been told that
> they would be granted an export license only if they built
> sme sort of backdoor into their product. I am not aware of
> any case in which someone has been willing to go on the record
> as saying that they were required to do so in exchange for
> being granted a license, but the rumors do circulate.
>
> So original poster was asking a naive but not a stupid
> question. OK troll, can you give us Tom back now?
Back.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: bogus speed claims (just wondering)
Date: Wed, 02 May 2001 19:00:43 GMT
"Ben Hamilton" <[EMAIL PROTECTED]> wrote in message
news:0FLH6.45$[EMAIL PROTECTED]...
> one word - marketing.
>
> Not everyone in this sweet world is as straightforward as you Tom.
What a shame.
Tom
>
> ben hamilton
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:TVvH6.105445$[EMAIL PROTECTED]...
> > > If you see someone claiming a code size of 500 B when he needs a 256 B
> > > table, that probably means the table is in ROM or EEPROM, and what he
> > > means is "I can make this algorithm run on a microcontroller with 512
B
> of
> > > RAM".
> > Then why don't they say that? Are they afraid it wouldn't seem so cool?
> >
> > Tom
>
>
>
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: Message mapping in EC.
Date: Wed, 2 May 2001 21:34:13 +0200
"Mike Rosing" wrote:
> [...]. If you want to embed the number "3" = 0011 in binary on a curve,
you first check to see if x=0011 satisfies the curve equation. If it does,
you're done.
>
> If it doesn't, you can change x to x=0111 and see if that point is on the
curve.
> If not, you can try x=1011. One of them is bound to be on the curve. So
when
> you get the data point, you clear the top bits and keep the data.
I use the curve 160 r1 from "SEC 2: Recommended Elliptic Curve Domain
Parameters", p is a 160 bit number (2^160-2^31-1).
If I start with m=84894A24.... (these are the firsts 32 bits of 160) it
doesn't map until m=6 84894A24... (163 bits). Is it good that m>p map on the
curve?
> [...]. You need 5 bits to make sure data will fit on the curve, so that
leaves plenty for raw data.
Is this only an aproximate measure or does it have some explanation?
Cristiano
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: LFSR Security
Reply-To: [EMAIL PROTECTED]
Date: Wed, 2 May 2001 19:44:18 GMT
In sci.crypt.random-numbers Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: Gregory G Rose wrote:
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> >Question: Does the BM algorithm apply when non consecutive outputs
:> >are known?
:>
:> A regular decimation (say, every 3rd output) of an
:> LFSR is another LFSR. B-M will apply to that. [...]
: As has been said, the real problem (new problem?) is *irregular* (but
: known) decimation of an LFSR. This is generally not another LFSR.
:> If you know the taps and where the bits came from,
:> then David's solution works anyway, the equations
:> just get more complicated.
: And if we know where the bits came from, but not the taps, what then?
Each bit at a given position in the output is still some linear function
of the seed bits - and you can express each subsequent bit as some
known number of iterations of a fixed (but unknown) linear function
of the previous state.
I believe this is sufficient to recover all the details of the system -
using linear algebra - with "not very much" output - provided the sampling
period doesn't repeatedly happen to hit the period of the LFSR.
As usual, complete linearity leads to a security disaster.
--
__________
|im |yler Try my latest game - it rockz - http://rockz.co.uk/
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: LFSR Security
Reply-To: [EMAIL PROTECTED]
Date: Wed, 2 May 2001 20:30:46 GMT
In sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
: In sci.crypt.random-numbers Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
[breaking LFSR variants]
: : And if we know where the bits came from, but not the taps, what then?
: Each bit at a given position in the output is still some linear function
: of the seed bits - and you can express each subsequent bit as some
: known number of iterations of a fixed (but unknown) linear function
: of the previous state.
: I believe this is sufficient to recover all the details of the system -
: using linear algebra - with "not very much" output [...]
It's easy to quantify how much as well - for a shift register of length
n, you get n unknowns from the unknown initial state of the register, and
n unknowns from the unknown taps - one for each possible position.
To recover all the details of the system, you thus need 2*n linear
equations - and consequently 2*n bits of output - just the same as
the BM algorithm needs, in fact.
--
__________
|im |yler There's no escaping the Rockz - http://rockz.co.uk/
------------------------------
From: "Brice Canvel" <[EMAIL PROTECTED]>
Subject: Redundancy Function and Guillou-Quisquater
Date: Wed, 2 May 2001 21:56:52 +0100
Following my previous post ealier, i have had a look at the Handbook of
Applied Cryptography and found most of the information i was looking for on
the Feige-Fiat-Shamir and Guillou-Quisquater identification schemes.
However, in the GQ scheme, i don't quite understand what the redundancy
function is and what it does.
Could anyone help please?
Thank you.
Brice.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Reply-To: [EMAIL PROTECTED]
Date: Wed, 2 May 2001 20:46:49 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: John Savard wrote:
:> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
:> >Dumb question: What is the function of the conventional
:> >cipher (i.e. it seems to be redundant here)?
:>
:> Its key is less bulky, so it can be distributed more securely. The OTP
:> keys are bulky, so the risk of their being intercepted is higher, and
:> without a conventional cipher, it's trivially obvious what to do with
:> them.
: I think that I disagre a bit. An OTP (to be securely
: transported, e.g. through diplomatic currier) is either
: intercepted or not. [...]
There can still be degrees of interception:
The pad is thrown into the water from a ship. It is rapidly rescued - but
the ink on the first and last pages has dissolved (as it was designed to
do).
I'm sure many more plausible "just so" stories along similar lines can be
concocted. Any partial destruction of the key would qualify - and
the courier might well attempt to destroy the key, rather than have it
captured.
Also, John what hypothesizing that the interception probability depended
on the size of the key - not an unreasonable idea.
--
__________
|im |yler Try my latest game - it rockz - http://rockz.co.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Reply-To: [EMAIL PROTECTED]
Date: Wed, 2 May 2001 20:52:51 GMT
Matthew Skala <[EMAIL PROTECTED]> wrote:
: John Savard <[EMAIL PROTECTED]> wrote:
:>So by using both the COTP, and the *true* OTP, or UOTP, plus layers of
:>conventional encryption, one has better confidence in one's message
:>being obscured! It is mathematically unbreakable, because a UOTP is
:>used; it is obscured, because a COTP is used, it is not easily
:>readable if a breakdown happens in handling the large masses of key
:>material, because a conventional cipher is used.
: I suspect that you know this and are pulling our legs [...]
John's article seems quite serious and perfectly correct to me.
I too can easily imagine advocating applying a conventional cypher -
in addition to an OTP - in order to improve the security of the latter.
Ideally the respective keys should be distributed (or at least
generated) in differing ways.
--
__________
|im |yler Try my latest game - it rockz - http://rockz.co.uk/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: information theoretic stream cipher
Date: Wed, 02 May 2001 21:20:14 GMT
Ok no secret primes here :-)
Pick a public prime (say >2^128) you then divide the message into blocks
M_1, M_2, such that 0 < M_i < p, eg they are all units wrt to Z*p.
The cipher has two variables in it's state A and B both of which are the
same magnitude as the prime. (say 128-bits). Both belong to Z*p as well.
To encode a block you perform
1. C_i = M_i * A + B mod p
2. Update A
3. Update B
4. If A is zero goto 2
Let's suppose the update in #2 and #3 is perfect, then to break this you
have to either determine A or B from random. Since this is pair-wise
decorrelated it's hard to tell. You know one impossible value of B, e.g. B
= -C_i since the first part cannot be zero. Other than that I dunno.
As for #2 and #3 what would be required. Off the top of my head I am
thinking of a simple LCG. This is vulnerable to a divide and conquer attack
though wher you guess either A and B and see if it holds (i.e the update
rules make sense). If A and B are 128-bits each this shouldn't be a
problem.
Another problem is how to encode zero blocks. I would say that if you have
p>2^128 you could simply encode them as 128-bit blocks and do the transform
C_i = (M_i + 1) * A + B mod p. This would chop off a whole bunch of values
of A and B since we know M_i is <= 2^128 but I doubt it would be enough to
tell em from random.
Yet another final problem is that the ciphertext would be a bit longer than
the plaintext. In this case it would be a single bit larger which really
shouldn't cause a problem.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Blum-Micali generator
Date: Wed, 2 May 2001 23:41:51 +0200
The main formula for this generator is Xi+1=(a^Xi) mod p.
The generator to be cryptographicaly secure have to have p very big (512
bit) and it have to be prime. What about a, can it be any
number???????????????
Should p have to have any more futures????
I am using openSSL library but I can not find function to count a^x mod p.
Where can I find such a function or how to do it?
Thanks
Best Regards
Mike D
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: cryptographicaly secure prng
Date: Wed, 2 May 2001 23:53:36 +0200
I have implemented generators such as BBS, RSA,Micali-Schnor and
Blum-Micali generators.However I need one more cryptographicaly secure
generator. Can U advise me one more such a generator which is very easy to
implement(-short algorithm) and is secure. Can U also write me an algorithm
to it.
Thanks
Best regards
Mike D
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: ok newbie here ya go
Date: Wed, 02 May 2001 18:20:43 -0400
The key is
61 3c 30 2a 80 5b 9f c8 8a 66 e3 50 da 47 e3 64
c7 f8 ac 2c 01 a9 d6 05 3d 95 2f cd df 69 9c 60
ae 28 20 e3 aa e9 5f 36 4b ac 48 fc 04 1f 3e ca
c0 4f f0 7c d4 56 49 c5 9a fb c1 aa 3e 65 52 0c
7c 99 f3 12 f6 ae 1b fe 00 fc 66 b5 70 d8 fa ee
a1 fe 08 d4 67 d7 44 3c 21 83 90 35 73 15 ca 1a
eb 6a fe a9 23 e7 e6 b2 ee c4 27 ea 3f 74 17 f5
0c a8 bc bc 06 39 0c 0f 53 80 f3 f5 0b 74 ec 2c
d6 d5 91 f5 14 61 c9 b3 ed
which makes the plaintext to be
54 6f 6d 20 53 74 2d 44 65 6e 69 73 20 6c 69 6b
65 73 20 74 6f 20 73 74 61 72 74 20 66 6c 61 6d
65 73 2c 20 65 73 70 65 63 69 61 6c 79 20 77 69
74 68 20 4e 65 77 62 69 65 73 2e 0a 4e 6f 20 6f
6e 65 20 68 65 72 65 20 72 65 61 6c 6c 79 20 6b
6e 6f 77 73 20 77 68 79 2c 20 69 74 27 73 20 61
20 62 69 67 20 6d 69 73 74 65 72 79 2e 0a 54 69
64 6c 65 79 20 62 65 65 2c 20 74 77 69 64 6c 65
20 61 6e 64 20 64 65 65 2e
Formatting this last hexadecimal representation to
Unix's 'xxd' format, we get:
0000000: 546f 6d20 5374 2d44 656e 6973 206c 696b
0000010: 6573 2074 6f20 7374 6172 7420 666c 616d
0000020: 6573 2c20 6573 7065 6369 616c 7920 7769
0000030: 7468 204e 6577 6269 6573 2e0a 4e6f 206f
0000040: 6e65 2068 6572 6520 7265 616c 6c79 206b
0000050: 6e6f 7773 2077 6879 2c20 6974 2773 2061
0000060: 2062 6967 206d 6973 7465 7279 2e0a 5469
0000070: 646c 6579 2062 6565 2c20 7477 6964 6c65
0000080: 2061 6e64 2064 6565 2e
for which 'xxd -r' gives us
Tom St-Denis likes to start flames, especialy with Newbies.
No one here really knows why, it's a big mistery.
Tidley bee, twidle and dee.
The surprising part to me is the "Tidley bee, twidle and dee."
There is also spelling errors.
But in any case, try it out for yourself!
--Anton
Tom St Denis wrote:
>
> Here's a lengthly (somewhat) ASCII message encrypted with a OTP (plain xor).
> Decrypt it using your method!
>
> 35 53 5d 0a d3 2f b2 8c ef 08 8a 23 fa 2b 8a 0f
> a2 8b 8c 58 6e 89 a5 71 5c e7 5b ed b9 05 fd 0d
> cb 5b 0c c3 cf 9a 2f 53 28 c5 29 90 7d 3f 49 a3
> b4 27 d0 32 b1 21 2b ac ff 88 ef a0 70 0a 72 63
> 12 fc d3 7a 93 dc 7e de 72 99 07 d9 1c a1 da 85
> cf 91 7f a7 47 a0 2c 45 0d a3 f9 41 54 66 ea 7b
> cb 08 97 ce 03 8a 8f c1 9a a1 55 93 11 7e 43 9c
> 68 c4 d9 c5 26 5b 69 6a 7f a0 87 82 62 10 80 49
> f6 b4 ff 91 34 05 ac d6 c3
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org
--
___________________________________
Anton Stiglic <[EMAIL PROTECTED]>
Software developer & Cryptologist.
Zero-Knowledge Systems Inc.
___________________________________
------------------------------
From: "Rickey Braddam" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Wed, 02 May 2001 22:25:31 GMT
"David Hopwood" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> It is possible, just about, but what is far from obvious from the
> Microsoft documentation is that it can *only* be done via a ring 0
> device driver, not directly from an application. In fact even with
> the co-operation of a device driver, it's decidedly non-trivial to
> access locked memory from a Windows application.
True, but it has been done. In the sources for PGP 6.58 there is the
PGPmemlock.vxd (and .sys for NT) driver which uses _LinPageLock(...) to lock
memory allocated with VirtualAlloc(...). The lock and unlock functions are
accessed via DeviceIOControl(...), which is clumsy, but it is at least
possible. Actually, I'm surprised that similiar techniques have not been
included in the CryptoPP and Cryptlib libraries. Wei Dai? Peter?
Rick
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Wed, 02 May 2001 22:26:39 GMT
Paul Pires wrote:
> > > > Imagine if this happened with patents. "Well, it expires in 6 months, so
> > > > we'll just wait." Five months later: "Whoops! Now we have to wait anouther
> > > > 10 years."
> > >
> > > Actually, I'd cry all the way to the bank.
> >
> > Not if you were the company waiting for the patent to expire.
>
> Were do you get this? You make it sound as if companies are wasting
> away just waiting for these barriers to be lifted. This is a nieve take
> on what really happens. The patent is an asset. It has value. I can give
> you many more examples of business's not proceeding because the
> remaining term is not long enough. Cases where a new product is being
> ignored by the entrenched market leaders but where a second tier player
> knows that once the idea gets their attention, the big boys will wax him.
You're still looking at it from the wrong POV. I'm saying that I want to use
what you have patented. My choice is to pay you a license fee, or to wait
for the patent to expire. If I decide to wait, it's rather problematic if
congress starts extending the patent duration just as the patent is about to
run out.
You're looking at it from the POV of the patent owner. I intended you to
look at it from the POV of the person who does *not* own the patent.
> > > Agreed, it is a bad way do do business but don't lay it at Doug's door.
> >
> > Uh, I wasn't laying anything at Doug's door. I was just pointing out that
> > copyright can't be interpreted as enforcement of a private contract. I.e.,
> > that "copyright" isn't protecting the author's ability to make a living if
> > the terms of the contract change after the author is dead. :-)
>
> Doug Gwyn said nothing like that. He did not say that it was
> an agreement between two people he said it is an agreement of the
> author to abide by the provisions of his government.
> "He agrees to let use[us] use it for certain purposes under
> certain conditions,...." Who is he agreeing with? The
> government.
Oh. I read it as agreeing to let the purchaser of the music CD (for example)
have a copy. In particular, "us" is rarely "the government", methinks.
Especially since there are special rules for what the government gets to
copy vs what us mere citizens get to copy.
He later says
> If you then do not follow the terms, you have broken a (possibly implied)
> contract.
There's no contract involved, however. There's certainly no contract between
the author and the government, nor is there between the buyer of the music
and the government, so I'm not sure where you're seeing any "I agree to let
you use it, where you are the government" involved. If the government
doesn't follow the terms, they haven't broken any contract. They've either
broken the law, or changed the law.
> Author seeks grant, shows compliance, agrees to terms.
> Government grants boon and enforces it.
Whatever.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Invasion in chinese restaurant:
ALL YOUR RICE ARE BELONG TO US!
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 2 May 2001 22:30:47 GMT
Tim Tyler wrote:
>Each bit at a given position in the output is still some linear function
>of the seed bits - and you can express each subsequent bit as some
>known number of iterations of a fixed (but unknown) linear function
>of the previous state.
>
>I believe this is sufficient to recover all the details of the system -
>using linear algebra - with "not very much" output - provided the sampling
>period doesn't repeatedly happen to hit the period of the LFSR.
Yes, but how? That's exactly the question under consideration,
just rephrased in slightly different language, and I don't see how
the rephrasing helps.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 2 May 2001 22:31:30 GMT
Tim Tyler wrote:
>It's easy to quantify how much as well - for a shift register of length
>n, you get n unknowns from the unknown initial state of the register, and
>n unknowns from the unknown taps - one for each possible position.
>
>To recover all the details of the system, you thus need 2*n linear
>equations - and consequently 2*n bits of output - just the same as
>the BM algorithm needs, in fact.
But you don't get 2n linear equations. If you work out what the
equations are, they are nonlinear. Try it on an example and see
for yourself!
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Hash function
Date: Wed, 02 May 2001 18:32:07 -0400
Are you looking for a cryptographic hash function, or just a regular
hash function?
> *. There is a key of 64 bits (QWord).
> [1a]. Take the text, append to it its length.
> [2a]. Pad the text till it reaches a length which can be divided into QWords
> (e.g. 16 chars).
Pad it with 0 I guess?
> [1b]. Take each (char's asci) * (it's position in the text)
What do you mean by position in the text? Do you mean the position of
the
string resulting from [2a] (with the length concatenated at the
beginning,
and padding at the end?). And is there any carries? (what do you do
with them?).
> [2b]. Then XOR [1b] with the partial value of the key.
I don't understand this part exactly. What is the partial value of the
key?
>
> [1c]. Split the result of [2b] into an Array of DWords.
> [2c]. XOR all the blocks (block1 ^ block2 ^ block3 etc.), while every even block is
> reversed ($ae34 --> $43ea).
> 3c. The result is a DWord (... yes I know).
Maybe some diagram description would help?
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: DES sample vector
Date: 2 May 2001 23:21:23 +0200
In article <[EMAIL PROTECTED]>,
Frederic Donnat <[EMAIL PROTECTED]> wrote:
> I'd like to implemente DES algorithm in java but i don't manage to find
> test vector ! :-(
> I mean test vector to test each round and the final computation.
> Can someone point me to a place where i can find that please. ;-)
The first case below, "DES Codebok", is right from the FIPS document
which describes the DES algorithm. The other three cases I constructed
myself, and I've found them useful when testing new DES implementations.
DES CodeBook
Key: 01 23 45 67 89 AB CD EF
ASCII: N o w i s t h e t i m e f o r a l l
Clear: 4E 6F 77 20 69 73 20 74 68 65 20 74 69 6D 65 20 66 6F 72 20 61 6C 6C 20
Crypt: 3F A4 0E 8A 98 4D 48 15 6A 27 17 87 AB 88 83 F9 89 3D 51 EC 4B 56 3B 53
DES CBC
Key: 01 23 45 67 89 AB CD EF
IV: 01 23 45 67 89 AB CD EF
ASCII: N o w i s t h e t i m e f o r a l l
Clear: 4E 6F 77 20 69 73 20 74 68 65 20 74 69 6D 65 20 66 6F 72 20 61 6C 6C 20
XOR: 01 23 45 67 89 AB CD EF 96 C3 D4 A6 DC 1C 01 17 76 97 08 E9 C6 1D 28 58
XClear: 4F 4C 32 47 E0 D8 ED 9B FE A6 F4 D2 B5 71 64 37 10 F8 7A C9 A7 71 44 78
Crypt: 96 C3 D4 A6 DC 1C 01 17 76 97 08 E9 C6 1D 28 58 F1 05 77 7D D5 51 7D AB
DES3 CodeBook
Key 1: 00 11 22 33 44 55 66 77
Key 2: 88 99 AA BB CC DD EE FF
ASCII: N o w i s t h e t i m e f o r a l l
Clear: 4E 6F 77 20 69 73 20 74 68 65 20 74 69 6D 65 20 66 6F 72 20 61 6C 6C 20
Crypt1: ED FC 77 AE 9B 3C C0 47 A8 B4 D9 9D A7 29 F8 29 C6 C2 C4 3F 65 EC 4E 1A
Decry2: 33 EE E1 6E 46 B9 19 42 A0 3C 62 5E C5 5F 3A 78 7D C8 34 95 89 B8 DE B4
Crypt3: 1D 5D E8 95 51 03 3F DF E9 42 B9 E2 83 C7 88 46 25 3B A3 0E CE 0C DF F8
DES3 CBC
Key 1: 00 11 22 33 44 55 66 77
Key 2: 88 99 AA BB CC DD EE FF
IV: 01 23 45 67 89 AB CD EF
ASCII: N o w i s t h e t i m e f o r a l l
Clear: 4E 6F 77 20 69 73 20 74 68 65 20 74 69 6D 65 20 66 6F 72 20 61 6C 6C 20
XOR: 01 23 45 67 89 AB CD EF 98 93 4C 64 A2 A3 F7 F5 2A 34 E7 E8 CD 9B 4D 87
XClear: 4F 4C 32 47 E0 D8 ED 9B F0 F6 6C 10 CB CE 92 D5 4C 5B 95 C8 AC F7 21 A7
Crypt: 98 93 4C 64 A2 A3 F7 F5 2A 34 E7 E8 CD 9B 4D 87 0A 74 4F 03 1F BE A3 53
--
================================================================
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
------------------------------
** 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
******************************
