Poll On New Value Field Size

[khal]

I discussed a bit with ryan-c about the encryption, here is a brief resume :
- if we don't encrypt names, values can be decrypted by anybody (the name will be the key), the name_show command will do that (nothing has really changed ?)
- if we encrypt names, it means you must know the name, hash it some way, and then you can get the value and decrypt it with the hashed value (the key). It also means names are not searchable/listable anymore in namecoin (a lot of possibilities are removed with this IMO)

I'm a bit skeptic about the blockchain encryption...


ps : should you make the poll re-votable (as the discussion may bring important things :p) ?

[domob]

I discussed a bit with ryan-c about the encryption, here is a brief resume :
- if we don't encrypt names, values can be decrypted by anybody (the name will be the key), the name_show command will do that (nothing has really changed ?)
- if we encrypt names, it means you must know the name, hash it some way, and then you can get the value and decrypt it with the hashed value (the key). It also means names are not searchable/listable anymore in namecoin (a lot of possibilities are removed with this IMO)

I'm a bit skeptic about the blockchain encryption...

Someone made a suggestion a while back which I like: If you have names like "torrents/wikileaks/some-name", then only "torrents/wikileaks" would be the unknown encryption key for each of the names following the second "/". That way, names are encrypted and non-searchable "by default" (which is not a bad property, IMHO), but it is also possible to create directories which are searchable by everyone knowing the directory's name. (A hypthetical database of Wikileaks Torrent files, in this case - you would have to know that the database is called "torrent/wikileaks", but could then browse all "entries" using this name as key.)

[virtual_master]

I discussed a bit with ryan-c about the encryption, here is a brief resume :
- if we don't encrypt names, values can be decrypted by anybody (the name will be the key), the name_show command will do that (nothing has really changed ?)
- if we encrypt names, it means you must know the name, hash it some way, and then you can get the value and decrypt it with the hashed value (the key). It also means names are not searchable/listable anymore in namecoin (a lot of possibilities are removed with this IMO)

I'm a bit skeptic about the blockchain encryption...


ps : should you make the poll re-votable (as the discussion may bring important things :p) ?

This are all known and already more times discussed aspects Khal.
We should come forward and implement at least 2.5k value field size without encryption and without torrent links.
Not only those who are looking those over-discussed type of pictures are crazy but who think that anybody will look at porno pictures at 2.5 kB size is also.
When we have implemented encryption then we can implement 5k value field size or higher and torrent link support also.

-----------

I already suggested another encryption type where the encryption key of the value fields of an entry is in the next block. (miners are protected this way by plausible deniability against eventually included controversial content)

[indolering]

What about a compromise of 2.5k? That way we could still fit in a largish key with some additional data. It should be sufficient for most applications so the benefit from anything more is small.

*checks size of image he can fit into 2K*

This still makes me uncomfortable but I guess I can live with 2.5K. Can we put size restrictions on the key field size to keep it at 2K?

*smacks his forehead and yells "DOH!"

Not KB but kb! *checks size of image he can fit into 5 kilobits*

Okay, that 5 kilobit image is tiny. As long as the maximum value size is 5kb and not 5KB we should be okay. However, we are still opening ourselves up for an attack. Could someone give me a sanity check on the following:

• Can we force the key field to be a maximum of 4K?
• Can we enforce any field size and content restrictions at the blockchain value level? Just making the parser fall over doesn't mean ... pm me for possible scenarios. I don't want to give "them" any ideas.
• Could we further compress key sizes without enabling compression arbitrary data as well? Then we could just specify that values in id/ be run through an additional function to derive the key. I'm not comfortable enough with the low-level number theory here.

Sorry to be a PITA, Jeremy_Rand talked me down from the cliff a few months ago on this issue. I still need to write a post on the defenses we came up with and work out an NEP.

Not only those who are looking those over-discussed type of pictures are crazy but who think that anybody will look at porno pictures at 2.5 kB size is also.

PM me or join the BitMessage thread for possible attacks. They are withering and I don't want to give "them" any ideas.

[virtual_master]

PM me or join the BitMessage thread for possible attacks. They are withering and I don't want to give "them" any ideas.

I don't want to look on such pictures not even as test.

---------------

It seems that with bits and bytes there was a confusion. From my side also.
The maximal key size for the actual RSA/DSA system is 4096 bits. That would be only 512 bytes if stored optimal but if stored as decimal numbers(as they seems to be) then they require almost 1.5 KByte.
So if we limit the value field with 2KB it will reach for any actual GPG supported key size.
The size of the name entry we don't need to limit(just only with the size fee) so it could be introduced both RSA and DSA keys for encryption and signature by a same name entry.

Is that OK for everybody ?

[indolering]

PM me or join the BitMessage thread for possible attacks. They are withering and I don't want to give "them" any ideas.

I don't want to look on such pictures not even as test.

I am talking about sharing ideas for attacks against the coin, not images. But even in my benchmarking I only use non-explicit images of babies.

EDIT: Ugh, even that sounds gross. They do convey the potential for harm more clearly. FWIW my mother is a child therapist and there are very few reasons children go to therapy. Few people fully appreciate this evil *shudders.*

