Phillip Hallam-Baker wrote on 1/3/19 1:29 PM: > UDF=KD25H-GSNE2-JVVJE-RXTMA-7VAWT > UDF=KCOO3-EKPAG-FKYFC-O2B2N-O3UUA > UDF=KBR3A-RQLV7-SMB6X-6OB7X-JMBNT  Ooh, I've tagged this email as "Later" so I can go back to that. How will I go about verifying those when the secrets are divulged? (Pardon me if I haven't been paying attention in class here.) > Of couse, I could do what I usually do and re-invent stuff because I am > too lazy to read the literature. But I rather doubt there is a > literature in this case... That's the spirit. I doubt anyone will do it better than you anyway. ;) Seriously though maybe take a look at HashGraph and see if there's anything there ready for adoption and use, and get back to us. -- Patrick _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

From: cryptography <cryptography-bounces+dennis.hamilton=acm.org@metzdowd.com> On Behalf Of Phillip Hallam-Baker Sent: Thursday, January 3, 2019 10:30 To: Cryptography Mailing List <cryptography@metzdowd.com> Subject: [Cryptography] Blockchain without proof of work [orcmid] [ … ] So what is the current state of the art on blockchain without proof of work? Harber and Stornetta suggested publication in the Times. Which is of course recourse to a higher level notary. The next obvious approach is a circular firing squad of notaries that cross notify. Has anyone published anything further I should present? Of couse, I could do what I usually do and re-invent stuff because I am too lazy to read the literature. But I rather doubt there is a literature in this case... [orcmid] ALGORAND is a distributed ledger that avoids proof-of-work by reliance on a (Fast-and-Furious) Byzantine Agreement methodology. See https://www.algorand.com/ and also https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf (PDF download). Silvio Micali has also provided an ACM Learning webcast with an interesting slide-deck and commentary. I find the number of patents pending rather discouraging. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Fri, Jan 4, 2019 at 12:18 PM Dennis E. Hamilton <dennis.hamilton@acm.org> wrote: > > > *ALGORAND is a distributed ledger that avoids proof-of-work by reliance on > a (Fast-and-Furious) Byzantine Agreement methodology. See* > > *https://www.algorand.com/ <https://www.algorand.com/>; and also > https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf > <https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf>; > (PDF download). Silvio Micali has also provided an ACM Learning webcast > with an interesting slide-deck and commentary. * > > > > *I find the number of patents pending rather discouraging. * > Thanks, that is what I am looking for. I consider all proof of resource schemes equally obnoxious. I started in this business writing arcade games for 8-bit CPUs with Arduino class processing and memory. The basis for modern cryptography is the assumption that the attacker has dramatically greater resources than the defender so that they can afford work factors of 2^64, 2^72 or even higher to break schemes. So proof of work/ space/ stake/ pudding are all unacceptable to me. The number of patents is discouraging and mean that I probably face a choice between patenting anything I invent myself or having someone else do that. Someone once told me there are over a hundred US patents on technologies I invented that don't have my name listed as an inventor. Thats how I became an expert witness in the WebMail case (a Web Mail service written as a thin wrapper round VMS mail was the test case I used for for HTTP that led to the Content-Length field being added to make the POST and PUT methods work). The reason BitCoin is successful is of course the belief that people are making money. Most people find it much easier to believe things that they agree with. And what is there to disagree with about getting rich? It is why people get into Ponzi schemes or support obviously corrupt politicians who tell them while male heterosexual people like themselves are morally superior to all other folk. The thing with money is that money is whatever people believe to be money so the Tinkerbell spell works as long as people believe. Which is of course why 80% of the folk on this list saw the BitCoin announcement but only a tiny number ever bothered to mine on a serious basis. We are skeptics and don't believe. Perhaps because we saw GoldAge, e-Gold and the rest. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

