Cryptography-Digest Digest #862
Cryptography-Digest Digest #862, Volume #12 Sat, 7 Oct 00 06:13:01 EDT
Contents:
Re: what is wrapped PCBC? (Mack)
Rijndael ([EMAIL PROTECTED])
Re: Getting best available security without knowing which cipher to use (David
Schwartz)
Re: NSA quote on AES (Eric Smith)
Re: Why wasn't MARS chosen as AES? (Eric Smith)
Error-correcting code ? ([EMAIL PROTECTED])
Re: Error-correcting code ? ("John A. Malley")
Re: NSA quote on AES ("Brian Gladman")
Re: NSA quote on AES ("Brian Gladman")
Re: NSA quote on AES ("Brian Gladman")
Re: NSA quote on AES (David Schwartz)
Re: Looking Closely at Rijndael, the new AES ("Brian Gladman")
Re: Q: does this sound secure? (Simon Johnson)
Re: NSA quote on AES (Justin)
Re: one time pad using a pseudo-random number generator (Mok-Kong Shen)
From: [EMAIL PROTECTED] (Mack)
Date: 07 Oct 2000 03:51:33 GMT
Subject: Re: what is wrapped PCBC?
[EMAIL PROTECTED] (Mack) wrote in
[EMAIL PROTECTED]:
[EMAIL PROTECTED] (Mack) wrote in
20001006000832.15659.0334@ng- fd1.aol.com:
[snip]
wrapped PCBC is basically a form of chaining similar to CBC and PCBC.
It uses multiple passes over the text wrapping the last block to the
front
It is a form of AONT. If the encryption function is unbreakable
wrapped PCBC is unbreakable.
example
P1 P2 P3 P4
E1=f(P4^P1^P2)
E2=f(E1^P2^P3)
E3=f(E2^P3^P4)
E4=f(E3^P4^E1))
However in scott19u E1 does not overlay P1 there is a 9 bit shit
so that the file rotates 9 bits each pass.
Interesting but it complicates the nice description. I can see the use
but it slows it down.
Well scott16u is not slowed that much. Since I use
an 8 bit shift. But scott19u. is dam slow with the 9 bit shift.
I only ran it a few times on my 486. But scott19u flys on a k6-III
that I know have.
I rather like AMD myself.
now here is where it gets interesting
second round produces what we will call G
G1=f(E4^E1^E2)
G2=f(G1^E2^E3)
G3=f(G2^E3^E4)
G4=f(G3^E4^G1)
notice that this is invertible
In scott19u and relatives the second xor is changed to a +.
It must be decrypted last block first to unwind it.
In particular scott19u uses large tables for f and round keys.
This prevents 'the Onions attack' by Paul Onions which is
a form of Slide attack. It is interesting that it isn't mentioned
in David Wagner's paper on Slide attacks. I believe David may have
been around a bit when that attack was introduced.
Well at the time David Wanger brought up his slide attack
he made a grand statement that it was the death of my cipher
until someone tried it and mentioned some of the problems it
caused for the slide attack. Wagner in only one small post
admitted that the slide attack may well not work against it
but that he did not really understand what my code did.
I guess having the complete source code that compiles was just
to hard for him to follow.
Actually I suspect he never looked at it at all and was just
spouting BS out his mouth. Most people who attend Berkeley are
quite arrogant. I konw I have met many of them and one of my siblings
went there for 3 years. But then again there are a few rare
good ones from there.
Yes but you think he would have given Paul some credit.
Well I think the so called crypto gods only go around
patting each other on the back. A ture independent thinker
like Paul Onions is an embarassment to them. Its obvious
he seems much sharper than Mr Wagner who has trouble reading
code. I wonder how you followed my code when the so called
experts could not. I don't see Mr Onions writting very ofen
but I like his thoughts on various things.
I do coding work professionally. Your code isn't the clearest
but it isn't the most opaque either. It tends to be efficient
which generally leaves out clarity. I generally write two versions
for code which will be publically available. One that is clear
and one that is efficient. That is if I can't do both at the same
time.
I posted a paper about it a long time back in sci.crypt.research
I introduced IS8, RS8 and M8 of those only M8 had round keys
and is still unbroken. It is in the north american crypto archive
as X8.ZIP
I remeber but for some reasom I thought your name was Maack
but then again I can't spell worth shit.
No the account I was using then was [EMAIL PROTECTED]
I do remember you. It just names are hard. I know it was
a different spelling of Mack but considering my dsylxeia
I think I got pretty dam close.
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
Cryptography-Digest Digest #863
Cryptography-Digest Digest #863, Volume #12 Sat, 7 Oct 00 09:13:00 EDT
Contents:
Re: NSA quote on AES ("Brian Gladman")
Re: Q: does this sound secure? (Paul Rubin)
Block Cipher Question ("musashi_x")
Re: i should have finished high school (ca314159)
Re: Block Cipher Question (David Crick)
Re: Advanced Encryption Standard - winner is Rijndael ("Rick Braddam")
Re: NSA quote on AES (Tim Tyler)
Re: TC8 -- Yet Another Block Cipher (Tom St Denis)
Re: Idea for Twofish and Serpent Teams (Tom St Denis)
Re: one time pad using a pseudo-random number generator (Simon Johnson)
Re: NSA quote on AES ("Brian Gladman")
Re: one time pad using a pseudo-random number generator (Herman Rubin)
Re: Error-correcting code ? (John Bailey)
From: "Brian Gladman" [EMAIL PROTECTED]
Subject: Re: NSA quote on AES
Date: Sat, 7 Oct 2000 11:17:39 +0100
"David Schwartz" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Brian Gladman wrote:
I am absolutely certain that NSA attempts to manipulate the perceptions
of
outsiders by issuing statements designed to be misinterpreted. This
does
mean that considerable care is needed in reading them. I hence don't
blame
people for being sceptical about their content but they won't always be
right in taking this line.
When a statement appears to be carefully crafted, I assume it means
exactly and only what it says. I disregard all implications. I think
this is the correct way to read NSA statements.
In principle I agree with this approach and I believe that it leads to a
sensible conclusion in this case. Unfortunately, however, very few
statements of any length in english are devoid of the need for
interpretation of some kind so the approach does not always produce the
right answer (if there ever is such a thing).
Brian Gladman
--
From: Paul Rubin [EMAIL PROTECTED]
Subject: Re: Q: does this sound secure?
Date: 07 Oct 2000 03:27:55 -0700
"William A. McKee" [EMAIL PROTECTED] writes:
I have to ask the user for an user id and password in a Java applet (client)
then validate it on a server. Does this sound like a secure scheme?
No.
1) the server issues a random session key (32 bits).
2) the user id and password are hashed (MD5) by the client.
3) the session key and hash key from 2 are hashed (MD5).
Wait a sec, how did the hash key from 2 and the session key come into
contact so they could be hashed together? Do you mean the server sent
the session key unencrypted to the client? That means it's not really
a key, but more like a salt. It's known to the attacker.
4) the user id and hash key from 3 are sent to the server.
Oops. Now the attacker, knowing the session ID, and the hash from step 3,
can recover the password by brute force search.
5) the server looks up the user id in a password file then hashs the session
key and the stored hash key (previously computed, the same as in 2).
6) the two hash keys (from 3 and 5) are compared.
7) the server issues a "PASS" if 6 compares true (and moves into a "logged
on state") else it issues a "FAIL"
Passwords are at least 6 characters long with at least one non-alpha
character.
This is nowhere near enough.
Is there any advantage to using SHA instead of MD5?
No. The scheme is insecure either way.
I also have a registration dialog box in the client that asks for a
new user id and password. The data is hashed as in 2 and the user
id and hash key are sent directly to the server to be added to the
password file. Does this compromise security?
Yes, now the new password is compromised just like the old one.
Look, do yourself a favor, stop trying to design protocols. The
simplest way to do what you're describing is encrypt the whole channel
with SSL if you can. Then you can just send the unhashed password
over the encrypted channel and hash it on the server side if you're
storing hashed passwords in the database. If you're writing a web
application, this also lets you avoid needing an applet, and avoiding
applets is always a good thing.
If you can't use SSL and you're serious about protecting the
passwords, you have to use something like SRP
(http://srp.stanford.edu) or one of its many equally complicated
competitors. But I don't recommend that because it's a big hassle,
plus AFAIK all these schemes require secure random numbers on the
client side, which are not necessarily easy to come by.
--
From: "musashi_x" m u s a s h i _ [EMAIL PROTECTED]
Subject: Block Cipher Question
Date: Fri, 6 Oct 2000 23:00:48 -0400
Something got me thinking recently...(I am, of course, a crypto-newbie). I
have a question about CBC output. If you were to encrypt something with,
say, Blowfish in cipher block chaining mode and then remove the first 7
characters of the output, wouldn't that make cryptoanalysis a great deal
harder? From what I
Cryptography-Digest Digest #864
Cryptography-Digest Digest #864, Volume #12 Sat, 7 Oct 00 14:13:00 EDT
Contents:
Re: Why trust root CAs ? (Daniel James)
Re: i should have finished high school ("Paul Lutus")
Re: It's Rijndael ([EMAIL PROTECTED])
Re: NSA quote on AES (Mok-Kong Shen)
Re: NSA quote on AES (Mok-Kong Shen)
Re: NSA quote on AES (Jim Gillogly)
Re: Why trust root CAs ? (zapzing)
Re: How to use PGP2.6.2?? (Rich Wales)
Re: NSA quote on AES ("Brian Gladman")
Re: is NIST just nuts? ([EMAIL PROTECTED])
Re: Choice of public exponent in RSA signatures (David A Molnar)
Re: Choice of public exponent in RSA signatures (David A Molnar)
From: Daniel James [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Sat, 07 Oct 2000 15:13:57 +0100
Reply-To: [EMAIL PROTECTED]
In article [EMAIL PROTECTED], Bruce Stephens wrote:
Bruce Schneier's new book, "Secrets and Lies", has an interesting section
on certificates and such where, if I understand him correctly, he concludes
that the real security in B2C web transactions comes from the credit card
company and it's limits on personal liability and not the CA.
If had the book I'd give the page,
pp.238-239.
"Digital certificates provide no actual security for electronic
commerce; it's a complete sham."
Yes, Bruce likes saying that - he comes across as very sceptical of any benefits
claimed for PKIs and certificates.
As things stand today he's right - certificates are used as a guarantee of a
party's identity, and not a very good guarantee at that. It doesn't have to be
this way.
Imagine, if your bank gave you a smartcard as a credit card, and that card
contained a private key you could use to sign messages, a certificate for that
key signed by the bank, and the bank's CA certificate. The bank could then say
that they wouldn't accept any payment made by you unless it was signed with your
key, and that any correctly signed payment *must* have come from you so your
card account would be debited even if you denied making the payment. The only
way that could be done is if someone obtained your card and your PIN (or broke
the digital signature algorithm used by the card). This would provide good
security for the bank, because they would be able to say with a high degree of
justification that any correctly signed payment must have come from you or from
someone else acting on your behalf (with your card AND your PIN) - but it
doesn't provide any protection for the customers that they're not getting at the
moment from the banks' and credit card companies' policy of refunding payments
that are made fraudulently.
The point here is that the banks aren't under any obligation to provide that
protection. They do so because they make money on every transaction, and so it's
financially to their advantage to keep the transaction count high, and so they
encourage their customers to use their cards online by offering to indemnify
them against fraud (and by insuring against part of the cost of doing so). It
wouldn't take much of an increase in the level of fraud, or of the cost of
insuring against it, to change this.
A bank could also offer a service whereby it would issue identity certificates
to online traders signed with its own CA key (whose certificate is on your smart
credit card). You still don't know with absolute certainty what the identity of
that trader is, but you do know with a high degree of certainty who your bank
thinks that trader is. This - from the point of view of someone trying to make
an online purchse from that trader using funds from that bank is all that really
matters.
Digital certificates and PKIs provide a means whereby trust, once established,
can be shared and can be communicated between parties who trust on another. None
of this plays much part in eCommerce security today because the banks see it as
in their interest to indemnify their customers against loss, so their customers
don't actually have to care too much about trust. This state of affairs should
not be expected to last.
Cheers,
Daniel.
--
From: "Paul Lutus" [EMAIL PROTECTED]
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: i should have finished high school
Date: Sat, 7 Oct 2000 07:42:56 -0700
ca314159 [EMAIL PROTECTED] wrote in message
news:8rn255$1bj$[EMAIL PROTECTED]...
It might be interesting though to consider how
this effect may be used for FTL computation.
To earn its name, FTL computation would rely on FTL communication. Let's see
if there is any --
For instance, if a hologram is made of a slide rule
with a displacement between the slides, then
the apparent FTL motion due to the lighthouse effect,
The lighthouse effect is not an FTL effect. Not apparent, not real. Imagine
the water coming out of a swinging hose. None of the water travels at
greater than the basic stream
Cryptography-Digest Digest #865
Cryptography-Digest Digest #865, Volume #12 Sat, 7 Oct 00 16:13:01 EDT
Contents:
Re: How to use PGP2.6.2?? (Imad R. Faiad)
Re: Choice of public exponent in RSA signatures (David A Molnar)
Could NSA help vigilance? (Andru Luvisi)
Re: How to use PGP2.6.2?? (Imad R. Faiad)
securely returning password info to a server from a client ("William A. McKee")
Re: Why wasn't MARS chosen as AES? (Stephan Eisvogel)
Re: Block Cipher Question ("musashi_x")
Re: NSA quote on AES (Bill Unruh)
The talk of R. Moris (Mykhailo Lyubich)
Re: How to use PGP2.6.2?? ([EMAIL PROTECTED])
Re: Why wasn't MARS chosen as AES? (Tom St Denis)
Re: NSA quote on AES (Mack)
Re: Why wasn't MARS chosen as AES? (Tom St Denis)
Re: NSA quote on AES (David Schwartz)
From: Imad R. Faiad [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: How to use PGP2.6.2??
Date: Sat, 07 Oct 2000 18:27:16 GMT
=BEGIN PGP SIGNED MESSAGE=
Greetings,
On 7 Oct 2000 17:32:35 -, in alt.security.pgp [EMAIL PROTECTED] (Rich
Wales) wrote:
Imad R. Faiad wrote (in alt.security.pgp):
I would not recommend generating an RSA key with any PGP
2.6.x . . . because most if not all PGP 2.6.x are compiled
with the Blum flag set. What this does is let the program
look for primes congruent to 3 modulo 4. This shaves about
2 bits from the domain of the key.
I can indeed confirm that the 2.6.3ia source code does use Blum primes.
I'm not sure I see this as a big issue with a 2K-bit RSA key, however.
And if 4K-bit RSA keys manage to come into wider use, I don't see it as
an issue at all.
I agree with you, shaving 2 bits from the key does not make that much
of a diference for RSA keys 2048 bits and above.
However, since we are discussing in relative terms, one many say that two
random primes chosen so as to yield a modulus which is a Blum integer
in the context of RSA key generation are inferior to two random primes
period.
As for whether or not it makes any sense to use Blum primes for RSA (as
opposed to random primes), I'm crossposting to sci.crypt as well as to
alt.security.pgp.
Also, the quality of the primes generated in later versions
of PGP is much better in my view.
Could you provide us some more details regarding why you believe this?
The RNG in later versions of PGP is much much improved.
- From the collection of entropy to the actual random bits generation.
Look at the source code. Hence, one may argue that two random primes
chosen by the PGPSDK RNG are more random than those generated in PGP 2.6.x.
FWIW, the 2.6.3ia source code explicitly doesn't try to select "strong"
primes. A comment in the code claims that there is no valid reason to
worry about using strong primes. Is this advice outdated?
No, it is still current. As it is rightly says in the source code:
**QUOTE**
*"Strong" primes are no longer advantageous, due to the new
* elliptical curve method of factoring.
**ENDQUOTE**
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
Best Regards
Imad R. Faiad
=BEGIN PGP SIGNATURE=
Version: 6.5.8ckt http://irfaiad.virtualave.net/
Comment: KeyID: 0xBCC31718833F1BAD
Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45
iQEVAwUBOd9qJrzDFxiDPxutAQEMiwf+JA/J03Efx1Ryf55YHZE2UYSZ3342H2Lu
+f4I3Wladlh53gpODCEJyYtk0XaX+exZ35l8Tus4KvuyjM2565S1pxun0tb/nZUd
xSJw1Bancti7RiCTLVP7k6m+SBWru5DXg3eWJ4Z3NKHrRqcSkg9q4tl5CogBJW4j
+ftRcvzfpoH0/DB3oWsYWWPTvBGSOqtYrKThx2BgeUVOgV1E3MAKLUNXVEAqp1HI
1FgD+Etr7NbcHzPHL1R5AtmAYDcgslhxmC8L1k1WnE5ZZRUPKKbfXCAlMLT0NLC/
AfjNK68Y/HPUpCHn2d0QdCVkeCn4ww7ABRPyROTzmIRtmb07o5wK7Q==
=tQcR
=END PGP SIGNATURE=
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: Choice of public exponent in RSA signatures
Date: 7 Oct 2000 18:01:58 GMT
Francois Grieu [EMAIL PROTECTED] wrote:
PSS has better security bounds than Full Domain Hashing, for example,
so to get the same security you would need to compensate by increasing
the modulus size and slowing down the algorithm.
I whish the difference could be quantified ! I'd buy a 40% extra
verify time (20% extra modulus size) for a deterministic signature.
It can be. What you do is you look at the security guarantee for FDH and
the one for PSS and calculate. If memory serves, in order to get the
same security level as 1024-bit modulus for PSS, you need something
like a 3000 bit modulus for FDH.
There was a recent paper "On the Exact Security of FDH" in this year's
CRYPTO. I haven't read it. It may modify the calculations somewhat.
-David
--
From: Andru Luvisi [EMAIL PROTECTED]
Subject: Could NSA help vigilance?
Date: 07 Oct 2000 11:23:26 -0700
Just a random thought...
What if
Cryptography-Digest Digest #867
Cryptography-Digest Digest #867, Volume #12 Sat, 7 Oct 00 21:13:01 EDT
Contents:
Re: Signature size ("Joseph Ashwood")
Re: It's Rijndael (Sam I am)
Re: Choice of public exponent in RSA signatures (DJohn37050)
Re: Block Cipher Question (Tim Tyler)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Rich Wales)
Re: Deadline for AES... (Mok-Kong Shen)
Re: Advanced Encryption Standard - winner is Rijndael (Anonymous)
Re: Advanced Encryption Standard - winner is Rijndael (David Schwartz)
Re: Advanced Encryption Standard - winner is Rijndael (David Schwartz)
From: "Joseph Ashwood" [EMAIL PROTECTED]
Subject: Re: Signature size
Date: Fri, 6 Oct 2000 17:04:57 -0500
... in which all but 32 bits are chosen by the
attacker.
Exactly, but since the instruction is known to be
32-bits,
the instruction itself is fixed.
I don't see what you're getting at here. Either the
message is = 32 bits
and there is no need to use a CRC, or it is greater than
32 bits, and
the attack I posted applies. In either case, using a CRC
in the way you
described is a bad idea.
I was encouraging the use of the CRC as a check for whether
or not the package had been tampered with basically by
expanding the instruction to 64-bits in some deterministic
way. Because the CRC would be encrypted in the same block as
the instruction it can be considered to be a tamper evident
system, or more accurately as a sparse mapping of 32-bit
instructions to a 64-bit space, with internal methods of
detecting probable tampering (as opposed to padding with
random numbers), the goal was to certify the instruction,
and with a shared secret CRC polynomial it can be determined
(as long as not a single block is compromised). There are
other methods, and some better methods, but given what I
took to be the original posters level of knowledge, I didn't
think tamper-resilient codes were necessarily within the
available options.
Joe
--
From: Sam I am [EMAIL PROTECTED]
Subject: Re: It's Rijndael
Date: Sat, 07 Oct 2000 15:09:19 -0700
On Sat, 07 Oct 2000 15:55:40 GMT, [EMAIL PROTECTED] wrote:
Two bits of wisdom:
1. snip
2. If naked AES is used, why not always use 256 bit keys? I don't
really buy the efficiency argument. Show me exactly where the slightly
greater work factor for handling larger keys is really significant?
Possibly there are some cases, so let them worry about what to do or
how to inter-operate with the rest of the world that sticks to 256
bits. As a relative outsider, I always find it strange how
cryptologists worry about bits as if they were worth their weight in
gold. Maybe this is a meme remnant of a time decades ago where crypto
was always done in hardware and where CPUs were rare and expensive
thing.
The answer to your question is that in some systems AES at 128-bits will
be a burden on available compute power, and requiring more rounds would
just increase this burden. For example, in the real-time industrial
control environment, most of the process-connected equipment is required
to operate and communicate on less than 40 mW -- perhaps 1/1000 the power
used by a typical notebook computer. This is not an arbitrary power
limit; it is established by the ignition properties of H2 and similar
explosive substances, and by the need for multiple pieces of equipment to
share the same buried kilometer-long twisted pair (which carries both
power and signal ling).
Historically this market has used near-d.c. 4-20 mA point-to-point analog
signaling. Today it is transitioning to digital multi-drop bus
structures. Unfortunately, the higher signaling frequencies of digital
systems makes "outside-the-fence" eavesdropping possible. The
commoditization of such networks also facilitates surreptitious taps and
therefore wholesale eavesdropping and command spoofing. Thus there is a
need for confidentiality of economically valuable data, as well as for
authentication of potentially dangerous commands.
Rijndael and Twofish were the two round-2 candidates that best met the
needs of this market. We are very happy with the NIST choice, and have
told them so.
Tom Phinney
US Technical Advisor for IEC/SC 65C (industrial communications standards)
Convenor, IEC/SC 65C/WG 1 and /MT 9 (fieldbus standards)
--
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Choice of public exponent in RSA signatures
Date: 07 Oct 2000 22:54:09 GMT
PSS is in P!363a which is a draft. not in P1363, which is a standard.
Don Johnson
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Block Cipher Question
Reply-To: [EMAIL PROTECTED]
Date: Sat, 7 Oct 2000 22:31:13 GMT
musashi_x m u s a s h i _ [EMAIL PROTECTED] wrote:
: Something got me thinking recently...(I am, of course, a crypto-newbie). I
: have a question about CBC output. If you
Cryptography-Digest Digest #868
Cryptography-Digest Digest #868, Volume #12 Sat, 7 Oct 00 22:13:01 EDT
Contents:
Re: i should have finished high school (Scott Craver)
Re: Serial number scheme using DSA variant ("Lyalc")
Re: NSA quote on AES (John Savard)
Re: Rijndael (John Savard)
Re: Why wasn't MARS chosen as AES? (John Savard)
Re: NSA quote on AES (John Savard)
Re: It's Rijndael (John Savard)
Re: Pencil and paper cipher. (John Savard)
Re: Could NSA help vigilance? (John Savard)
Re: Looking Closely at Rijndael, the new AES (John Savard)
Re: NSA quote on AES (John Savard)
Re: It's Rijndael (John Savard)
Re: My Theory... (John Savard)
Re: NSA quote on AES (John Savard)
Re: Rijndael Coverage Improved on Web Site (John Savard)
Re: Why trust root CAs ? ("Lyalc")
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: i should have finished high school
Date: 8 Oct 2000 01:12:28 GMT
Paul Lutus [EMAIL PROTECTED] wrote:
The lighthouse effect is not an FTL effect. Not apparent, not real. Imagine
the water coming out of a swinging hose. None of the water travels at
greater than the basic stream velocity. It's the same with light.
Right. This guy is basically suggesting that random-access
of data happens at "faster than light" speeds if serial access
of that same data requires faster-than-light travel.
For instance, a terabyte stored on one roll of paper tape
(quick, somebody start planting trees) would probably require
FTL travel to shuttle to a random byte in less than 1 second.
-S
--
Paul Lutus
www.arachnoid.com
--
From: "Lyalc" [EMAIL PROTECTED]
Subject: Re: Serial number scheme using DSA variant
Date: Sun, 8 Oct 2000 12:28:56 +1000
Why don't you use the simple process used in ATMs and EFTPOS globally today?
In essence, encrypt the data with a DES key in CBC, and keep only 32 bits
from the last 8 bytes of result. Including the serial number on the
encrypted data will help ensure uniqueness of the result to the serial
number and the data.
Change the key every message if you want, but for the criteria you've
outlined, a single key may be sufficient.
With RSA, DSA or DES (or anything else using crypto), there are identical
key storage security issues.
Lyal
[EMAIL PROTECTED] wrote in message 8ro2fb$o4b$[EMAIL PROTECTED]...
Hi!
First of all thanks for your help regarding short signatures.
After a while I came up with a scheme which could be the solution for
my problem.
I will sum up the requirements first so you can see for yourself if the
scheme meets those criteria.
This scheme will be used for secure serial numbers secure meaning that
no one else is able to forge serial numbers i.e. serial numbers can
only be given out by someone knowing the private key.
Requirements:
- serial numbers must be short (40 base32 characters at the most)
- serial numbers can be verified in reasonable time in the software
- no one should be able to generate serial numbers but me
(Security equal to cracking DES is secure enough)
- Only 16384 unique serial number required
Scheme:
I want to employ a DSA variant using only 128 bits for q instead of
160. The part of the signature for all possible messages (16384) which
is not dependant on the message is deployed with the software (the r
part in DSA). Therefore the application needs to store 16384*128 bits =
256 kbytes. The serial number will be delivered as
unique serial number|signature (s part)
thus taking up exactly 142 bits = 29 base-32 characters.
On runtime this serial number
Do you think this is secure? Any objections to this design?
As I understand it I do not need to hash the unique serial number
(otherwise I could use MD5 for example). Is this correct?
Thanks for your help...
kryps
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 17:16:33 GMT
On Sat, 7 Oct 2000 11:17:39 +0100, "Brian Gladman"
[EMAIL PROTECTED] wrote, in part:
"David Schwartz" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
When a statement appears to be carefully crafted, I assume it means
exactly and only what it says. I disregard all implications. I think
this is the correct way to read NSA statements.
In principle I agree with this approach and I believe that it leads to a
sensible conclusion in this case. Unfortunately, however, very few
statements of any length in english are devoid of the need for
interpretation of some kind so the approach does not always produce the
right answer (if there ever is such a thing).
Since it is seldom the practice of people to craft their statements
carefully, when someone does do so, it is naturally
Cryptography-Digest Digest #869
Cryptography-Digest Digest #869, Volume #12 Sun, 8 Oct 00 00:13:01 EDT Contents: Re: Error-correcting code ? (Peter Pearson) Re: NSA quote on AES (Mack) Re: Advanced Encryption Standard - winner is Rijndael (Mack) Re: securely returning password info to a server from a client (Thomas Wu) Re: Advanced Encryption Standard - winner is Rijndael (John Savard) Re: Deadline for AES... (Mack) Re: Q: does this sound secure? (Thomas Wu) Re: Q: does this sound secure? (Thomas Wu) Re: TC8 -- Yet Another Block Cipher (Mack) Re: No Comment from Bruce Schneier? (Joaquim Southby) Re: Q: does this sound secure? (Paul Rubin) From: Peter Pearson [EMAIL PROTECTED] Subject: Re: Error-correcting code ? Date: Sat, 07 Oct 2000 19:18:14 -0700 [EMAIL PROTECTED] wrote: Does anyone know an algorithm, simple or well-documented (like, source code) enough that an idiot like me can implement it, for error-correcting short strings of digits ? So that if someone writes down "123454321" and someone reads it back as "123454327" or "lZ34S43Zl" that I can recover the original number. I'm sure there are more sophisticated approaches (c'mon, guys, help me out), but a simple technique is to add two check digits and to insist that all legal strings be multiples of, say, 97. When a string shows up that is not a multiple of 97, look for the most likely modification that would fix it. "Most likely" depends on what sort of corruptions you're anticipating. Hoping this helps - Peter -- From: [EMAIL PROTECTED] (Mack) Subject: Re: NSA quote on AES Date: 08 Oct 2000 02:48:40 GMT On 06 Oct 2000 20:30:12 -0700, Eric Smith [EMAIL PROTECTED] wrote, in part: [EMAIL PROTECTED] (Mack) writes: After the Skipjack fiasco the NSA is being much more careful. What Skipjack fiasco is that? Perhaps he means the Clipper Chip controversy. (No, AFAIK, SKIPJACK hasn't been cracked.) John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm The whole thing was a bit of a fiasco. The algorithm was finally made public. There was a weakness but it wasn't in Skipjack itself. But Skipjack does have a structure that lends itself to impossible differential analysis. So far as I know the 80 bit key was the major weakness. 56 bit keys are obviously crackable. 80 bits is 16 million times harder but that certainly isn't going to prevent attack 20 years from now. Anyone with enough money could probably build a skipjack cracker that will provide keys for a specific known plaintext/ciphertext pair. Mack Remove njunk123 from name to reply by e-mail -- From: [EMAIL PROTECTED] (Mack) Subject: Re: Advanced Encryption Standard - winner is Rijndael Date: 08 Oct 2000 02:57:15 GMT Anonymous wrote: Is there truly ANYONE stupid enough to believe ANY government would adopt an encryption standard that DIDN'T have a back door for unlimited government access?!?!?! This is just the software version of the "clipper" chip- only this time, the government didn't repeat their earlier mistake of admitting they have the capability to easily decrypt the data. But in all fairness, the US government has established itself as a decade-long enemy of encryption that they can't easily decrypt. It's a safe bet the government chose the Rijndael encryption method because they can already decrypt it. So what good would this do them? They couldn't, for example, admit decrypted data into evidence because that would make it obvious that they could break the cipher. They couldn't even use the information indirectly to aid prosecution, because that would mean an ever-widening circle of law-enforcement personnel who knew that the cipher was broken. About all they could use it for are issues of the highest national security, where the decrypts and information relating to them, were held in to the smallest number of people possible. I give very little weight to poorly reasoned arguments advanced anonymously. DS The NSA never admitted to owning a DES cracker. However it is very likely that one was built in the 80's. It was technically feasible and not outrageously expensive. By government standards anyway. I doubt they had one when the standard was approved. They could have though. It does show that they 'might' do something like that. Mack Remove njunk123 from name to reply by e-mail -- From: Thomas Wu [EMAIL PROTECTED] Subject: Re: securely returning password info to a server from a client Date: 07 Oct 2000 20:02:50 -0700 "William A. McKee" [EMAIL PROTECTED] writes: Thanks for the replies. (I'm a real newbie at this crypto stuff.) My applications is a Java (applet) based Asian language text editor with server side resources for file i/o and language translation. I'm trying to keep the applet small and off-load
