torcontrol: Explicitly request RSA1024 private key #9234

1. 
   laanwj commented at 4:17 pm on November 28, 2016: member

   When generating a new service key, explicitly request a RSA1024 one.

   The bitcoin P2P protocol has no support for the longer hidden service names that will come with ed25519 keys, until it does, we depend on the old hidden service type so make this explicit.

   See #9214.

2. laanwj added the label Needs backport on Nov 28, 2016
3. laanwj added the label P2P on Nov 28, 2016
4. laanwj added this to the milestone 0.13.2 on Nov 28, 2016
5. torcontrol: Explicitly request RSA1024 private key

   When generating a new service key, explicitly request a RSA1024 one.
   
   The bitcoin P2P protocol has no support for the longer hidden service names
   that will come with ed25519 keys, until it does, we depend on the old
   hidden service type so make this explicit.
   
   See #9214.

   7d3b627395
6. laanwj force-pushed on Nov 28, 2016
7. 
   btcdrak commented at 5:21 pm on November 28, 2016: contributor

   utACK
8. 
   sipa commented at 6:37 pm on November 28, 2016: member

   utACK 7d3b627395582ae7c9d54ebdbc68096d7042162b
9. 
   fanquake commented at 1:30 am on November 29, 2016: member

   utACK 7d3b627
10. 
    paveljanik commented at 7:32 am on November 29, 2016: contributor

    utACK 7d3b627
11. 
    gmaxwell commented at 10:19 am on November 29, 2016: contributor

    utACK; do we know how far back tor version wise this is supported?
12. 
    laanwj commented at 10:32 am on November 29, 2016: member

    I’m quite sure choosing “RSA1024” instead of “BEST” has always been supported - why have a key type parameter otherwise.

    The only reason I’ve chosen “BEST” here originally was that I was unaware that a different key type could change the address format to something bitcoin can’t handle.

13. 
    laanwj commented at 11:22 am on November 29, 2016: member

    The parameter is documented here: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1446

    There is no mention of any version constraints relevant to KeyBlob.

14. 
    gits7r commented at 2:05 pm on November 29, 2016: none

    ACK.

    I confirm explicitly asking for the key type is supported for as far back as ADD_ONION is. Until RSA1024 keys (v2 HS) are permanently rejected in the Tor network, this patch should work. It’s useless to ask for BEST key type when there is a p2p protocol ‘address’ limitation (I don’t think the limit should go away, just increased just enough to keep up with current demands).

15. 
    gmaxwell commented at 3:00 am on November 30, 2016: contributor

    ACK. (tested now)
16. laanwj merged this on Nov 30, 2016
17. laanwj closed this on Nov 30, 2016

    ---

18. laanwj referenced this in commit 56bee4986d on Nov 30, 2016
19. laanwj referenced this in commit 94531b5350 on Nov 30, 2016
20. MarcoFalke referenced this in commit 82e29e8b7c on Nov 30, 2016
21. MarcoFalke removed the label Needs backport on Nov 30, 2016
22. 
    MarcoFalke commented at 9:18 pm on November 30, 2016: member

    Was backported to 0.13 in 94531b53509470e01dcbd90275577cb37a794fa8. (Removing label)

    Added backport for 0.12 to #9211

23. UdjinM6 referenced this in commit 7c426cd3b6 on Mar 22, 2017
24. UdjinM6 referenced this in commit 01a3477547 on Mar 22, 2017
25. zkbot referenced this in commit 45faa928ec on Mar 26, 2017
26. UdjinM6 referenced this in commit ff30aed68f on Apr 11, 2017
27. thokon00 referenced this in commit 05d2057e7d on Apr 17, 2018
28. MarcoFalke locked this on Sep 8, 2021

Contributors
laanwj btcdrak sipa fanquake paveljanik gmaxwell gits7r MarcoFalke

Labels
P2P

Milestone
0.13.2