CryptoDox talk:Community Portal

From CryptoDox, The Online Encyclopedia on Cryptography and Information Security

Jump to: navigation, search


SVG Support

Read the CryptoDox:Community_Portal page on the issue we are facing with SVG images. How can we get SVG images to work? To see an example of the error we get, see MD5.svg. --Anuj 01:10, 17 October 2007 (EDT)

Ways to improve the Wikipedia dump

It would be nice if the "external links" section of each imported page mentioned "This page originally based on ..." with a link back to the Wikipedia page.

--> You will see this in the revision history as a comment. --Anuj 13:33, 16 October 2007 (EDT)

Is there anything else we need to do to avoid plagiarism? Can we do this automatically?

There are sites which provide this as a premium service. I can evaluate it to see if it works well on a wiki. --Anuj 13:33, 16 October 2007 (EDT)

It would be nice if pages that say "Don't do X" went on to recommend "Do Y instead". For example, the RC4 currently says "RC4 ... is not recommended for use in new applications." I'm going to edit it to explicitly say what *is* recommended for use in new applications, but I'm sure there are dozens of other pages that have a similar discouraging "Don't do X" that also need to be updated with the latest positive recommendations on what to use instead.

--DavidCary 12:23, 16 October 2007 (EDT)


How can we collaborate with the SPORE: Security Protocols Open Repository group? --DavidCary 14:40, 17 October 2007 (EDT)

yet another proposed protocol

I posted yet another cryptography-related protocol to . Should I copy it / move it here to CryptoDox, so experts can point out its flaws? --DavidCary 17:28, 30 January 2008 (EST)

David, feel free to make a local copy here. --Anuj 06:20, 6 February 2008 (EST)

OK, I'll post a copy (literally) here in the "CryptoDox talk:Community Portal". Perhaps later we can create a page for "protocol proposals" and move this sort of brainstorming there. --DavidCary 16:55, 14 February 2008 (EST)

yet another misguided protocol

Problem: A bunch of people who edit a wiki or talk in a IRC chat room (or some other non-real-time, long-distance, community) need to make some essentially arbitrary decision. And sometimes they become so polarized they cannot reach a consensus.


  • How to keep one person from stuffing the ballot box with lots of "sock puppets"?
  • How to keep one real person from forging a ballot from some other real person?
  • How to avoid transmitting a password in plain text?

Proposed protocol:

(brainstorming) Make a "votes" server. Make it so you can log into it, and register a vote. Have it publish HTML fragments for both presenting results, and for collecting results. Users have a password that they use to key their vote in. Users also have a username associated with the password, used for presenting results of the vote, which must be unique to the votes server.

There are several ways to verify unique votes even when (most) communication is through a public IRC room.

  • Every day, the vote server invents a completely random string (today's random string), and publishes it publicly somehow.
  • Each voter makes up their own random string for each vote and also fetches the vote server's "today's random string".
  • The voter calculates a confirmation sum = sha-2( (id-of-vote) (id-of-selection) (voter's random string) (voter's secret password) (today's random string) ).
  • The vote server watches IRC for votes of the form (name) "vote" (id-of-vote) (id-of-selection) (voter's random string) (confirmation sum).
  • The server does the same calculation the the voter does, and compares the sha-2 in the message with the one it calculated.
  • The vote server replies with one of "validated!", "sorry, something got corrupted in transmission", or "Hey! you already voted (id-of-vote) (previous-id-of-selection)!". (So, should only the *first* vote from that person count, or only the *last* vote?)
  • Somehow, the vote server closes the id-of-vote and refuses to accept any more votes on that particular issue (perhaps a fixed 3 weeks after it first sees a particular (id-of-vote) ... or some other way).
  • Anyone can ask the vote server at any time for the current totals on any particular id-of-vote, what today's random string is, or a list of ids of currently open id-of-vote and when they will be closed.

This protocol assumes:

  • good-enough random number generators
  • the passwords and random numbers are long enough to prevent guessing
  • Only one voter and the vote server know that voter's password (previously communicated over some other, private, communication channel)
  • Somehow, the list of passwords in the vote server is limited to the people who are allowed to vote -- no more, no less.
  • enough bandwidth that all valid voters can send a vote to the vote server, even if someone is flooding the channel in a denial-of-service attack.
  • hopefully no man-in-the-middle attack blocks people who vote "the wrong way", or sends out his own "current totals" that trick people into thinking the results were different.
  • it's OK that everyone knows exactly how everyone else voted.

... there's also a way to tweak this into a protocol that keeps it secret which way each person voted ... Actually, no, that additional requirement opens up many more vulnerabilities. Avoiding those vulnerabilities requires far more than a "tweak".

A protocol like this is a technological solution to a small part of the problem. The protocols mentioned on vote may be better. The bigger social part of the problem still remains.

import articles

What's the best way to import articles from Wikipedia? --DavidCary 18:12, 23 September 2008 (EDT)