I presume a few people will want to cite the Round 1 submissions to NIST's PQC "process". I've put a bib file parsed from the NIST website here: https://gist.github.com/malb/1b06e6bb90078561873f25b820103d58

I noticed that for some conferences, the year field is incorrect.

For instance, CRYPTO 1991 uses year field 1992, Eurocrypt 1992 uses year field 1993, Eurocrypt 1993 uses year field 1994, CRYPTO 1993 uses year field 1994, Eurocrypt 1994 uses year field 1995.
This seems to be the case for all CRYPTOs between 1984 and 1993 and Eurocrypts between 1982 and 1994.

I have not checked if this also applies to other conferences.

This is such a great resource, but I wonder why it doesn't include publications from Usenix Security.

My understanding is that the crypto.bib file should not contain cross references.

However, there are three books in the current crypto.bib that are cross referenced:
NguZhe10, JoyTun12, SadNac10.

Hi, when trying to use crypto.bib with biber http://biblatex-biber.sourceforge.net/ I run into the following error

WARN - Entry SP:D does not parse correctly
WARN - Entry PODC:JohD does not parse correctly
WARN - Entry STOC:O does not parse correctly
WARN - Entry EPRINT:O does not parse correctly
ERROR - BibTeX subsystem: /tmp/RUa9x87y4f/crypto_crossref.bib_20112.utf8, line 132486, syntax error: found "ForHel96", expected ","

These are because of the use of apostrophes in bibtex keys, i.e. the following diff fixes the issue for me:

diff --git a/crypto_crossref.bib b/crypto_crossref.bib
index 78ba6c2..807f58b 100755
--- a/crypto_crossref.bib
+++ b/crypto_crossref.bib 
@@ -132483,7 +132483,7 @@
   crossref =     ieeesp96,
 }

