Cryptography-Digest Digest #997
Cryptography-Digest Digest #997, Volume #13 Sun, 25 Mar 01 17:13:01 EST
Contents:
Re: RC4 test vectors after gigabyte output?. (Gregory G Rose)
[STATS] Septic asks more of nice TLA (Anonymous)
Re: [STATS] Septic asks more of nice TLA ("Tom St Denis")
Re: RC4 test vectors after gigabyte output?. (Gregory G Rose)
Re: Compression-encryption with a key (SCOTT19U.ZIP_GUY)
Cmeclax asks to eat radishes (Anonymous)
NSA needs to encode terrible algorithm ("A. Melon")
Rascal would love perl scripts (Anonymous)
Shinn requires to read some Kenneth Pangborn (lcs Mixmaster Remailer)
Data Dependent Crypto (Ichinin)
Cracow wants to fuck faggots (Anonymous)
His in-law loves NSA (Anonymous)
Re: [STATS] Septic asks more of nice TLA ("Sam Simpson")
Mix needs more of tasty pommies (Frog2)
Cracow2 loves to fuck these TLA (Anonymous)
Re: Riot uses to print remaining of radishes (Anonymous)
Cracker would love VB code (Anonymous)
Re: Fill-in-the-blank codes (similar to Error-correcting codes) (Jerry Avins)
NSA needs to write all these NSA (Anonymous)
LefArris requires some NSA (Anonymous)
NSA absolutely would love to eat these TLA (Anonymous)
[STATS] His in-law asks to infect nice carrots (Frog2)
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: RC4 test vectors after gigabyte output?.
Date: 25 Mar 2001 13:53:04 -0800
As Luis has pointed out, my test vectors don't
agree as stated with the normal RC4. This is
beacuse I forgot to tell you all one important
point.
In my code, I throw away 256 outputs from RC4
automatically as part of the keying process. This
is to avoid the correlation of the first output
byte(s) with key bytes, as observed first by
Kocher I think.
So, the test vectors below apply to bytes
256..299, and 1meg+256...
I apologise for this oversight, entirely my fault.
regards,
Greg.
In article 99c2pg$[EMAIL PROTECTED], Gregory G Rose [EMAIL PROTECTED] wrote:
In article u5C3OpCcF7b2VNiAEyPmh3csFGJy@wingate,
Luis Yanes [EMAIL PROTECTED] wrote:
There is any RC4 test vectors after gigabyte output?.
Well, not a gigabyte.
Initialise RC4 (or equivalent) with the 8 byte key
"test key". Then the first 44 output bytes are:
unsigned char expected[] = {
0xbd, 0xe9, 0x5c, 0xb5, 0x2b, 0x8d, 0xf8, 0xfb,
0xf2, 0xb7, 0x51, 0xf6, 0x5b, 0xe1, 0xdf, 0x3e,
0xd7, 0x4b, 0x45, 0x7a, 0xe9, 0x76, 0x4d, 0x26,
0x2f, 0x43, 0xa4, 0x70, 0x9a, 0x2a, 0xc9, 0x4e,
0x11, 0x23, 0x89, 0x7b, 0x02, 0x2a, 0x4f, 0x07,
0x80, 0x98, 0xa1, 0xa0,
};
With the same initialisation, throw away 1MB (that
is, 1048576 bytes) and the next 44 are:
unsigned char meg_expected[] = {
0x6b, 0x10, 0xd6, 0x79, 0xc8, 0x87, 0xa1, 0x26,
0xee, 0x2d, 0x7b, 0xd6, 0xbe, 0x04, 0xbe, 0x0c,
0x8f, 0x7a, 0xb3, 0xf0, 0xe0, 0xb8, 0xbd, 0xb5,
0x0f, 0x0c, 0x52, 0x33, 0xae, 0x62, 0xdd, 0x9e,
0x38, 0x4d, 0x03, 0xdd, 0xaf, 0x56, 0xcd, 0x07,
0xb1, 0x89, 0x0c, 0x13,
};
As someone else pointed out, this is indeed a
meaningful test. An even better test (but I don't
have a test vector for it) is to generate some
output, and use that output to rekey the cipher,
and iterate this process a large number of times
(say 100).
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
--
Date: Sun, 25 Mar 2001 14:53:32 -0700
From: Anonymous [EMAIL PROTECTED]
Subject: [STATS] Septic asks more of nice TLA
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Tr: Swiss fucking needs all some NSA
TLA sure asks more of those republicans
Bush loves to code tasteful CIA
6,562853E-02 0,9349315 0,2422448 -2001/03/25 16:57:30-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Clinton wants to fuck carrots
[WARNING] His cat needs most of those obnoxious mexicans
Re: TLA uses to eat radishes
--
From: "Tom St Denis" [EMAIL PROTECTED]
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: [STATS] Septic asks more of nice TLA
Date: Sun, 25 Mar 2001 21:54:22 GMT
"Anonymous" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Tr: Swiss fucking needs all some NSA
TLA sure asks more of those republicans
Bush loves to code tasteful CIA
6,562853E-02 0,9349315 0,2422448 -2001/03/25 16:57:30-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Clinton wants to fuck carrots
[WARNING] His cat needs most of
Cryptography-Digest Digest #997
Cryptography-Digest Digest #997, Volume #12 Tue, 24 Oct 00 23:13:01 EDT
Contents:
Re: idea for spam free email ("G. Orme")
Re: Why trust root CAs ? ("Tor Rustad")
Re: idea for spam free email (jungle)
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: IEEE P1363 Meeting Announcement (Mack)
Re: Efficient software LFSRs ("Trevor L. Jackson, III")
Re: Visual Basic ("Phillip Jones")
Re: Efficient software LFSRs ("Trevor L. Jackson, III")
Re: Efficient software LFSRs (Tom St Denis)
Re: Steganography books (wtshaw)
From: "G. Orme" [EMAIL PROTECTED]
Subject: Re: idea for spam free email
Date: Wed, 25 Oct 2000 01:09:57 GMT
"Ben Clifford" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
On Sat, 21 Oct 2000 10:39:01 GMT, G. Orme [EMAIL PROTECTED] wrote:
G. This is a good point because the system could be rendered worthless. I
would propose to stop this by every month people download a small update
to
their software. The server would be set to not accept emails from people
who
didn't have this update. Hackers would then have to crack the software
once
a month to keep sending advertising which is a lot of work for a small
return. In a variation of this the update is emailed to each person once
a
month to make it easier for them.
But equally, someone would have to put effort into rewriting the code
every month, in such a way that it cannot be automatically hacked at
the other end. For example, if you just change some string constant in
your program, it should be pretty easy to automatically find
that constant. So a hacker only needs to make a program once, which will
hack the code every month automatically.
G. The code could include a kind of checksum of the size of certain files
that is sent with emails, and if it is wrong the emails are not accepted. A
hacker couldn't know what the checksum was.
Maybe some form of varying obfuscation?
system is easily done. Say you want to send an email to someone who has a
protected email address as described. One would send the email as before,
but this would be diverted to an administrator who would send them a
message
that they must download the program to send the email. In a few minutes
they
can be logged on to the system and sending emails. One might have
additional
safeguards such as proof of ID, but if someone did spam then they would
be
automatically cut off on a complaint from a customer.
That is still too inconvenient.
G. It only has to be done the first time, and then once a month. It depends
whether it is more or less convenient than getting spam.
For example,
If you want me to give you help for my globe applet, you do it on my
terms, which means give me an e-mail address that I can correspond
to.
G. Once you join the network you correspond perfectly freely, no
restricitons except you agree not to send spam.
You don't have to do that, I don't have to communicate with you - it is
you who wants me to help you, and I am not going to help you if I have
to download code to decrypt your messages.
G. The messages aren't encrypted, just the email address. Of course someone
can have two email addresses, one for the people who won't use the system,
and a hmmm folder. Once the system is set up it would be exactly the same as
normal email, completely transparent. Think of the monthly upgrade as like
downloading small upgrades for e.g. flash which people do automatically
already.
So ultimately you lose out.
You either get no support for my globe applet, or you give me your
real address, in which case I sell it to my local spam factory for
1 eurodollarpoundmark.
--
http://www.hawaga.org.uk/ben/
GPG key 30F06950 on key servers my web page. You are encouraged to use
it!
Visit my page for benno.globe - rotating world map applet.
--
From: "Tor Rustad" [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Tue, 24 Oct 2000 12:58:15 +0200
"Anne Lynn Wheeler" [EMAIL PROTECTED] wrote in message
"Tor Rustad" [EMAIL PROTECTED] writes:
I'm reading your posts with interest, and will look into some of your
links
on this matter. I must admit that I have not paid attention to X9.59. In
SET, the ISO8583 mapping is implemented already, why do we need another
way
to do this? To open up for on-line debet card transactions?
As long as the card companies allow no security via credit cards, and
the
banks earn more mony (in some countries) on credit card transactions,
the
business case for implementing X9.59 doesn't look good. Also, _if_ X9.59
mandates new messages at the ASN.1 level, this will be expensive to
implement. Futhermore, some of us are starting to get really fed up with
all
these PKI standards...
there is existing fraud ...
Cryptography-Digest Digest #997
Cryptography-Digest Digest #997, Volume #11 Sat, 10 Jun 00 15:13:01 EDT
Contents:
Encryption implimentation in windows - downsides? (ie: temp files, virt memory, etc)
([EMAIL PROTECTED])
Re: Arithmetic Coding (Jack)
Re: Large S-Boxes (Terry Ritter)
Re: How does DES work? ("Paul Pires")
Keys larger than the plaintext (David Hopwood)
Re: Large S-Boxes ("Scott Fluhrer")
Re: Cryptanalytic gap [was: Re: Some dumb questions] ("Paul Pires")
Re: Large S-Boxes (Tim Tyler)
Re: Cryptographic voting (Greg)
Re: Comments on "Encase" forum about EE ([EMAIL PROTECTED])
Re: Double Encryption Illegal? (Greg)
Re: Cryptographic voting (zapzing)
Re: Cryptanalytic gap [was: Re: Some dumb questions] (John Savard)
Re: new public key? (Macckone)
Re: Large S-Boxes (zapzing)
Re: Large S-Boxes (zapzing)
From: [EMAIL PROTECTED]
Subject: Encryption implimentation in windows - downsides? (ie: temp files, virt
memory, etc)
Date: Sat, 10 Jun 2000 16:56:59 GMT
Hi,
I have been reading a lot about the things to watch for when
implementing an encryption system, and the following thoughts struck me:
* When I decrypt a file, read it, then encrypt it again, is it not the
case that some part (if not all) of the decrypted file will be left in
widows virtual memory or some kind of temp files?
* I want to have a database of encrypted documents, and want them
stored (and used) as securly as possible - should I (a) encrypt the
documents individually and have also an encrypted TOC file so I
minimise the danger of 'left overs' when encrypting / decrypting, or
should I encrypt the entire collection of documents in one block and
crypt/decrypt them when I start and then terminate my program
* Finally, is there any methology known (for windows based os) for
determining what has gone into virtual memory so I can wipe over those
blocks after re-encryption ?
thanks!
- Jay.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Jack)
Subject: Re: Arithmetic Coding
Date: 10 Jun 2000 17:19:36 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in [EMAIL PROTECTED]:
tomstd [EMAIL PROTECTED] wrote:
: In article [EMAIL PROTECTED], Tim Tyler [EMAIL PROTECTED] wrote:
:tomstd [EMAIL PROTECTED] wrote:
:: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
::[...] matt's site that has the best info on useful with
:: source code adaptive unadulterated arithmetic coding. [...]
:
:: To the best of my knowledge no arithmetic coder adds anything
:: that doesn't need to be there. So your logic is flawed my friend.
:
:What if the arithmetic stream does not terminate on a byte boundary?
:
: Think about it - an arithmetic coding stream is pretty good -
: but it is only rarely as perfect as you will find at:
:
: http://www3.sympatico.ca/mtimmerm/biacode/biacode.html
: While your site looks nice, it's pure crap. [...]
It's not my site. It belongs to Matt Timmermans
(http://www.timmermans.org/)
: Nowhere in any OS does it state that your file must contain at least
: or a boundary of 8 bits of *information*.
What is the purpose of this statement? Most modern OSs enforce an 8-bit
*data* alignment. Compression produces a stream of *data*. It's
information-content from the perspective of some observer is moot.
: Note: It is possible to write 7 bits of *information* to a file
: using ms-dos for example, you just end of wasting the last bit.
So - if I have this straight - you're advocating padding out the file
with an "impossible" token that takes the last arithmetic coding symbol
beyond the EOF?
This is likely to allow analysts to reject decrypts as being invalid
compressed files - and increases the average length of the file compared
to what's possible with Matt's end-treatment. There seem to be no
compensating advantages.
: All real arithmetic coders do is calculate the high/low and when
: they match in the upper decimal (bit) they shift the bit out.
: This isn't secret hidden information, it's part of the bloody
: number!!!
Your objection here appears to be addressing a point nobody ever raised.
The only "problem" with added information in arithmetic coding schemes
occurs at the end of the file.
Writting to little Tommy is a waste of time. I have tried and
his mind seems so full of crap that obvious facts seem to escape
him, Tim he is not capable of grasping the obvious facts of what
this kind of comprssion is all about. It is liking trying to teach
a pig. He can't learn and it only wastes your time and the pigs.
The only way he could even start to understand the concept would be
if a phony crypto god talked straight about the concept of compression
with encryption and getting and honest discussion out of them is
pretty much useless since it does not further there goals. Keeping
people like tom ignorant is much more inline with the
Cryptography-Digest Digest #997
Cryptography-Digest Digest #997, Volume #10 Fri, 28 Jan 00 22:13:01 EST
Contents:
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Michael Kagalenko)
How to password protect files on distribution CD ([EMAIL PROTECTED])
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: How to password protect files on distribution CD (Theo de Raadt)
Re: How much does it cost to share knowledge? (David A Molnar)
Re: How to password protect files on distribution CD (NFN NMI L.)
Re: Intel 810 chipset Random Number Generator ("james d. hunter")
Re: How to password protect files on distribution CD (GJJ)
Re: *** ECC Strong and Weak combined ("Harvey Rook")
Re: "Trusted" CA - Oxymoron? ("Brian Hetrick")
Re: Pencil paper cipher question (David Wagner)
Re: Pencil paper cipher question ("r.e.s.")
Re: designing secure backdoors into the system (Thierry Moreau)
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:02:29 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article 86qqvg$l1o$[EMAIL PROTECTED], [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
] Again nope. This cycle-by-cycle period variation produces clock drift,
] which grows with time. Precisely how it does so can be evaluated using
] fluctuation-dissipation theorem. If I feel like it, I might even do
] the computation one day.
]
]This flies in the face of my 20 years of experience as an Electronics
]Engineer, including working with high precision time references at
]Odetics and CD/DVD jitter measuring circuits at Disc Manufacturing, Inc.
You did not see what I describe because you weren't looking for it.
The good place to look would be metrology publications.
]What causes clock drift (two clocks with diverging ansers as to what
]time it is) is simply the difference between the actual and desired
]frequency.
That is one reason. The other reason is the presense of dissipation
in resonant system, or, in other words, wide resonance curve. Atomic
clocks are more precise because they make use of very narrow resonance
curves.
] Easy to correct for.
Then why GPS satellites bother with atomic clocks ? Just get
some thermostabilized and recalibrated quartz clocks.
] What causes the frequency to drift
]is the physical aging of the crystal.
That's much slower process than thermal drift.
] If it was caused by a brownian
]style drift caused by jitter (what you call "cycle-by-cycle period
]variation"), the frequency would reset when I turned off the
]electronics overnight.
You don't understand the point I am making. The frequency doesn't
get "reset" if you turn off the circuit. In fact, average
frequency does not change. I estimate I said that 5 times or so already.
] Brownian motion of particles has memory (the
]position of the particle).
Precisely wrong. Brownian motion has no "memory" of any kind.
] Crystal clock frequency has no memory;
]the frequncy is derived on the spot from various electrical and
]mechanical factors.
]
--
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:07:06 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article 86qreo$mr7$[EMAIL PROTECTED], [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
]Trevor Jackson, III ([EMAIL PROTECTED]) wrote
]
]]Further, you are assuming that clock drift is unpredictable.
]]This is simply invalid.
]
] No. You are wrong. Since quartz crystals have mechanical losses, they
] will have thermal noise, for the same mathematical reason that
] resistor has thermal noise.
]
]No one has disagreed with this.
No one showed any signs of having understood this.
] What the problem is is that this is
]a third or fourth order effect, completly swamped by predictable
]sources of variation.
We can discuss the magnitude of the thermal clock drift once there
is an agreement that the effect exists. So far, everyone opposing me
in this thread that it does not exist at all, not that it is small.
]] Given a small sample of measurements it is straightforward to
]]extrapolate the drift. That means it is predictable. That means it isn't
]]random. That means your argument fails.
]
] No, - it means that you a) did not read my post, where I said that
] syste
Cryptography-Digest Digest #997
Cryptography-Digest Digest #997, Volume #8 Fri, 29 Jan 99 11:13:03 EST
Contents:
Re: Random numbers from a sound card? (R. Knauer)
Re: hardRandNumbGen (Patrick Juola)
Re: what do u think about this algorithm of mine? (Patrick Juola)
Re: Random numbers from a sound card? (Patrick Juola)
Re: Random numbers generator and Pentium III (Mok-Kong Shen)
Re: Random numbers generator and Pentium III ([EMAIL PROTECTED])
Re: Random numbers generator and Pentium III (Mok-Kong Shen)
Re: Strong cryptography: the many ways we can trust a key
([EMAIL PROTECTED])
Re: hardRandNumbGen (Mok-Kong Shen)
Public Key encryption ("Phil Sumner")
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers from a sound card?
Date: Fri, 29 Jan 1999 13:37:25 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 29 Jan 1999 11:47:15 +0100, Mok-Kong Shen
[EMAIL PROTECTED] wrote:
The only way you can prove the crypto-grade randomness of a finite
number is to consider the method of generation. If the generator is a
TRNG, as we have defined it here several times recently, then the
numbers it generates are crypto-grade random numbers.
Ah! Finally one knows exactly what the term 'crypto-grade random
numbers' you employ means: These are DEFINED to be the output
from a hardware generator. If follows obviously then that there
is NO need whatsoever of testing the sequences obtained, since they
are BY DEFINITION 'crypto-grade'!
Are you being deliberatly obtuse - or does it come naturally?
Nothing that you said above follows from what I said. A TRNG is not a
True Random Number Generator just because it is a hardware device.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
--
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 29 Jan 1999 09:12:24 -0500
In article [EMAIL PROTECTED],
Kurt Wismer [EMAIL PROTECTED] wrote:
R. Knauer ([EMAIL PROTECTED]) wrote:
: Learn what crypto-grade randomness is. The concept is deceptively
: simple once you understand it. But first you have to give up all other
: definitions of randomness from other fields like statistics.
: The key to understanding is that randomness depends on the generation
: process, not the numbers themselves. The number 000...0 fails all
: sorts of statistical tests, but can be a random number if it is
: generated by a TRNG. Until you analyze the method of generation, you
: cannot know.
this is the definition i've used for years... strangely, nothing i ever
learned in statistics ever suggested i was wrong...
Possibly because it isn't. 8-)
On the other hand, it also looks suspiciously like the result of
an incompetent engineer *trying* to build a RNG.
Which is it? Your call. You know the engineers that you hired
-kitten
--
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: what do u think about this algorithm of mine?
Date: 29 Jan 1999 09:10:04 -0500
In article [EMAIL PROTECTED],
Klaus Rohde [EMAIL PROTECTED] wrote:
i don't know anything about encryption, but one day i was thinking about
it and had an idea for an algorithm which, as far as i can see, is
unbreakable.
you take byte n of a text stream and XOR it with byte n of the key to
produce byte n of the cipher text.
to me this seem's unbreakable, because by applying the right key any
cipher text can be decoded into literally anything of the same length,
meaning that unless someone has the key, they can't gain anything out of
the cipher text.
any thoughts or ideas (or proof that what im saying is nonsense) would be cool.
Nice idea except for the fact that the text stream, which you are
treating as a key stream, is almost certainly way too predictable.
If you used a good source of random numbers, you have just reinvented
the OTP, which *is* provably unbreakable.
However, as is, if you can manage to figure out one likely word or
phrase to appear in the plaintext (in the context of a sci.crypt
posting, for instance, I'd guess "cipher", "cypher", "security",
"breakable", and "algorithm", then if you just XOR that word with
every possible location in the cyphertext, eventually you'll see a
readable part of the key appear. You can use this to guess the
next (or previous) few key words, use those to unbutton the
plaintext, c.
-kitten
--
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Random numbers from a sound card?
Date: 29 Jan 1999 09:14:11 -0500
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
R. Knauer wrote:
You cannot prove the crypto-grade randomness of a finite number
algorithmically. You ca
