By the way, the general idea of One Hundred Year Security as far as
digital signatures go would be to combine digital signature
algorithms. Take one algorithm which is bog standard, such as ECDSA
over NIST secp256r1 and another which has strong security properties
and which is very different from
On Thu, 22 Apr 2010, Zooko O'Whielacronx wrote:
There is some interesting work in public key cryptosystems that reduce
to a *random* instance of a specific problem.
Here is a very cool one:
http://eprint.iacr.org/2009/576
...
Unless I misunderstand, if you read someone's plaintext without
http://jqi.umd.edu/news/215-random-numbers-but-not-by-chance.html
Random Numbers -- But Not By Chance
April 2010
Researchers have devised a new kind of random number
generator, for encrypted communications and other uses,
that is cryptographically secure, inherently private
I'm looking for a best practices guide (for a system architecture) or
case studies for how best to handle storing and using 3rd party
passwords.
Specifically, I'm interested in the case where a program or service
needs to store a password in such a way that it can be used (presented
to another
GPS tracking units that you can fit to your car to track where your kids are
taking it (or *cough* other purposes) have been around for awhile now. It's
interesting to see that recently the sorts of places that'll sell you card
skimmers and RFID cloners have started selling miniature GPS jammers
I hope the crosslinking is OK:
http://lists.lists.reflextor.com/pipermail/a51/2010-May/000605.html
Time memory tradeoffs attacks against A5/1, the most commonly used
encryption in GSM, have been known for over a decade. But older
proposals were limited to period hardware. The tables would be a
Aloha!
uIP [1] is a very compact TCP/IP stack for small, networked connected,
embedded devices. (The code size for uIP including TCP and ICMP on the
AVR processor is about 5 kBytes.)
Unfortunately, the TCP sequence number generator in uIP is a bit
simplistic - basically a monotonically
http://www.technologyreview.com/blog/arxiv/25189/
Not at all to my surprise, they broke it by exploiting a difference between a
theoretical system and a real-world implementation.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
http://arxiv.org/abs/1005.2376
Unconditional security proofs of various quantum key
distribution (QKD) protocols are built on idealized
assumptions. One key assumption is: the sender (Alice) can
prepare the required quantum states without errors. However,
such an assumption may be
Dear all,
A colleague dropped in yesterday and confronted me with the following.
He wanted to scrape off some additional bits when using AES-CBC because
the messages in his concept are very short (a few hundred bit). So he
was thinking about a variant of AES-CBC, where he uses just 32 (random)
India recently forbade some Chinese companies from bidding on some
cell phone infrastructure projects, citing national security concerns:
http://www.chinatechnews.com/2010/05/25/12102-indias-bsnl-excludes-chinas-huawei-zte-from-gsm-bidding
Of course, the Chinese gov't and companies are by no
The last Thursday, Vincent Rijmen announced a new clever attack on AES
(and KASUMI) in a report posted to the Cryptology ePrint Archive:
Practical-Titled Attack on AES-128 Using Chosen-Text Relations,
http://eprint.iacr.org/2010/337
I believe the related-subkey model is an interesting
CFP: ACM CCS Workshop on Insider Threats
Apologies for cross-posting.
-Matt
ACM Workshop on Insider Threats
http://www.csiir.ornl.gov/ccsw2010/
Call for Papers
ACM Workshop on Insider Threats
in conjunction with ACM CCS 2010
October 8, 2010
When equipped with insider knowledge, an attacker
For years, there have been unverifiable statements in the press about assorted
hostile parties using steganography. There may now be a real incident -- or at
least, the FBI has stated in court documents that it happened.
According to the Justice Department
All,
I've got a perfect vs. good question.
NIST is pushing RSA-2048. And I think we all agree that's probably a
good thing.
However, performance on RSA-2048 is too low for a number of real world
uses.
Assuming RSA-2048 is unavailable, is it worth taking the intermediate
step of
http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors
Tuesday, June 29, 2010
Nanoscale Random Number Circuit to Secure Future Chips
Intel unveils a circuit that can pump out truly random numbers at high speed.
By Tom Simonite
It
CHAOCIPHER REVEALED: THE ALGORITHM
Moshe Rubin © 2 July 2010
ADDRESS: Rechov Shaulson 59/6, Jerusalem 95400 ISRAEL;
mos...@mountainvistasoft.com.
ABSTRACT: Chaocipher is a method of encryption invented by John F. Byrne
in 1918, who tried unsuccessfully to interest the US Signal Corp and
Navy in
Hi,
On Apr 27, 2010, at 5:38 AM, Peter Gutmann (alt) pgut001.reflec...@gmail.com
wrote:
GPS tracking units that you can fit to your car to track where your
kids are
taking it (or *cough* other purposes) have been around for awhile
now. It's
interesting to see that recently the sorts of
On Thu, 22 Apr 2010, Zooko O'Whielacronx wrote:
On Wed, Apr 21, 2010 at 5:29 PM, Samuel Neves sne...@dei.uc.pt wrote
(on the cryptography@metzdowd.com list):
[2] http://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf
As one of the authors of the above paper, I have an obvious interest in
this
Jonathan Katz wrote:
[2] http://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf
On the other hand, there is one published scheme that gives a slight
improvement to our paper (it has fewer on-line computations): it is a
paper by Chevallier-Mames in Crypto 2005 titled An Efficient CDH-Based
On Fri, Apr 23, 2010 at 3:57 AM, Paul Crowley p...@ciphergoth.org wrote:
My preferred signature scheme is the second, DDH-based one in the linked
paper, since it produces shorter signatures - are there any proposals which
improve on that?
http://eprint.iacr.org/2007/019
Has one. Caveat
On Thu, Apr 22, 2010 at 12:40 PM, Jonathan Katz jk...@cs.umd.edu wrote:
On Thu, 22 Apr 2010, Zooko O'Whielacronx wrote:
Unless I misunderstand, if you read someone's plaintext without having
the private key then you have proven that P=NP!
…
The paper you cite reduces security to a
On Wed, 28 Apr 2010, Zooko O'Whielacronx wrote:
Anyway, although this is not one, there do exist proposals for public
key crypto schemes where breaking the scheme implies solving a worst
case instance of a supposedly hard problem, right?
Not to worst-case hardness of an NP-complete problem,
Folks:
Regarding earlier discussion on these lists about the difficulty of
factoring and post-quantum cryptography and so on, you might be
interested in this note that I just posted to the tahoe-dev list:
100-year digital signatures
Dear people of the cryptography mailing lists:
We just released Tahoe-LAFS v1.7. The major new feature is an SFTP
server. This means that (with enough installing software and tinkering
with your operating system configuration) you can have a
normal-looking mount point backed by a Tahoe-LAFS grid.
[cc:d to cryptography list from the tahoe-dev list.
See http://allmydata.org/pipermail/tahoe-dev/2010-June/004439.html,
http://allmydata.org/pipermail/tahoe-dev/2010-June/004502.html and
http://allmydata.org/pipermail/tahoe-dev/2010-June/004496.html for context.]
Brian Warner wrote:
On 6/23/10
David-Sarah Hopwood wrote:
[snip]
There could also be a concern that point 4 above is similar to
on-line/off-line signatures as patented by Even, Goldreich and Micali
(U.S. patent 5016274, filed in 1988; expires on 14 May 2011).
Ah, I calculated the expiration date incorrectly. It was filed
CTR mode seems a better choice here. Without getting too technical,
security of CTR mode holds as long as the IVs used are fresh whereas
security of CBC mode requires IVs to be random.
In either case, a problem with a short IV (no matter what you do) is the
possibility of IVs repeating. If
Unfortunately I can't remember the author, but there was a paper
showing that an encrypted counter was secure to use as IVs for CBC
mode. So encrypting a shorter random IV should also be secure.
Greg.
On 2010 Jun 2, at 9:36 , Ralph Holz wrote:
Dear all,
A colleague dropped in yesterday
On Mon, 14 Jun 2010, Alfonso De Gregorio wrote:
The last Thursday, Vincent Rijmen announced a new clever attack on AES (and
KASUMI) in a report posted to the Cryptology ePrint Archive: Practical-Titled
Attack on AES-128 Using Chosen-Text Relations,
http://eprint.iacr.org/2010/337
Err...I
On Thu, 1 Jul 2010 06:46:30 +0200
Dan Kaminsky d...@doxpara.com wrote:
All,
I've got a perfect vs. good question.
NIST is pushing RSA-2048. And I think we all agree that's
probably a good thing.
However, performance on RSA-2048 is too low for a number of real
world uses.
Dan,
I looked at the GNFS runtime and plugged a few numbers in. It seems
RSA Security is using a more conservative constant of about 1.8 rather
than the suggested 1.92299...
See:
http://mathworld.wolfram.com/NumberFieldSieve.html
So using 1.8, a 1024 bit RSA key is roughly equivalent to
On Jul 9, 2010, at 1:55 12PM, Jonathan Katz wrote:
CTR mode seems a better choice here. Without getting too technical, security
of CTR mode holds as long as the IVs used are fresh whereas security of CBC
mode requires IVs to be random.
In either case, a problem with a short IV (no matter
The following usenet posting from 1993 provides an interesting bit
(no pun itended) of history on RSA key sizes. The key passage is the
last paragraph, asserting that 1024-bit keys should be ok (safe from
key-factoring attacks) for a few decades. We're currently just
under 1.75 decades on from
On Jul 9, 2010, at 1:55 PM, Jonathan Katz wrote:
CTR mode seems a better choice here. Without getting too technical,
security of CTR mode holds as long as the IVs used are fresh
whereas security of CBC mode requires IVs to be random.
In either case, a problem with a short IV (no matter what
35 matches
Mail list logo