Phillip Hallam-Baker <phill@hallambaker.com> writes: >The number of patents is discouraging and mean that I probably face a choice >between patenting anything I invent myself or having someone else do that. >Someone once told me there are over a hundred US patents on technologies I >invented that don't have my name listed as an inventor. Or you could publish a paper on the IACR e-print archive, https://eprint.iacr.org/curr/, or arXiv, https://arxiv.org/list/cs.CR/recent, documenting what you've done to prevent others from claiming it. Someone once complained that the last page or two of a paper I'd written was "just a brain dump of everything related to the work", which was exactly what it was supposed to be, a description of a wide range of practical applications so that no-one could take the theoretical part and render it into practice by way of patents. Peter. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Fri, Jan 4, 2019 at 7:16 PM Patrick Chkoreff <pc@fexl.com> wrote: > Phillip Hallam-Baker wrote on 1/3/19 1:29 PM: > > > UDF=KD25H-GSNE2-JVVJE-RXTMA-7VAWT > > UDF=KCOO3-EKPAG-FKYFC-O2B2N-O3UUA > > UDF=KBR3A-RQLV7-SMB6X-6OB7X-JMBNT > > Ooh, I've tagged this email as "Later" so I can go back to that. How > will I go about verifying those when the secrets are divulged? (Pardon > me if I haven't been paying attention in class here.) > OK so I have decided to make a few changes to the structure here so the values will change. Let us say that m = "Konrad is a Kompromised agent". first choose a random key kt = P (0xB0 || rand (512), 125) (where P is the presentation/truncation function using Base32 putting in dashes every 5 characters and truncating to 125 bits) We use SHA-2-512 to construct a Keyed UDF, so HKDF(), H(), HMAC() are functions all using that as the base digest: k = HKDF (kt, 512) f = HMAC (k, ct || ':' || H(m)) udf = P((v || f), 125) Where v is simply a tag to identify the fingerprint type and ct is the IANA content type So the core here is that we have a fingerprint of the data that can only be verified if the key kt is known. Since this is a keyed digest, we are using an HMAC for the purpose. I have pushed out the code to GitHub but I need to clean it up a bit. The version prefixes have been chosen so that the version number shows the fingerprint type. A SHA-2 fingerprint will always start with an M (Merkle-Damguard) and SHA-3 will always start with an S (Spongeworthy). Random numbers will always start with R and I had chosen K for Keyed hash. It since occurs to me that I should probably use K for actual Keys so maybe I need to move the prefixes about. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On 04/01/2019 02:29, Phillip Hallam-Baker wrote: > > The next obvious technical topic to tackle is blockchain. Right now, > blockchain is using more electricity than Ireland and minting several > billion worth of new currency to process fewer transactions than a > moderately busy CostCo. Obviously, blockchain should work on proof of stake. I have proposed the following system. Stake is registered with peers, of which there are a few hundred, which tend to be very large machines with very high bandwidth connections, but stake is owned by clients, who are hosted by peers. Clients tend to be small machines with low storage and low bandwidth connections. Client signatures can move stake from one peer to another. Stake is client money, so that power is ultimately in the hands of the clients, though a peer somewhat resembles a bank from the point of view of clients. Paxos protocol with peers holding fifty percent of stake get to decide on which transactions are committed and which are rolled back. I also have a plan for making this system anonymous, through transaction pooling, where each transaction is a pool of payments made by several public keys to several other public keys, and the block chain does not reveal which key in the pool were paying which other key in the pool, just the total going in and out, but I intend to publish the full details when I have something working. Bitcoin payments are pseudonymous, but when money goes in and out of the system, apt to connect pseudonyms to true names, and when bitcoin goes from one nym to another, reveals connections between nyms. Pooling would hide connections between nyms, because you would not know which of the many nyms in the pool was paying which of the many other nyms in the pool. Because the pools cannot be very large, and will often be quite small, this still leaks some information, giving people trying to follow the money clues and hints, but it leaks far less information than the bitcoin blockchain. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Sat, Jan 5, 2019 at 7:46 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote: ... >> > UDF=KD25H-GSNE2-JVVJE-RXTMA-7VAWT >> > UDF=KCOO3-EKPAG-FKYFC-O2B2N-O3UUA >> > UDF=KBR3A-RQLV7-SMB6X-6OB7X-JMBNT ... > > OK so I have decided to make a few changes to the structure here so the values will change. > > Let us say that m = "Konrad is a Kompromised agent". > first choose a random key kt = P (0xB0 || rand (512), 125) > (where P is the presentation/truncation function using Base32 putting in dashes every 5 characters and truncating to 125 bits) > > We use SHA-2-512 to construct a Keyed UDF, so HKDF(), H(), HMAC() are functions all using that as the base digest: > > k = HKDF (kt, 512) > f = HMAC (k, ct || ':' || H(m)) > udf = P((v || f), 125) > > Where v is simply a tag to identify the fingerprint type and ct is the IANA content type > So that's effectively just HMAC(rand(117), m), truncated to 120 bits (i.e. a birthday complexity of 60 bits). What purpose does the obfuscation serve? > So the core here is that we have a fingerprint of the data that can only be verified if the key kt is known. Since this is a keyed digest, we are using an HMAC for the purpose. > > I have pushed out the code to GitHub but I need to clean it up a bit. Is that this code? https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L212-L222 That link is to some bizarre functionality to "compress" the output by adding the number of leading zero bytes to the versionID, which further reduces the hash to 117 bits, and allows fingerprints from two different versions to collide. Your convenient Validate function isn't constant time: https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L407-L408 And throughout this library you've wrapped all the crypto functions in a way that obscure their nature and leads to typos: https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L39 https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/Standard/Digest.cs#L440 https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/Standard/Digest.cs#L515 https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/Algorithms/SHA3Managed.cs#L94 Mark _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Sat, Jan 5, 2019 at 2:55 PM Mark Steward <marksteward@gmail.com> wrote: > On Sat, Jan 5, 2019 at 7:46 AM Phillip Hallam-Baker > <phill@hallambaker.com> wrote: > ... > >> > UDF=KD25H-GSNE2-JVVJE-RXTMA-7VAWT > >> > UDF=KCOO3-EKPAG-FKYFC-O2B2N-O3UUA > >> > UDF=KBR3A-RQLV7-SMB6X-6OB7X-JMBNT > ... > > > > OK so I have decided to make a few changes to the structure here so the > values will change. > > > > Let us say that m = "Konrad is a Kompromised agent". > > first choose a random key kt = P (0xB0 || rand (512), 125) > > (where P is the presentation/truncation function using Base32 putting in > dashes every 5 characters and truncating to 125 bits) > > > > We use SHA-2-512 to construct a Keyed UDF, so HKDF(), H(), HMAC() are > functions all using that as the base digest: > > > > k = HKDF (kt, 512) > > f = HMAC (k, ct || ':' || H(m)) > > udf = P((v || f), 125) > > > > Where v is simply a tag to identify the fingerprint type and ct is the > IANA content type > > > > So that's effectively just HMAC(rand(117), m), truncated to 120 bits > (i.e. a birthday complexity of 60 bits). What purpose does the > obfuscation serve? > A straight hash function would allow a dictionary attack. Adding in the key means that a brute force attack has a work factor of the dictionary size times 2^512 which is obviously infeasible. > > So the core here is that we have a fingerprint of the data that can only > be verified if the key kt is known. Since this is a keyed digest, we are > using an HMAC for the purpose. > > > > I have pushed out the code to GitHub but I need to clean it up a bit. > > Is that this code? > > > https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L212-L222 > > That link is to some bizarre functionality to "compress" the output by > adding the number of leading zero bytes to the versionID, which > further reduces the hash to 117 bits, and allows fingerprints from two > different versions to collide. > That is important and useful functionality for key fingerprints. The compression function does not affect the brute force work factor for the attacker. What it means is that if the user puts in a Work Factor of 2^24 on key generation, the work factor of the resulting 125 bit fingerprint will be 2^(117+24) rather than 2^117. That is a standard construction that has been reviewed by the IETF. Unfortunately, there is a patent on a particular approach held by Microsoft. While they have licensed that for certain IETF protocols, it is not generally licensed. > Your convenient Validate function isn't constant time: > > > https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L407-L408 Probably not. That is currently just a placeholder. It doesn't even accept longer fingerprints to check against shorter patterns. > And throughout this library you've wrapped all the crypto functions in > a way that obscure their nature and leads to typos: > > > https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L39 > > https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/Standard/Digest.cs#L440 > > https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/Standard/Digest.cs#L515 > > https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/Algorithms/SHA3Managed.cs#L94 > That is historical due to the fact that .NET was changing as I was writing the code. So when I originally wrote the code it had to be able to swap out the core crypto depending on whether it was Mono or .NET Framework. Microsoft has since fixed that and I am currently going through the code to eliminate the historical functions. I would really like it if Microsoft would get with the program and actually implement SHA3, Ed448, Ed22519, X448 and X25519. And I expect they will. but in the meantime, I had to write some placeholder code. I don't plan to rely on constant time implementation to protect against side channel attack. It tends to be brittle in the face of aggressive compiler optimization. The Kocher patents should expire soon if they haven't already and they provide a more powerful approach that I need to implement for other reasons. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Sat, Jan 5, 2019 at 10:26 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote: > > > > On Sat, Jan 5, 2019 at 2:55 PM Mark Steward <marksteward@gmail.com> wrote: >> >> On Sat, Jan 5, 2019 at 7:46 AM Phillip Hallam-Baker >> <phill@hallambaker.com> wrote: >> > >> > OK so I have decided to make a few changes to the structure here so the values will change. >> > >> > Let us say that m = "Konrad is a Kompromised agent". >> > first choose a random key kt = P (0xB0 || rand (512), 125) >> > (where P is the presentation/truncation function using Base32 putting in dashes every 5 characters and truncating to 125 bits) >> > >> > We use SHA-2-512 to construct a Keyed UDF, so HKDF(), H(), HMAC() are functions all using that as the base digest: >> > >> > k = HKDF (kt, 512) >> > f = HMAC (k, ct || ':' || H(m)) >> > udf = P((v || f), 125) >> > >> > Where v is simply a tag to identify the fingerprint type and ct is the IANA content type >> > >> >> So that's effectively just HMAC(rand(117), m), truncated to 120 bits >> (i.e. a birthday complexity of 60 bits). What purpose does the >> obfuscation serve? > > > A straight hash function would allow a dictionary attack. Adding in the key means that a brute force attack has a work factor of the dictionary size times 2^512 which is obviously infeasible. > I don't mean "why use an HMAC", I mean why take 512 bits of random, truncate them to 117 bits (by prefixing 8 constant bits and calling P), and then stretch the output and pretend it's 512 bits? Why then prefix content type unless you're anticipating reusing keys? And why truncate the final output to 117 bits again, and format it like it's something to be entered by hand, when a simple HMAC would suffice? There must be a reason you've chosen this inscrutable structure. >> https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L212-L222 >> >> That link is to some bizarre functionality to "compress" the output by >> adding the number of leading zero bytes to the versionID, which >> further reduces the hash to 117 bits, and allows fingerprints from two >> different versions to collide. > > > That is important and useful functionality for key fingerprints. The compression function does not affect the brute force work factor for the attacker. What it means is that if the user puts in a Work Factor of 2^24 on key generation, the work factor of the resulting 125 bit fingerprint will be 2^(117+24) rather than 2^117. > > That is a standard construction that has been reviewed by the IETF. Unfortunately, there is a patent on a particular approach held by Microsoft. While they have licensed that for certain IETF protocols, it is not generally licensed. > I can't make sense of what you're trying to say here. The initial zeroes are part of the hash, not leading zeroes from prime numbers or similar. If you removed this suspicious and buggy functionality, would that break anything? >> Your convenient Validate function isn't constant time: >> >> https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L407-L408 > > > Probably not. That is currently just a placeholder. It doesn't even accept longer fingerprints to check against shorter patterns. > Checking shortened fingerprints is an antipattern, as demonstrated by GPG short key collisions. If humans need to enter hashes by hand, something's gone very wrong already. > I don't plan to rely on constant time implementation to protect against side channel attack. It tends to be brittle in the face of aggressive compiler optimization. The Kocher patents should expire soon if they haven't already and they provide a more powerful approach that I need to implement for other reasons. > Are you talking about the patent from 1998? I don't see how that can help with hash comparison. Mark _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Sun, Jan 6, 2019 at 9:56 AM Mark Steward <marksteward@gmail.com> wrote: > On Sat, Jan 5, 2019 at 10:26 PM Phillip Hallam-Baker > <phill@hallambaker.com> wrote: > > > I don't mean "why use an HMAC", I mean why take 512 bits of random, > truncate them to 117 bits (by prefixing 8 constant bits and calling > P), and then stretch the output and pretend it's 512 bits? Why then > prefix content type unless you're anticipating reusing keys? And why > truncate the final output to 117 bits again, and format it like it's > something to be entered by hand, when a simple HMAC would suffice? > There must be a reason you've chosen this inscrutable structure. > [Thanks for the feedback here it is helping, the design has evolved over time and not all the features may be apparent.] I think your confusion is probably due to the fact that I haven't pushed out the draft yet which gives the context. This is a fingerprint scheme that has been extended to support commitments. It was not designed as a pure commitment scheme. This is the latest draft but it is not complete. It may still have the previous construction in places that did not use HMAC. https://tools.ietf.org/html/draft-hallambaker-udf-12 The starting point is I wanted a more robust, flexible PGP fingerprint scheme that protects against semantic substitution, has a readable presentation, etc. So a UDF fingerprint with a work factor approximating to the 128 bits we like to work from (actually 117 bits) looks like this: MDDK7-N6A72-7AJZN-OSTRX-XKS7D That is something I can put on my business card. But it is still a little long. Hence the need for the compressed version: ME522-SXCSN-BFY3H-JBAAD That has a work factor of 116 bits. If I could press my GPUs into service, I could generate a public key with a 124 bit work factor without too much inconvenience. The reason for rendering the key as text is that it allows me to write it down on paper without going to a printer. We only need as many bits of randomness in the input to the HMAC as we will report in the output. It is stretched to 512 bits using HKDF because that is the function that is designed to convert strings to keys. It is overkill for this purpose but it means I use the same function everywhere. I can't make sense of what you're trying to say here. The initial > zeroes are part of the hash, not leading zeroes from prime numbers or > similar. If you removed this suspicious and buggy functionality, would > that break anything? > It would not break anything at the technical level but it would make the usability worse. One of the antipatterns I see when using BASE32 fingerprints is that folk end up generating fingerprints like MONEY-SXCSN-BFY3H-JBAAD-XKS7D or MICRO-SOFTN-BFY3H-JBAAD-XKS7D Which seems great at first until you realize that a human is only ever going to check the readable part. so now there is an in for the attacker who generates MONEY-SXGDR-KG47R-7OVPT-OSTRX That is completely different but is going to be confused. For even more confusion, match the first and last segments: MONEY-SXCSN-BFY3H-JBAAD-XKS7D MONEY-SXGDR-KG47R-7OVPT-XKS7D > >> Your convenient Validate function isn't constant time: > >> > >> > https://github.com/hallambaker/Mathematical-Mesh/blob/8f309a1/Libraries/Goedel.Cryptography/UDF.cs#L407-L408 > > > > > > Probably not. That is currently just a placeholder. It doesn't even > accept longer fingerprints to check against shorter patterns. > > > > Checking shortened fingerprints is an antipattern, as demonstrated by > GPG short key collisions. If humans need to enter hashes by hand, > something's gone very wrong already. > I disagree. Humans do need to be able to enter fingerprints in certain circumstances. But the short fingerprints should never have a work factor of less than 2^110. The long fingerprints in UDF are 250 or 500 bits. That is clearly not something that a sysop should ever type. The situation in which I would see these being used would be something like the following. 1) User sets up new device, it reports its UDF as MDDK7-N6A72-7AJZN-OSTRX-XKS7D 2) User cuts and pastes the UDF into an admin tool 3) Admin tool talks to device, gets the document corresponding to the UDF, calculates the long UDF: MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI-6OZSL-U2VOA- TZQ6J-MHPTS 4) Admin tool determines that the user fingerprint matches the one calculated and declares it a match 5) Admin tool stores the 250 bit fingerprint in the device database. > I don't plan to rely on constant time implementation to protect against > side channel attack. It tends to be brittle in the face of aggressive > compiler optimization. The Kocher patents should expire soon if they > haven't already and they provide a more powerful approach that I need to > implement for other reasons. > > > > Are you talking about the patent from 1998? I don't see how that can > help with hash comparison. > I don't see how constant time would be relevant for a digest operation. The implementations of Ed/X 448/25519 are not constant time because they are only placeholders for use until Microsoft releases some proper implementations. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On 2019-01-06 at 13:29 -0500, Phillip Hallam-Baker wrote: > I think your confusion is probably due to the fact that I haven't > pushed out the draft yet which gives the context. This is a > fingerprint scheme that has been extended to support commitments. It > was not designed as a pure commitment scheme. > > > This is the latest draft but it is not complete. It may still have the > previous construction in places that did not use HMAC. > > > https://tools.ietf.org/html/draft-hallambaker-udf-12 I am a bit worried by the truncation part. The fact that a hash function is collision-resistant does NOT mean that the first N-bits (in your case 25) are as collision resistant as the whole hash. Thus, you may find for instance that a SHA2 truncated to 128 bits is actually suffering more collisions than a "weaker" MD5. > > (...) > > > One of the antipatterns I see when using BASE32 fingerprints is that > folk end up generating fingerprints like MONEY-SXCSN-BFY3H-JBAAD-XKS7D > or MICRO-SOFTN-BFY3H-JBAAD-XKS7D > > > Which seems great at first until you realize that a human is only ever > going to check the readable part. (...) If that human misuse is a concern, I think you would have to move to either use a wordlist (either PGP Word List or a new one). Or perhaps by completely making it non-readable (like removing vowels) you might get some people making a better check than readable words that would attract to be the ones checked, (however, it increases the odds of people not making any verification at all). I guess there's also the argument of people actually lowering the entropy by focusing on generating readable hashes (on the other handit would be easier to remember a hash of "MONEY-LENDI-NGSER-VICES-BANK"). Even if placing a (human) filter after random key generation for discarding "ugly hashes" decreases the initial entropy, I am however not aware of any way that could be actually exploited, provided: * It uses a strong hash function (pre-image resistance) * The keys themselves are not weakened for facilitation getting a readable hash (eg. using composite numbers in place of a prime) * The generation method does not follow a set of steps that actually allow cheaper generation of the key. (in summary, that you still do the things the right way™) Best regards PS: Note the html entities on section 4. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On 2019-01-03 at 13:29 -0500, Phillip Hallam-Baker wrote: > As of 1st Jan, I am no longer employed by Comodo Group or any other CA > or browser provider. So I am looking at new directions. One of these > is a video blog: PHB's CryptoWar which will follow my various > interests from politics, to cryptography to prop making. > > > To start it off: here are three commitments which are the names of > three individuals who I expect to see indicted/charged with serious > crimes in the near future: > > > UDF=KD25H-GSNE2-JVVJE-RXTMA-7VAWT > UDF=KCOO3-EKPAG-FKYFC-O2B2N-O3UUA > UDF=KBR3A-RQLV7-SMB6X-6OB7X-JMBNT > [These names are also known to at least two international news > organizations who like myself are allowing the authorities to complete > their work.] > > > The kommitments provide a cryptographic means of proving that I knew > something at a particular time without revealing it (yet). They > demonstrate both the use of a digest function and the advantage of > using a key. > > > The next obvious technical topic to tackle is blockchain. Right now, > blockchain is using more electricity than Ireland and minting several > billion worth of new currency to process fewer transactions than a > moderately busy CostCo. > > > So what is the current state of the art on blockchain without proof of > work? Harber and Stornetta suggested publication in the Times. Which > is of course recourse to a higher level notary. The next obvious > approach is a circular firing squad of notaries that cross notify. Has > anyone published anything further I should present? You will probably think this is a very gross solution, but my initial idea for the stated problem was that you simply obtained (eg. with Lets Encrypt, but you can pay for it, too) HTTPS certificates for: KD25H-GSNE2-JVVJE-RXTMA-7VAWT.villain1of3.20190101prediction.hallambaker.com KCOO3-EKPAG-FKYFC-O2B2N-O3UUA.villain2of3.20190101prediction.hallambaker.com KBR3A-RQLV7-SMB6X-6OB7X-JMBNT.villain3of3.20190101prediction.hallambaker.com and rely heavily on the CT logs to prove so that there was only a single 20190101 prediction and that you didn't backdate it (something for which we have less guarantees, probably this would be based on trusting the CA ways to make Not before as the Creation value). Att least it is immensely cheaper than storing the same data in the bitcoin blockchain. Cheers _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography