Nostr anahtarları açıklandı: iki dizede dijital kimliğiniz

Nostr hesabınız bir kullanıcı adı ve şifre kombinasyonu değildir. Bu, sizin tarafınızdan tutulan, biri açık ve biri özel olan bir çift şifreleme anahtarıdır. Yaptığınız her gönderi özel anahtarınızla imzalanır; gönderinizi gören her istemci imzayı açık anahtarınıza karşı doğrular.

Bu, Nostr hakkında anlaşılması gereken tek en önemli şeydir, çünkü diğer her şeyi şekillendirir. Hiçbir şirketin bir kopyası olmadığı için kimliğiniz kaybolursa kurtarılamaz. Hesabınız bir platform tarafından yasaklanamaz, çünkü kaldırılacak bir platform veritabanı yoktur. Bunlar aynı özelliğin farklı açılardan görülmesidir.

Bu kılavuz anahtarların ne olduğunu, her birinin ne yaptığını, nasıl kodlandığını ve bunları kaybettiren spesifik hataları açıklar.

TL;DR. npub1... sizin açık anahtarınızdır. Her yerde paylaşmak güvenlidir. nsec1... sizin özel anahtarınızdır. Bunu bir şifre yöneticisinde veya güvenli bir yerde kağıt üzerine basılı olarak tutun. Asla bir web sitesi formuna yapıştırmayın. Kaybederseniz kimlik kalıcı olarak kaybolur.

Hazır olduğunda, @nostr.blog adresini al →

Bir anahtar çifti aslında nedir

Bir anahtar çifti, matematiksel olarak bağlantılı iki sayıdır. Matematik, secp256k1 adlı bir eğri üzerinde eliptik eğri şifrelemesidir (Bitcoin'in kullandığı aynı eğri).

• Özel anahtar, rastgele bir 32 baytlık sayıdır. 256 bitlik herhangi bir rastgele sayı işe yarar; sizin hakkında özel bir şey yoktur.
• Açık anahtar, özel anahtardan eliptik eğri üzerinde belirli bir hesaplama yoluyla türetilir. Özel anahtar verildiğinde, açık anahtarı hesaplamak hızlıdır. Açık anahtar verildiğinde, özel anahtarı geri hesaplamak pratik olarak imkansız olduğu inanılır.

"Pratik olarak imkansız" burada şu anlama gelir: bilinen hiçbir algoritma bunu makul bir süre içinde, var olan veya makul ölçüde var olabilecek herhangi bir bilgisayarda yapamaz. Güvenlik bu asimetri üzerine kuruludur. Açık anahtarı serbestçe yayınlarsınız; özel anahtarı mutlak olarak korursunuz.

Her anahtar ne yapar

Açık anahtar kimliğinizdir. Birisi sizi takip ettiğinde, açık anahtarı takip eder. Birisi sizi bahsettiğinde, açık anahtarı etiketler. Bir relay gönderilerinizi depoladığında, bunları açık anahtarla indeksler. Ağda sizin hakkında görünen her şey bu tek değere bağlıdır.

Özel anahtar imzalar. Her olay (gönderi, tepki, takip listesi güncellemesi, profil değişikliği) özel anahtardan ve etkinliğin karmasından üretilen bir Schnorr imzası taşır. Herhangi bir istemci ters kontrolü çalıştırabilir: açık anahtar, karma ve imza verildiğinde, eşleşen özel anahtarın sahibi tarafından üretilen imzanın bu olması gerektiğini doğrulayın.

Sonuç: relay'ler ve istemciler kimseyi güvenmeleri gerekmez. İmzaları kendileri doğrularlar. Geçersiz imzası olan sahte bir gönderi sessizce bırakılır. Doğru anahtar tarafından imzalanan gerçek bir gönderi hangi relay'den sunulduğu fark etmeksizin kabul edilir.

Anahtarlar nasıl kodlanır

Ham 32 baytlık bir sayı bakmak veya yazmak için elverişsizdir. Nostr iki kodlama konvansiyonu kullanır.

Hex. Ham baytlar küçük harf onaltılı sayı olarak yazılır: 64 karakter, a-f ve 0-9. Bu, NIP-05 JSON dosyalarının içinde ve çoğu protokol içinde görünen kanonik biçimdir.

Hex'deki açık anahtar örneği: 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. Aynı baytlar bir ön ek ve sağlama toplamı ile insan odaklı bir biçimde sarılmıştır. Ön ek, insanlara (ve yazılıma) ne tür bir şey olduğunu söyler. npub1 "bu bir Nostr açık anahtarıdır" anlamına gelir. nsec1 "bu bir Nostr özel anahtarıdır" anlamına gelir.

Bech32'deki açık anahtar örneği: npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

Bech32'deki sağlama toplamı önemlidir. Yanlışlıkla bir karakteri değiştirirseniz, sağlama toplamı başarısız olur ve herhangi bir araç anahtarı geçersiz olarak reddeder. Bu, kopyala-yapıştır sırasında sessiz bozulmayı önler. Hex'te böyle bir güvenlik yoktur; bir hex anahtardaki tek yanlış karakter farklı (ama geçerli görünen) bir kimlik üretecektir.

Önek, diğer Nostr veri türleri için de mevcuttur. note1 bir etkinlik kimliğidir. nprofile1, açık anahtar ve önerilen relay'lerle birlikte paketlenmiştir. nevent1, etkinlik kimliği yazarı ve relay'lerle birlikte paketlenmiştir. 1, sürüm numarası değil, Bech32 ayırıcının parçasıdır.

Anahtarlar nerede yaşar

Herhangi bir Nostr istemcisini ilk kez yüklediğinizde, işletim sisteminden 32 rastgele bayt isteyerek bir anahtar çifti oluşturur. Bütün tören budur. Rastgele sayı üreteci bittiğinde anahtarlar sizdir.

İstemcinin bunları nerede depolayacağı uygulamaya bağlıdır:

• Yerel mobil uygulamalar nsec'i işletim sistemi anahtar zincirinde depolar (iOS Keychain, Android Keystore). Her ikisi de cihazın şifresi veya biyometrik verisiyle şifrelenmiştir.
• Tarayıcı tabanlı istemciler genellikle NIP-07 uzantısı yüklemenizi ister (nos2x, Alby, Flamingo) ve nsec'i uzantının güvenli depolamasında tutar. İstemci asla nsec'i doğrudan görmez; talep üzerine olayları imzalamak için uzantıyı sorar.
• NIP-07'yi atlayan istemciler nsec'i yerel tarayıcı depolama alanına yapıştırmanızı ister; bu daha az güvenlidir. Bu, düşük bahisli hesaplar için iyidir ve değerli olanlar için kötü bir fikirdir.
• Donanım cüzdanı stilindeki Nostr imzalayıcılar (bunker uygulamaları, uzak imzalayıcılar) nsec'i ayrı bir cihazda tutarlar ve şifrelenmiş bir kanal üzerinden uzaktan imzalarlar. En gelişmiş, en düşük saldırı yüzeyi.

nsec'i nasıl yedekleyin

En önemli yedekleme kuralı: nsec en az iki yerde bulunmalı, ancak asla sağlayıcı tarafından okunabilecek bir bulutta olmamalıdır.

İyi yerler:

• 1Password, Bitwarden, KeePassXC veya uçtan uca şifreleme ile herhangi bir şifre yöneticisi
• iCloud Keychain (uçtan uca şifrelenmiş; Apple bunu okuyamaz)
• Güvenli bir fiziksel konumda basılı bir kağıt (bir kasa, bir banka kasası)
• Fiziksel dayanıklılık istiyorsanız Bitcoin tarzı çelik yedekleme plakası

Kötü yerler:

• iCloud Notes, Google Keep, Evernote, OneNote (bunlar sağlayıcı tarafından çözülebilecek biçimlerde senkronize olur)
• Kamera rolünüzde bir ekran görüntüsü (iCloud veya Google Fotoğraflar'a düz metin olarak otomatik yedeklenir)
• Kendinize e-posta
• Telegram "Kaydedilen Mesajlar" veya başka bir sohbet uygulaması kendi kendine DM
• Dropbox, Google Drive, iCloud Drive'da düz metin dosya

Ayırım şudur: sağlayıcı isterse metni okuyabilir mi? Evet ise, konum güvenli değildir. Hayır ise (veya sağlayıcı yazıcıyla birlikte siz ise), konum güvenlidir.

Paranoyaklar için: parçalama. nsec'i eşik şeması kullanarak birden çok parçaya bölün (Shamir Gizli Paylaşımı) ve her parçayı ayrı ayrı saklayın. İki veya üç parça anahtarı yeniden oluşturur. Çoğu kullanıcı için gereksiz, yüksek değerli bir kimliğe sahip kullanıcılar için mantıklıdır.

nsec'i kaybederseniz ne olur

Hesap kalıcı olarak kaybolur. Sıfırlama akışı yoktur. Hiçbir şirketin bir kopyası yoktur. npub'tan tek başına anahtarı kurtarabilecek şifreleme hilesine yok.

Kaybın üç pratik sonucu vardır:

• O kimlikten artık gönderi yapamazsınız.
• Bu kimliğe zap alamazsınız (eski profil etkinliğinizin gösterdiği Lightning adresi hala vardır, ancak profilinizi güncelleyemediğiniz için, temel hizmet değişirse adres eski hale gelebilir).
• Takip listenizi, profilinizi güncelleyemez veya doğrudan mesajlara yanıt veremezsiniz.

Gönderileriniz relay'lerde kalır, herkes tarafından okunabilir. Takipçileriniz eski gönderileri istemcilerinde görmeye devam eder. Yeni aktivite imkansızdır.

Pragmatik yanıt: yeni bir anahtar çifti oluşturun, eski npub'unuzu izleyen herkese "geçiş" açıklaması yapın ve yeniden başlayın. Kırılmada sizi takip etmek isteyen insanlar bunu yapacak; bazılarını kaybedecek ve başkalarını tekrar kazanacaksınız. Bunu henüz protokol düzeyinde sürtünmesiz hale getirmenin bir yolu yoktur.

Birisi nsec'inizi alırsa ne olur

Saldırgan yapabileceğiniz her şeyi yapabilir:

• Kimliğiniz altında gönderi yayınlayın (sonsuza dek)
• Şifresi çözülmüş doğrudan mesajlarınızı okuyun
• Profilinizi güncelleyin (NIP-05 tanımlayıcınızı da değiştirme dahil)
• İstemcinizle erişilebilir herhangi bir cüzdan bakiyesi kullanarak zap gönderin
• Takip listenizi değiştirin

Ek erişim olmadan yapamayacakları:

• İstemcinin eşleştirilmediği Lightning cüzdanını doğrudan boşaltın
• Size gönderilen zap'ları çalin (bunlar yapılandırılmış Lightning adresinize gider)
• Anahtarı kullanmanızı engelleyin (yine de sizin; bu geçersiz kılınan bir kimlik doğrulama jetonu değildir)

Şüpheli nsec tehlikesinize acil yanıt zordur. Şifrenin aksine, nostr nsec'leri iptal edilemez. Gerçekçi azaltma yeni bir anahtar çifti oluşturmak, eski olandan kimlik döndürdüğünü uyarmak ve kimlikleri değiştirmektir. NIP-41 ve benzer öneriler bunu temizlemeyı amaçlar ancak henüz evrensel olarak desteklenmez.

Çoklu kimlikler

Birçok Nostr kullanıcısı birden fazla kimlik çalıştırır. Halka açık mesleki bir hesap, özel bir kişisel hesap, belirli topluluklar için anonim bir hesap. Her biri ayrı bir anahtar çifttidir; çiftleri arası gönderiler yoluyla bağlamayı seçmedikçe hiçbir şey onları şifreleme yoluyla bağlamaz.

Çoğu istemci kimlikler arasında bir menüden geçişy yapılmasını destekler. Anahtarlar bağımsızdır; aynı istemci hepsine açılabilir ve bir dokunuşla geçiş yapabilir. Bu, kimliklerin aynı platformun veritabanında girişler olduğu Twitter çoklu hesaptan farklıdır; Nostr'da cryptographically ilişkisizdir.

Pratik bir ipucu: şifre yöneticisi girdilerini açıkça etiketleyin. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. Kopyala-yapıştır sırasında bunları karıştırmak, yanlışlıkla yanlış kimlikten gönderi yapmanın bir yoludur.

Anahtarlar hesaptır

Nostr'daki diğer her şey (okunabilir ad, profil resmi, biyografi, kullandığınız relay'ler, NIP-05 tanımlayıcısı) ikincil metaveridir. Bunların tümü değiştirilebilir veya taşınabilir. Anahtar çifti, yenisiyle başlamadan değiştirilemeyen tek şeydir.

nsec'i buna göre ele alın. Yedekleme, oluşturduğunuz anda iki dakika alır. Kayıp nsec'den kurtarma, haftalar süren yeniden yapım ve asla tamamen işe yaramazlık alır.

Nesil üzerine bir not. Yeni bir anahtar çifti almanın güvenli yolu, bir istemcinin bunu yerel olarak oluşturmasına izin vermektir ve hiçbir zaman özel yarısı ağ üzerinden iletmez. nostr.blog'un kaydolması bunu tarayıcıda istemci tarafında yapar; sunucu nsec'i asla görmez. Herhangi bir kaydolma akışı özel anahtarı önce bir sunucuya gönderirse, bu kırmızı bayraktır. Uzaklaşın ve başka yerde oluşturun.