-@InProceedings{SP:D'hForHel96,
+@InProceedings{SP:DhForHel96,
   author =       "Patrik D'haeseleer and
                   Stephanie Forrest and
                   Paul Helman",
@@ -165242,7 +165242,7 @@
   crossref =     podc13,
 }

-@InProceedings{PODC:JohD'S13,
+@InProceedings{PODC:JohDS13,
   author =       "Samuel D. Johnson and
                   Raissa M. D'Souza",
   title =        "Brief announcement: brokerage and closure in a strategic model of social capital",
@@ -210078,7 +210078,7 @@
   crossref =     stoc15,
 }

-@InProceedings{STOC:O'DWri15,
+@InProceedings{STOC:ODWri15,
   author =       "Ryan O'Donnell and
                   John Wright",
   title =        "Quantum Spectrum Testing",
@@ -241620,7 +241620,7 @@
   note =         "\url{http://eprint.iacr.org/2015/210}",
 }

-@Misc{EPRINT:O'FChe15,
+@Misc{EPRINT:OFChe15,
   author =       "Colin O'Flynn and
                   Zhizhang Chen",
   title =        "Power Analysis Attacks against {IEEE} 802.15.4 Nodes",

Some conferences span multiple months, and the cryptobib citations write them as e.g. sep~/~oct. This makes Biber unhappy, since it expects integers for months:

Biber warning: [5804] Utils.pm:164> WARN - month field '9~/~10' in entry 'CHES11' is not an integer - this will probably not sort properly.

I expect this is deliberate and I should just ignore the biber warning, but wanted to bring it up in case it wasn't.

The list of such conferences in abbrev3 is:

$ grep -ir month cryptobib/abbrev3.bib | grep \~ | cut -d\{ -f2 | cut -d' ' -f1 | tr \n , | sed s/month//g
acisp15,ccs06,asiacrypt94,asiacrypt03,asiacrypt15,ches05,ches11,cqre99,rsa12,rsa13,rsa16,eurocrypt82,eurocrypt98,eurocrypt02,eurocrypt06,fc05,fc06,fc11,fc12,focs89,icalp74,icalp03,icisc06,icisc11,isc02,isc06,latin14,ndss07,ndss10,pkc13,pkc15,podc98,provsec08,stoc95,stoc09,stoc14,trustbus04,trustbus11,

Hello,

When using cryptobib with biber, some French names (e.g., Benoît) were encoded incorrectly,
for example î should be encoded as {\^i} instead of {\^\i}, causing the following error during the compilation

Package inputenc Error: Unicode character ̂(U+302) [...]

NDSS:CarMan16's title should be Killed by Proxy: Analyzing Client-end {TLS} Interception Software

Hi!

was trying to import FOCS21 but this conference curiously (well, ...) happend in 2022 (but there's also going to be FOCS22 of course)

is there a good way to map this in the cryptobib system?

I have corrected a problem in eprint that showed up in cryptobib as well. In crypto_db.bib there is an occurrence of \" which has caused a problem with a bibtex parser and also caused problems with our work on the new IACR journal. The error is in EPRINT:Castelluccia06 where it has \". It should be just "

I have already corrected this in https://eprint.iacr.org/2006/416

Hi,

the current commit of the export repo cryptobib/export@041e0ec(maybe previous ones as well) contains two keys EPRINT:BeiD'AVer21 and EPRINT:ThiO'FDew21 with apostrophes.
This breaks biber such that it doesn't recognize any keys anymore (as least for me).
I searched a bit and did not find an official statement that bibtex keys should be apostrophe-free, but I did find this thread confirming that apostrophes in bibtex keys cause issues.

I took a look at the DBLP entries and their bibtex keys but they don't contain apostrophes, thus I guess that cryptobib creates the keys.

Best,
Nicholas

PS: As a hotfix, manually deleting the apostrophes resolved the issue.

Hi,
The bib entry TCHES:SBHM20 author name Mark E. Marson started with an and, which cause the Biber warning.

Please check and correct this.
Regards

@Article{TCHES:SBHM20,
  author =       "Pascal Sasdrich and
                  Beg{\"u}l Bilgin and
                  Michael Hutter and
                  and Mark E. Marson",
  title =        "Low-Latency Hardware Masking with Application to {AES}",
  pages =        "300--326",
  volume =       2020,
  publisher =    tchespub,
  year =         2020,
  journal =      tches,
  number =       2,
  doi =          "10.13154/tches.v2020.i2.300-326",
  issn =         tchesissn,
  note =         "\url{https://tches.iacr.org/index.php/TCHES/article/view/8553}",
}

The FSE papers only have a DOI from 2013 on.
Do you have some (semi-) automatic way to fetch these from the springer homepage or something?

Issues 1-3 are there, but 4 seems to be missing.
https://dblp.org/db/journals/popets/popets2018.html

The following paper has wrong paper title indicated in crypto.bib.
https://www.di.ens.fr/david.pointcheval/Documents/Papers/2003_acisp.pdf

@InProceedings{ACISP:PiePoi03,
author = "Josef Pieprzyk and
David Pointcheval",
title = "Josef Pieprzyk, David Pointcheval",
pages = "387--401",
editor = acisp03ed,
booktitle = acisp03name,
volume = acisp03vol,
address = acisp03addr,
month = acisp03month,
publisher = acisppub,
series = mylncs,
year = 2003,
}

The CCS booktitle has four letter years up to 2019, but then 2020 has "20". Is this intentional?

https://cryptobib.di.ens.fr/
In this link, I download the crypto.bib file. I search for the paper published in TCHES2021 issue2.
This paper name should be "Fault Attacks on CCA-secure Lattice KEMs" in https://tches.iacr.org/index.php/TCHES/article/view/8787
But in the file it is Fault attacks on lattice-based {KEMs}

EPRINT was last updated almost a year ago.

I'm not sure if this is the best place to point this out, but since the website https://cryptobib.di.ens.fr/ is can be considered part of the documentation for cryptobib I thought I'd put it here.

The website claims that then acronym for LATINCRYPT is "LATINCRYPT" but the bib files actually use "LC".

I was using pybtex to both parse and then format cryptobib, and it fails because there are @incollection entries in the database that are missing required fields. These are missing the required booktitle field, and have crossref entries to the book they are contained in, but the @book entries do not contain a booktitle - they only contain a title. There are two possible solutions:

1. populate the booktitles in the @incollection entries (I counted 63 of them)
2. populate the @book entries with both title and booktitle. This sounds like the right solution, because according to tame the beast,

A field that is neither mandatory nor optional, is ignored. Thus you can add any comment
or personal field in your bibliography, even if they’re not in the list below. Some other fields
might of course be used by other, non classical styles.

The case of @book having a booktitle field is specifically mentioned in section 12.

The entries that have this flaw are:

OswSta12:incollection:bibtex entry OswSta12 requires booktitle field
Clavier12:incollection:bibtex entry Clavier12 requires booktitle field
Rivain12:incollection:bibtex entry Rivain12 requires booktitle field
Giraud12:incollection:bibtex entry Giraud12 requires booktitle field
SchMed12:incollection:bibtex entry SchMed12 requires booktitle field
BDFR12:incollection:bibtex entry BDFR12 requires booktitle field
BerCanGou12:incollection:bibtex entry BerCanGou12 requires booktitle field
KimQui12:incollection:bibtex entry KimQui12 requires booktitle field
AlkDomHas12:incollection:bibtex entry AlkDomHas12 requires booktitle field
HarRey12:incollection:bibtex entry HarRey12 requires booktitle field
AWKS12:incollection:bibtex entry AWKS12 requires booktitle field
NguTib12:incollection:bibtex entry NguTib12 requires booktitle field
MraPagVer12:incollection:bibtex entry MraPagVer12 requires booktitle field
BarTri12:incollection:bibtex entry BarTri12 requires booktitle field
RBIK12:incollection:bibtex entry RBIK12 requires booktitle field
BBBPP12:incollection:bibtex entry BBBPP12 requires booktitle field
GuiDan12:incollection:bibtex entry GuiDan12 requires booktitle field
TFGLSO12:incollection:bibtex entry TFGLSO12 requires booktitle field
MaeVer10:incollection:bibtex entry MaeVer10 requires booktitle field
HanSchTuy10:incollection:bibtex entry HanSchTuy10 requires booktitle field
KMNSVZ10:incollection:bibtex entry KMNSVZ10 requires booktitle field
RuhBusKat10:incollection:bibtex entry RuhBusKat10 requires booktitle field
SPYQYO10:incollection:bibtex entry SPYQYO10 requires booktitle field
AMSST10:incollection:bibtex entry AMSST10 requires booktitle field
TehSun10:incollection:bibtex entry TehSun10 requires booktitle field
BGKN10:incollection:bibtex entry BGKN10 requires booktitle field
HamDanSun10:incollection:bibtex entry HamDanSun10 requires booktitle field
Kirovski10:incollection:bibtex entry Kirovski10 requires booktitle field
LBSPV10:incollection:bibtex entry LBSPV10 requires booktitle field
UllVog10:incollection:bibtex entry UllVog10 requires booktitle field
SadVisWac10:incollection:bibtex entry SadVisWac10 requires booktitle field
DenChaSuh10:incollection:bibtex entry DenChaSuh10 requires booktitle field
Kuhn10:incollection:bibtex entry Kuhn10 requires booktitle field
DGLM10:incollection:bibtex entry DGLM10 requires booktitle field
JKSS10:incollection:bibtex entry JKSS10 requires booktitle field
GuaAsiPet10:incollection:bibtex entry GuaAsiPet10 requires booktitle field
SLLLB10:incollection:bibtex entry SLLLB10 requires booktitle field
Nguyen10:incollection:bibtex entry Nguyen10 requires booktitle field
ValVer10:incollection:bibtex entry ValVer10 requires booktitle field
Schnorr10:incollection:bibtex entry Schnorr10 requires booktitle field
Stehle10:incollection:bibtex entry Stehle10 requires booktitle field
Hanrot10:incollection:bibtex entry Hanrot10 requires booktitle field
Simon10:incollection:bibtex entry Simon10 requires booktitle field
Kluners10:incollection:bibtex entry Kluners10 requires booktitle field
AarEis10:incollection:bibtex entry AarEis10 requires booktitle field
May10:incollection:bibtex entry May10 requires booktitle field
HHPW10:incollection:bibtex entry HHPW10 requires booktitle field
Gentry10:incollection:bibtex entry Gentry10 requires booktitle field
Micciancio10:incollection:bibtex entry Micciancio10 requires booktitle field
Khot10:incollection:bibtex entry Khot10 requires booktitle field
Regev10:incollection:bibtex entry Regev10 requires booktitle field
Zheng10:incollection:bibtex entry Zheng10 requires booktitle field
AnRab10:incollection:bibtex entry AnRab10 requires booktitle field
BaeSte10:incollection:bibtex entry BaeSte10 requires booktitle field
BLMQ10a:incollection:bibtex entry BLMQ10a requires booktitle field
BLMQ10b:incollection:bibtex entry BLMQ10b requires booktitle field
DenMal10:incollection:bibtex entry DenMal10 requires booktitle field
Bjorstad10:incollection:bibtex entry Bjorstad10 requires booktitle field
Dodis10:incollection:bibtex entry Dodis10 requires booktitle field
PiePoi10:incollection:bibtex entry PiePoi10 requires booktitle field
Boyen10:incollection:bibtex entry Boyen10 requires booktitle field
Dent10:incollection:bibtex entry Dent10 requires booktitle field
CuiHan10:incollection:bibtex entry CuiHan10 requires booktitle field

The @book entries that they crossref are:
JoyTun12, SadNac10, NguVal10, DenZhe10

I tried to compile the whole cryptobib to see if changes broke anything:

\documentclass{scrartcl}

\usepackage[american]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

\usepackage{csquotes}

\usepackage{biblatex}
\bibliography{abbrev3,crypto_db,crypto_conf_list}
\begin{document}
\nocite{*}
\printbibliography{}
\end{document}

But apparently, there are some errors, like invalid characters in labels, multiple "and" in author fields and so on. Most of them is easy to fix, I'll prepare a PR in a moment.
But one warning is:

WARN - BibTeX subsystem: /tmp/p8quxHBGKq/crypto_db.bib_6845.utf8, line 117842, warning: undefined macro "icalp16"

(this appears for each ICALP 16 entry). The problem here is, we need either icalp16-1 or -2, I guess.
I do not see a quick way to figure out, which label is the correct one, so I'll skip this for now.
Another warning is the multiple month one, already mentioned in Issue #22 by @katrielalex.

Hi there, would you accept a PR to add

• https://www.springer.com/journal/10623
• https://www.degruyter.com/journal/key/jmc/html
• https://journals.flvc.org/mathcryptology (which I guess kind of is JMC 2.0)
  ?

Adding those seems easy enough but I wanted to check first.

Volume 33 issues 1-3 seem to be there, and volume 34 is there, but volume 33 issue 4 seems to be missing.

add_journal("TCHES", 2018, "tches", "Transactions on Cryptographic Hardware and Embedded Systems",
            months=[],
            url="httpss://dblp.uni-trier.de/db/journals/tches/tches${year}.html")

This should read https.

According to his webpage (http://gonzaleznieto.com/?page_id=4), I believe his last name is Gonzales Nieto. Many bib entries/keys should be corrected...

I'll do a PR eventually, I was just posting it here not to forget.

There's an extra s in the title. A possible correction is

 @InProceedings{EC:KowWee19,
   author =       "Lucas Kowalczyk and
                   Hoeteck Wee",
-  title =        "Compact Adaptively Secure {ABE} for {$\mathsf{NC}s^1$} from $k$-Lin",
+  title =        "Compact Adaptively Secure {ABE} for {$\mathsf{NC}^1$} from $k$-Lin",
   pages =        "3--33",
   editor =       eurocrypt19ed,
   booktitle =    eurocrypt19name1,

The titles of EPRINT:Niehage20, EPRINT:RGGSWY18, and USENIX:BocSomYou18 have words (Nextcloud, Bleichenbacher, Bleichenbacher) that should be forced to be capitalized (i.e., put into curly brackets).

Happy to quickly create a PR if you grant me the right to.

Listed authors are Xuejia Lai and James L. Massey, while the paper https://link.springer.com/content/pdf/10.1007%2F3-540-46416-6_2.pdf also lists Sean Murphy (as does dblp do).

I would appreciate it if the ESORICS 2021 proceedings would be added at some point for entirely selfish reasons.

(I expect I will get to this soonish.)

I am trying to compile my manuscript. I am using the CCS template, as follows:

\bibliographystyle{ACM-Reference-Format}
\bibliography{mybibliography,abbrev3,crypto}

But when I compile my tex, I am getting the following errors, and the reference list does not show up:

This is BibTeX, Version 0.99d (TeX Live 2017/Debian)
The top-level auxiliary file: main.aux
The style file: ACM-Reference-Format.bst
A level-1 auxiliary file: appendix.aux
Database file #1: mybibliography.bib
Database file #2: abbrev3.bib
Database file #3: crypto.bib
Sorry---you've exceeded BibTeX's hash size 100000
Aborted at line 291526 of file crypto.bib
(That was a fatal error)

Process exited with error(s)

However, if I break the bib files into 3 separate lines, it compiles (with some warnings) but this way I am getting my references displayed 3 times...

\bibliography{mybibliography}
\bibliography{abbrev3}
\bibliography{crypto}

Is there any solution for that? I have tried looking on how to increase the Bibtex hash size but couldn't find anything...

It possibly makes sense to include the proceedings of Euro S&P to cryptobib, as S&P is already included.

Springer's instruction is, for example,

• to cite papers in Eurocrypt 2023 as "... Springer, Cham...", and
• to cite papers in Eurocrypt 2016 as "... Springer, Berlin, Heidelberg...".

CryptoBib currently cites all "Springer" as "Springer, Heidelberg[, Germany]".

I also observe that when a paper is sent to Springer for typesetting, they will correct the cities. Going forward, I think it's a good idea to have crypto23pub and crypto24pub separate, referencing springercham and springeranothercity, instead of a single cryptopub referencing springer.

For at least 2 entries (EPRINT:DebDut16 and EPRINT:ZhaKatPap16), there are trailing invisible characters (^C) after the name of one of the authors.
This leads to a LaTeX compilation (with inputenc) error when one of these references is included.
The LaTeX log follows:

./puncturable-sse.bbl:243: Package inputenc Error: Keyboard character used is u
ndefined
(inputenc)                in inputencoding `utf8'.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.243 Zhang, Y., Katz, J., and Papamanthou^^C
                                             , C.
You need to provide a definition with \DeclareInputText 
or \DeclareInputMath before using this key.

The last 6 issues of ToSC are missing in cryptodb, is it possible to include them?

I can try to submit a pull request, but I'm not sure how you're handling ToSC: there is a comment in config.py saying: "Warning: we are not using the import.py script for ToSC".

See question and the first answer in StackOverflow

https://tex.stackexchange.com/questions/158550/%C3%AF-%C3%AE-font-encoding

The following entry exists in crypto.bib

@InProceedings{FOCS:DPPS04,
  author =       "Yevgeniy Dodis and
                  Shien Jin Ong and
                  Manoj Prabhakaran and
                  Amit Sahai",
  title =        "On the (Im)possibility of Cryptography with Imperfect Randomness",
  pages =        "196--205",
  editor =       focs04ed,
  booktitle =    focs04name,
  address =      focs04addr,
  month =        focs04month,
  publisher =    focspub,
  year =         2004,
}

and I'm quite unsure where the key DPPS comes from. As far as I can tell it should be DOPS.

I would appreciate it if the LATINCRYPT 2021 proceedings would be added at some point for entirely selfish reasons.

(I expect I will get to this soonish.)

In the entries with keys "EPRINT:TakTibAbe18" and "TCHES:TakTibAbe18" the title should have braces around "Bleichenbacher" so that it is properly capitalized by bibtex.

Hi,

I just spotted that the names of all AsiaCCS conferences in the database are incorrect. They mistakenly reference the name of CCS instead.
I.e., in all abbrev files, the names of the AsiaCCS conferences is set as in the following example

@string{asiaccs11name = "ASIACCS 11: 6th " # ccsname}

Where "ccsname" should actually be "asiaccsname".

The PQCrypto workshops and conferences aren't in cryptobib.

Currently crypto.bib uses the note field for URLs. However, the canonical field for URLs is url and many tools expect it there, cf. tmalsburg/helm-bibtex/pull/185 It would be great of URLs could be moved to the url field.

I don't see a bibtex entry in the cryptobib for the cryptobib itself.

How should it be cited? For example would it make sense to add this to a pull request?

@misc{michel_abdalla_cryptobib_2015,
    title = {{CryptoBib} Database},
    url = {https://cryptobib.di.ens.fr/},
    shorttitle = {{CryptoBib}},
    abstract = {"{CryptoBib} is a {BibTeX} database containing papers related to Cryptography, with manually checked entries and uniform {BibTeX} data. {CryptoBib} can be used as a classical {BibTeX} database. {BibTeX} keys are short and easy to remember."},
    publisher = {{CASCADE} Team - Inria},
    author = {{Michel Abdalla}},
    editor = {{Michel Abdalla} and {Fabrice Benhamouda.}},
    date = {2015-06-12},
}

Issue 1. The name "Turing" should always have a capitalized "T".

A quick search over crypto.bib reveals the following cases: Turing (47 not followed by s), Turings (1), {Turing} (7), "Turing (3). According to Tame the BeaST, the correct encoding is {T}uring, regardless of where this word appears. The recommended fix is to do the following regular-expression replacements:

1. title =(.*?) Turing (leading space is significant to avoid replacing booktitle) replaced by title =$1 {T}uring repeatedly until there are no more occurrences (the word "Turing" might appear multiple times in a title). The replacement count should be 47+1.
2. \{Turing\} replaced by {T}uring. The replacement count should be 7.
3. title =(\s*)"Turing replaced by title =$1"{T}uring. The replacement count should be 3.

Issue 2. The first word after colons are often misencoded. For example, ACISP:LMOQ22 is currently encoded as {TIDE}: {A} Novel Approach to Constructing Timed-Release Encryption, but {A} should really be A. BibTeX "t" change.case$ (title casing) will not change the first letter after a colon followed by a space (see @<Perform the case conversion@>= in bibtex.web).

I am not sure if there is a compatibility reason for forcing the case after a colon (maybe some users use a BibTeX style that does not handle the word after a colon correctly). Also, it seems to require an enormous amount of effort to fix this, because one has to determine whether the first word following the colon is a proper phrase (e.g., {TM}: {T}uring Machine and {UTM}: Universal {T}uring Machine are correct). Therefore, currently I do not have a fix proposal.

Issue 3. The title of ICALP:Harel12 is misencoded. It should be (capitalization of "A" and "M", in addition to capitalization of "T")

Standing on the Shoulders of a Giant - One Persons Experience of {T}urings Impact (Summary of the {A}lan {M}. {T}uring Lecture - Invited Talk)

The work, as published by Springer, indeed writes "Persons" and "Turings" instead of "Person’s" and "Turing’s". I am also not sure whether hyphen-minus (-) or en dashes (--) or em dashes (---) should be used.

The title of CCS:Hellman16 is also misencoded. It should be (capitalized "A")

Cybersecurity, Nuclear Security, {A}lan {T}uring, and Illogical Logic

Issue 4. The title of EC:JLMS19 has a typo. The word is "over", not "overa".

Issue 5. The titles of some works jointly authored by me (Ji Luo). In the following, it is normal that different versions of the same work have different abbreviation/capitalization of certain parts.

• EPRINT:LinLuo20a should preserve lowercase "k" and capital "L" in "k-Lin":

Compact Adaptively Secure {ABE} from {k}-{L}in: Beyond {NC1} and towards {NL}

• AC:LinLuo20 should preserve capital "L" in "k-Lin":

Succinct and Adaptively Secure {ABE} for {ABP} from {$k$}-{L}in

• EPRINT:LinLuo20b should preserve lowercase "k" and capital "L" in "k-Lin":

Succinct and Adaptively Secure {ABE} for Arithmetic Branching Programs from {k}-{L}in

• EC:GonLuoWee23 should preserve capital "N", and lowercase "k" and capital "L" in "k-Lin".

Traitor Tracing with ${N}^{1/3}$-Size Ciphertexts and ${O}(1)$-Size Keys from {$k$}-{L}in

• EPRINT:GonLuoWee23 should use math for "O(1)", and preserve capital "L" in "k-Lin".

Traitor Tracing with {${N}^{1/3}$}-size Ciphertexts and ${O}(1)$-size Keys from {$k$}-{L}in

Updates

2023-07-24. Corrected a typo in suggested fix, improved suggested fix.

hi,

I was about to submit a patch that fixes some apparently erroneous occurences of the following pattern.

{Amaury de} Wargny
{Arnaud de} Mesmay
{Benne de} Weger
{Daniel Santana de} Freitas
{Fabien de} Montgolfier
{Fr{\'e}d{\'e}ric de} Portzamparc
{Jeroen van de} Graaf 
{Patrice Ossona de} Mendez
{Xavier de Carn{\'e} de} Carnavalet
{Ronald de} Wolf

which, I think, are all wrong except if authors have the unusual demand that their particle belong to their first name. While these forms do correctly sort the authors at, say, W for 'de Wargny', they do so by stripping off the particle in an abbreviated author entry.

However I noticed that there were manual edits to the database to specificallly enforce some of the entries above. (the last one in particular).

Was there a particular rationale that I could have missed ?

The database seems to contain at least one paper twice, once as "Cocks01" and once as IMA:Cocks01, as listed below.

@InProceedings{Cocks01,
  author =       "Clifford Cocks",
  title =        "An Identity Based Encryption Scheme Based on Quadratic Residues",
  pages =        "360--363",
  booktitle =    "Cryptography and Coding, 8th IMA International Conference",
  editor =       "Bahram Honary",
  publisher =    springer,
  address =      "Cirencester, UK",
  series =       mylncs,
  volume =       2260,
  month =        dec # "~17--19,",
  year =         2001,
}

@InProceedings{IMA:Cocks01,
  author =       "Clifford Cocks",
  title =        "An Identity Based Encryption Scheme Based on Quadratic Residues",
  pages =        "360--363",
  editor =       ima01ed,
  booktitle =    ima01name,
  volume =       ima01vol,
  address =      ima01addr,
  month =        ima01month,
  publisher =    imapub,
  series =       mylncs,
  year =         2001,
}

I'm not sure if this was done on purpose. (I'm also not sure if it should be changed given that it would break backwards compatibilty.) But when choosing the wrong one, i.e. "Cocks01", the entry is also not affected by the abbrev files.

Hi!

I just cited Pedersen's crypto paper from 91 and in the references it shows up as this occurred in 1992. I did a little digging and the problem is that in the @proceedings for C91 the year is off by 1. Looking at the proceedings for 90, 92, 93, 89, 88, 87, etc the year attribute is also wrong here. This makes me think it might be a general problem and maybe extend to other conferences as well. Starting from CRYPTO94 and up everything seems fine and as well for CRYPTO84 and down.

The custom cryptobib generation page (https://cryptobib.di.ens.fr/custom) does not seem to allow including eprint papers.

The TCHES proceedings in crypto_conf_list.bib are attributed to LNCS rather than TCHES

How should journals be treated that don't always publish in the same month of the year? Say Volume 2 is in February some years and in March some other years?

For some reason the "ccs19addr" is not set in any of the abbrev files. It should be "London, UK" in abbrev0 and abbrev2 unless I'm mistaken.