It seems that with bits and bytes there was a confusion. From my side also.
The maximal key size for the actual RSA/DSA system is 4096 bits. That would be only 512 bytes if stored optimal but if stored as decimal numbers(as they seems to be) then they require almost 1.5 KByte.
So if we limit the value field with 2KB it will reach for any actual GPG supported key size.
The size of the name entry we don't need to limit(just only with the size fee) so it could be introduced both RSA and DSA keys for encryption and signature by a same name entry.

Is that OK for everybody ?

I'm voting against it, forcing id/ clients to store their keys in binary or base-64 (which is the default) isn't an onerous requirement. Again, we can expand it in the future: Freenet and Tor are the only viable CP content storage mechanisms, we just need to get ourselves established with the public before we can make that point. After we establish rep, I think we can control the media fallout from an instance of this insane use-case (just as Google and other regular internet providers do).

[Ben]

I discussed a bit with ryan-c about the encryption, here is a brief resume :
- if we don't encrypt names, values can be decrypted by anybody (the name will be the key), the name_show command will do that (nothing has really changed ?)
- if we encrypt names, it means you must know the name, hash it some way, and then you can get the value and decrypt it with the hashed value (the key). It also means names are not searchable/listable anymore in namecoin (a lot of possibilities are removed with this IMO)

I'm a bit skeptic about the blockchain encryption...

I agree, I think encryption is unneeded and a bad idea for the same reasons mentioned.

[khal]

My GPG public key is 3117 bytes in base64 for a 4096bits key (https://dot-bit.org/files/gpg/khalahan.asc).
Other encodings may even use less space as noted by virtual_master.

The large key format used by domob in his id/domob is pretty simple and easy to manage in any software (a wget to fetch the uri may not even be needed if the key already exists in public servers or in your keyring) :

Code: Select all

{"v":"pka1","fpr":"0123456789abcde0123456789abcde0123456789","uri":"http://www.example.com/user.key"}

For now, even 1k would be sufficient (remember Bill Gates :p), so, the real question is, do we want to potentially make a second hard fork if we chose a too law value or limit potiential new usages ?

For example, I discovered the project metalinker (in a post by indolering) and they use such metadata to describe a file :
http://www.metalinker.org/samples/abiwo ... e.metalink (2.6k)
Note : of course we are not forced to store all this in the blockchain, nor I would say it is a good idea.

I start to think the shorter is better... (only stupid people don't change their mind we say, in FR :p) and that everything that can be put outside is better.
The reasoning behind this is :
- the blockchain/namecoind alone can't do a lot of things, so, other softwares are required
- those other softwares can fetch data without difficulty
- the blockchain will then be used only to store trusted data that allow to trust non trusted external data
- putting everything outside of the blockchain except a hash of a file is not a solution too

Based on this, we could find a ideal size :p

[indolering]

My GPG public key is 3117 bytes in base64 for a 4096bits key (https://dot-bit.org/files/gpg/khalahan.asc).
Other encodings may even use less space as noted by virtual_master.

The base-64 size should be smaller than a decimal representation, the dictionary size is larger.... VM did you mean ASCII?

The large key format used by domob in his id/domob is pretty simple and easy to manage in any software (a wget to fetch the uri may not even be needed if the key already exists in public servers or in your keyring) :

Code: Select all

{"v":"pka1","fpr":"0123456789abcde0123456789abcde0123456789","uri":"http://www.example.com/user.key"}

For now, even 1k would be sufficient (remember Bill Gates :p), so, the real question is, do we want to potentially make a second hard fork if we chose a too law value or limit potiential new usages ?

A future hard fork is highly likely. We could have a patch set of features requiring a hard fork waiting around for the next time a security bug requires a hard fork

For example, I discovered the project metalinker (in a post by indolering) and they use such metadata to describe a file :
http://www.metalinker.org/samples/abiwo ... e.metalink (2.6k)
Note : of course we are not forced to store all this in the blockchain, nor I would say it is a good idea.

I start to think the shorter is better... (only stupid people don't change their mind we say, in FR :p) and that everything that can be put outside is better.

Damn, I would like to store raw metalinks and plain-text representation of a 4Kb key into a single value as well. It's an obvious use-case and it simplifies things on the client side.

I think 1K is too small long term, we should definitely increase the overall size at some point. If we HAVE to make a change to the size anyway then I would be fine with 2KB. Again, however, can we place further restrictions on the field content (size and formatting) to keep the key field's size at a maximum of 1.5 KB?

[virtual_master]

My GPG public key is 3117 bytes in base64 for a 4096bits key (https://dot-bit.org/files/gpg/khalahan.asc).
Other encodings may even use less space as noted by virtual_master.

The base-64 size should be smaller than a decimal representation, the dictionary size is larger.... VM did you mean ASCII?

No. I mean decimal numbers. In a decimal number are fitting more than 3 bits.
2048 bits are fitting in 617 decimals and 4096 bits in 1234 decimals. (which are represented in ASCII)
Even in Unicode it can be only 2368 bytes theoretically.
Anyway if it would be compressed and decompressed before showed/used then it can only take 4096 bits/8=512 bytes.
The information content of a base 64 character is 6 bit so with base 64 encoding it must be theoretically 4096/6=684 bytes long for the DSA/RSA 4096 key. I don't understand how Khal has 3117 bytes instead of the theoretical 684(or 1368 with Unicode) bytes.
Look on the wikipedia, they calculated also for the RSA 2024 key.
https://en.wikipedia.org/wiki/RSA-768#RSA-2048

A two step value field increase (and fee update also in two steps) could have sense.